dataesr/scientific-paragraphs-categorization huggingface dataset:
Generating Transformations from Image Coordinates The goal of a post-acquisition correlative experiment is to localize of a feature from available image data inside a second, different image dataset that provides complementary information. In order to find the transformation that registers the coordinate frame from the first imaging modality to the second, we need to define the unknown parameters. In a typical CLEM experiment, the information from the light microscopy data and those obtained by EM are fundamentally different, so an automated feature detection will most likely fail due to the lack of common structures. We therefore rely on a generic approach and on the availability of landmark pairs that the user can manually position in both image modalities. Let's assume we want to find the parameters of a similarity without reflection.
6 The system of equations can thus be written as: with the matrices U containing the source and V the target coordinates. [x1, x2 ,x3; y1, y2, y3] ; 1 U = In order to solve for the matrix coefficients in T, we simply need to invert this matrix multiplication. In general, matrix multiplications are not commutative, so the order of the factors matters. In our case, we want to determine the left factor, therefore we can apply MATLAB's "/" operator (identical to the function mrdivide). 1 T = V / [U;ones(1,size(U,2))]; However, this approach will solve the general matrix parameters and will not take into account the restrictions on our transformation matrix, such as the number of free parameters depending on the chosen type of transformation. It will simply determine a matrix that solves this set of equations.
Moreover, if the number of provided landmark pairs exceeds the number of constraints necessary to solve the equations, MATLAB will find the matrix coefficients using a least-squares approach. In order to restrict the solution to a specific transformation type, we will use the MATLAB function fitgeotrans. It produces a MATLAB transformation structure that contains the matrix and some metadata. It requires the coordinate data in columns, so we transpose U and V. 1 Transformation_Type= 'nonreflectivesimilarity'; 2 structT=fitgeotrans(U',V',Transformation_Type); 3 T=structT. T' The script code for these 2 methods can be found in Background_Finding Transformations. m.
Clathrin in conjunction with other proteins involved in endocytosis forms a lattice that can dramatically change the shape of the plasma membrane to form a vesicle. Top row: electron microscopy (EM) image. Bottom row: schematic of top row, with the plasma membrane in black and clathrin and associated proteins in red. (Image provided by Ori Avinoam, EMBL and Weizmann Institute of science, from the data published in Avinoam et al. 2015) Data Presentation All data used are available using the DOI: 7 http://doi. org/10. 5281/zenodo. 1473535.
6 6. 2 62 Clathrin in conjunction with other proteins involved in endocytosis forms a lattice that can dramatically change the shape of the plasma membrane to form a vesicle. Top row: electron microscopy (EM) image. Bottom row: schematic of top row, with the plasma membrane in black and clathrin and associated proteins in red. (Image provided by Ori Avinoam, EMBL and Weizmann Institute of science, from the data published in Avinoam et al. 2015) Data Presentation All data used are available using the DOI: 7 http://doi. org/10. 5281/zenodo. 1473535.
Moreover, many logic-specific systems are investigating how to allow users to experiment with system behavior inside the system, e. g. , via meta-programming (for Idris in  [4] , for Lean in  [7] ) or unification hints (for Coq in  [10] , for Matita in  [1] ). Within this group, MMT  [22]  takes an extreme approach: it tries to systematically avoid any commitment to logical foundations while still allowing useful generic results  [21, 20, 19]. All kernel algorithms of MMT are parametrized by a set of rules, which are programmed in the underlying programming language (Scala). The set of rules to use is collected from the current context so that entirely different kernel behaviors can coexist in the same development. This makes MMT so flexible that other logical frameworks can be conveniently developed inside it.
After sketching the basics of MMT language in Sect. 2, using the dependent type theory LF  [11]  as a "hello-world example", the subsequent sections describe one case study each that extends LF with increasingly complex features: dependently-typed higher-order logic (DHOL) in Sect. 3, Dedukti-style rewriting in Sect. 4 , LLF P types as described in  [12]  in Sect. 5, linear logic as defined by the resource semantics in Sect. 6, and homotopy type theory (HoTT) in Sect. 7. Our main contribution is to answer positively the question whether it is possible to build a framework that allows prototyping such a variety of features both elegantly and rapidly. Regarding elegance: all prototypes involve only little non-declarative parts (i. e. , rules programmed in Scala), and that code is orders of magnitude shorter and arguably easier to understand than a from-scratch implementation would be.
Finally, we add rule declarations rule E to the theory LF. Here the expression E is interpreted as an object of the underlying programming language (Scala). When checking a judgment, MMT uses only those rules that are visible to the current context. Each rule is a self-contained Scala object that is loaded dynamically when needed. When prototyping systems in MMT, users usually use a logical framework like LF and only define declarative, statically checked rules like we did for PL above. But, critically, users have the option to add a Scala-based rule whenever necessary. Each rule implements a specific Scala interface. For example, rules implementing InferenceRule are used whenever the judgment t ⇒ T is encountered; this interface includes a method inferType that receives the current context and t and must try to return T.
It also receives callbacks to recursively check the premises of the rule. Listing 2 shows an example rule inferring the type of a lambda term. For LF, we use 5 inference rules applicable to different terms: one each for terms formed from type, kind, Pi (or arrow), lambda, and apply. Additionally, we define 2 rules that check t ⇐ T and t ≡ t : T whenever T is a Pi-expression, and a computation rule for β -reduction. For type-reconstruction, MMT uses some variables to represent omitted subexpressions that must be reconstructed. For LF, only one additional rule is needed that is aware of these meta-variables -a special rule for pattern unification. Together with two rules for inhabitability, our LF prototype requires 11 Scala rules, taking about 200 lines of Scala code. This is a tiny fraction compared to the logic-independent code in MMT that builds a full-fledged application from these 11 rules.
Maybe surprisingly, except for a few minor adaptations, all existing rules of LF can remain unchanged, e. g. , LF's Scala rule to check t ⇐ {x : A}B worked immediately if A is a kind. We call the resulting logical framework PLF. Using the MMT module system, it is defined by including LF and adding one rule declaration. 4. The resulting case study is shown in Listing 3. Starting with polymorphic equality, we can define higher-order logic in the usual way, including the definition of polymorphic quantifiers and their proof rules. Note how kinded variables are treated in the same way as typed ones because MMT does not care about the difference anyway. Similarly, type reconstruction of variable kinds and implicit type arguments works out of the box: the new Scala rule does not even mention reconstruction.
The implementation of our plugin -including reusable abstractions for matching -takes about 450 lines of code  5. To evaluate it, we formalize Σ-types. In general, there are three different ways to do that: • As new primitive features akin to how we defined Π-types in LF. But that requires new Scala rules. • By declaring an object logic inside LF. But that does not allow building pairs of arbitrary LF types. • By defining polymorphic Σ-types in PLF. All three ways have their merit, and the latter two can make use of rewriting in essentially the same way: they turn the two β -style rules into rewrite rules pi i (pair x 1 x 2 ) x i. Here we choose the third way, both for the sake of example and because it is a neat trade-off between the other two options. The resulting formalization is given in Listing 4  6.
Their behavior is as follows: (i) The formation rule infers L K A ⇒ type from A ⇒ type. (ii) The introduction rule infers L K t ⇒ L K A from t ⇒ A. Both rules use the flexibility of MMT expressions to put the assumption K into the context -something that plain LF would not allow because K is not a well-typed LF expression. (iii) The elimination rule infers U t : A if t : L K A and if K holds. This rule is called in InferUnlock in Scala, and a fragment of its code is given in Figure  6. It establishes K of the form p(t, A) in one of two ways: if K is in the context (i. e. , we are in the monad), it is assumed; otherwise, we look up an ExternalConditionRule for p and call it on K. (iv-vi) The remaining 3 rules (check against monadic type, compare equality at monadic type, reduce unlock of lock) are straightforward.
The λ v case study is shown in the bottom part of Listing 5  7. We declare the side condition Val as an untyped constant and a rule ValRule of type ExternalConditionRule. The Scala code of ValRule is given in Listing 6  8. It checks the condition Val(t, a), i. e. , that t is of the form free n or λ F; if that fails, it registers an error message that the IDE will show to the user. The remainder then follows  [12]  in a straightforward way. We added the declaration check2 and fail, where InferUnlock calls ValRule. This succeeds in the first case because the argument 'n, which appears as LF. Apply(CallByValue. free, n) in the Scala code, is a λ v -value; it (correctly) fails in the second case where the argument is not a λ v -value. (Val N term) (λ M)@N. =(M N) # betav 1 2 csiv : {M,N}({x} L (Val x term) (M x).
Indeed, implementing the Scala rules is tedious but straightforward. But from a user perspective, even formalizing seemingly simple inductive types like natural numbers or lists using W-types is inconvenient and unintuitive. For example, Listing 9  11  shows an implementation of natural numbers and addition. In order to provide more convenient syntax, we write a plugin that extends the MMT language. This uses a powerful extension mechanism of MMT-called structural features -that we omitted in Figure  1  for simplicity. It is described in  [13]. Our structural features are intended to enable the definitions shown in Listing 10 12 , which is immediately recognizable as an inductive type and a recursive function. Structural features can be seen as an elegant logic-independent version of Isabelle's definitional packages.
Syntactically, they allow using arbitrary nested theories as declarations. Semantically, these nested theories are elaborated into a list of declarations generated from its contents. Each such nested theory is introduced by a special keyword that indicates which structural feature provides the elaboration function. For W-types, we provide two structural features for the keywords induct and def. Both are conservative in the sense that the elaboration contains only defined constants. The former generates a constant with a W-type as definiens and analogously defined constants for all constructors of the type. The latter generates an inductively defined function on a W-type using the cases given in the body. For example, Listing 11  13  shows the relevant part of code that generates the W-type.
We prioritized writing declarative rules in logical frameworks in order to minimize the amount of user-written Scala code that has to be trusted. In particular, we used a plugin to operationalize declarative specifications by generating rewrite rules in Section 4. But we could still do better by dynamically generating more complex rules from appropriately tagged declarations. For example, we could generate typing rules to handle unification hints or soft typing. It is unclear if this is already possible or requires adaptations of the MMT kernel. Finally, MMT has prioritized making the prototyping fast rather than the prototype: it focuses on making prototypes usable (flexible notations, error messages, IDE, etc. ) and just fast enough for interactive case studies. While MMT rules are fast because they are written in a mainstream programming language, MMT loses speed by explicitly dispatching to these rules (rather than using the dispatch mechanism of the underlying programming language).
Acknowledgments The rewriting case study from Sect. 4 was inspired by a collaboration with  Gilles Dowek  and the  Dedukti team. The LLF P case study from Sect. 5 was carried out with Ivan Scagnetto during the Dagstuhl Seminar 16421 on Universality of Proofs. The linear logic case study from Sect. 6 benefited from discussions with  Kaustuv Chaudhuri. The authors were supported by  DFG  grant  RA-18723-1   OAF  and  EU  grant  Horizon 2020 ERI 676541  OpenDreamKit. MMT implementation and documentation are available at https://uniformal. github. io/. Online references for all case studies are given in the text.
Nevertheless, it significantly relies on the virtualization infrastructure for security. Among the many known aspects of the cloud-native and edge security  [1]   [2] , the protection of the virtualization infrastructure and the platform integrity are the focus of this work. We propose a trusted edge computing infrastructure based on Arm edge devices. In addition, we add attestation exten-sions to OpenStack  [3]   [4] , one of the most widely adopted open-source cloud managers. The combination of a remote attestation integrated into the infrastructure management software and a trusted pool of devices brings a secure and trusted virtualized edge. As part of this work, we perform a series of measurements showing the trade-off between performance and increased security. The experiments are conducted using standard virtual machines (VMs), showing the worst-case scenario in terms of instantiation (boot) times, however, the same concept is still applicable when working with unikernels or containers.
Worth to mention hardware technologies that are based on these specifications are outlined next. • Intel Trusted Execution Technology (TXT)  [10]  aims to provide a root of trust and verify the integrity of a platform by relying on a TPM. During boot, it performs measurements on the platform components (boot loader, firmware, hypervisor, operating system) and verifies them against pre-calculated white list values. • Intel SGX or Intel Software Guard Extensions  [11]  is an extension for Intel processors architecture which enables the use of protected areas of execution in memory, called enclaves. It makes an application code executing within the enclave protected even when the firmware or operating system are compromised. • Arm TrustZone  [12]  implements a TEE as a system-wide approach to security.
Other sensitive operations such as key storage and cryptography tasks are also commonly performed inside the Secure World  [13]. In addition to the hardware technologies, a number of software implementations of the Global Platform TEE exist. The commercial works are not of interest to this paper, while a short overview of the open-source ones is presented here. Open Portable Trusted Execution Environment (OP-TEE)  [14]  meets the GlobalPlatform TEE System Architecture specification and provides the TEE Internal Core API and TEE Client API. Other available implementations include Open TEE led by the Secure Systems group as part of their activities at the Intel Collaborative Research Institute for Secure Computing  [15]  and T6 which targets mobile devices using Arm hardware security extensions  [16].
III. TRUSTEDVIM The proposed solution in this work is called Trusted Virtualized Infrastructure Manager (TrustedVIM). It supplements the management capabilities of OpenStack with attestation extensions integrated directly into the OpenStack Compute (Nova) project. The key component is the compute infrastructure which is based on Arm TrustZone enabled hosts and OP-TEE where all the security services are isolated and safely executed inside a TEE. Relying on this framework, OpenStack compute nodes are being authenticated before cloud services such as virtual machines (VMs), unikernels or potentially containers  [17]  can be run on them, this way avoiding manin-the-middle or device replacement attacks. Furthermore, the operating system kernel is checked for unknown modifications, detecting malicious activities and a trusted boot ensures that the trustworthiness of the system is propagated throughout all software layers.
The base for the compute nodes trust verification is the security services running on the hosts. The trusted compute infrastructure is made of Arm TrustZone-enabled nodes running VOSYSMonitor  [18]. This is a thin monitoring software layer developed by Virtual Open System which manages the interaction between two execution worlds on a single Systemon-Chip. This mixed-critical infrastructure provides each node with an isolated environment for storing and running sensitive data and applications. Each host has two execution environments, called a Normal World and a Secure World. The Normal World hosts a rich operating system, Linux in the case of this work, where the nova-compute services and the guest VMs are running. Meanwhile, the Secure World works with OP-TEE to provide a secure environment for the critical tasks of the Normal World.
B. OP-TEE Security services Verifying that a compute node is not compromised is a challenging goal. However, some mechanisms can be put in place to detect infection symptoms. Having in mind this problem, the following services are implemented to take countermeasures: • Secure boot is a security mechanism applied to verify the trustworthiness of the software during each stage of the device boot process. It is implemented as a chain of trust starting from a hardware root of trust and propagates up to the user-space. • Node authentication is performed before starting the communication with a compute node. The OpenStack Controller uses a "Challenge-response" protocol, based on asymmetric cryptography, to verify that the compute node is actually the one that it is claiming to be. This is a fundamental service to avoid man-in-the-middle attacks.
• Kernel integrity check: in order to interfere with the execution of a VM a malicious software (commonly referred to as malware) has to gain high privileges. Usually, an infection of the kernel space is needed. The main malware category that aims at this are the so-called "Rootkits". One common technique used by rootkits is to tamper the kernel code to perform malicious actions. A valid countermeasure is a run-time integrity check of the kernel code memory. Although this doesn't prevent the execution of a Rootkit but only the detection of it, this information is valuable for the OpenStack Controller that can mark the infected node as not trusted and take countermeasures. These services can be implemented in normal user space but this will be insecure. In order to explain it, we model an attack as a generic rootkit.
Rootkits can tamper any application in the user and kernel space including the above security services. Here comes in help the hardware isolation provided by Arm TrustZone. By implementing the security services as OP-TEE applications inside the Secure world, they cannot be affected by software running in the Normal World and are protected from malware and rootkits. Meanwhile, through the Global Platform Client API a client software running in the Rich OS can ask OP-TEE for the safe execution of these services.
C. Implementation details In this subsection, the different parts of the TrustedVIM architecture are explained in terms of their implementation. The Trusted OpenStack extensions are implemented as part of the Nova project with more details following. Together with the OP-TEE security services, they form the two main features of our work, namely, host authentication and kernel integrity check. 1) Trusted Boot: A system's security cannot be guaranteed if it does not start from the moment of power-on. The trusted boot is the basis for the trustworthiness of the upper software layers in this work. It is accomplished by the vendor-specific secure boot mechanism relying on a hardware root of trust and is propagated to the Linux user-space by U-Boot's verified boot  [19]. U-boot is an open-source boot loader available for multiple computer architectures (Arm, x86, etc.
). The boot process is multi-staged and starts from the boot read-only memory (ROM) and the first-stage boot loader (FSBL). After the FSBL is determined as secure, it loads U-Boot which on its turn verifies the signature of the Linux kernel image and only then loads the operating system. 2) Attestation service: Nova-scheduler is one of the internal components of OpenStack Nova and is part of the flow for provisioning a new VM instance. By default, the novascheduler is configured as a filter scheduler. Filtering is a mechanism inside Nova for making decisions about where a new instance should be created. During this process the scheduler iterates through all compute nodes, evaluating each against a set of filters. The list of resulting hosts is ordered by weights and is used to select the one that meets all VM requirements.
The OpenStack Controller knows the public key of all the compute nodes, while all the compute nodes know the public key of the OpenStack Controller. Obviously, the private key is known only by the actor itself. Thanks to this, it is possible to exchange a packet composed of the following elements: • The encrypted message: thanks to this secrecy is granted since only the receiver can decrypt the content of the message. Moreover, the presence of a nonce makes ineffective reply attacks. • The signature of the message: this acts as a Message authentication code (MAC). It guarantees the authenticity and integrity of the packet By following this protocol, we achieve a secure communication secure channel that allows end-to-end encryption between the OpenStack Controller and the OP-TEE operating system.
Since the interface between user and kernel space goes entirely through this interface, it is mandatory to verify the integrity of this table to avoid tampering of those. • vectors: in the Arm architecture whenever an exception occurs the processor switches the execution to the correct entry in the vector table. This table is also critical for safety and it should not be never changed. Thanks to OP-TEE it is possible to verify at run-time that these tables content is not modified. To perform this it is sufficient to compute the digest of these tables and verify that it is exactly as the one expected. OP-TEE embeds in its code the digests of the tables computed offline using the verified kernel image. Figure  4  summarizes the steps of this integrity check.
The trusted implementation is 0. 253 seconds (∼ 2%) slower on average but looking at the detailed statistics, it can be seen that the minimum and median values are only slightly affected. The main difference comes from peaks into the measurements visible in the graphical representation on Figure  6. This can be explained by fluctuations of the connectivity speed and is a basis for future improvement. The topic of trusted computing pools is being explored by Intel in a combination with the OpenAttestation project (OAT)  [25]  and OpenStack. Their work is based on Intel TXT which creates a Measured Launch environment (MLE) on power-on  [10]. Intel TXT relies on a TPM as a hardware root of trust and for storing the measurements. Compute nodes based on Intel TXT are combined with a remote attestation software to provide Trusted computing pools to OpenStack.