dataesr/scientific-paragraphs-categorization huggingface dataset:
Then, the Wasm binary is distributed to all edge nodes, where it is compiled to a sandboxed machine code (x86 or ARM). This machine code is executed at every service request. having one single responsibility. This development model is known as serverless computing, or function-as-a-service  [14] ,  [9]. Figure  1  summarizes the development and deployment process for a client application to an edge-cloud platform. First, the developers of a client application implement the isolated services in a given programming language. The source code and the HTTP harness are then compiled to WebAssembly using, e. g. with LLVM  [15]  or Binaryen  [16]. When client application developers deploy a WebAssembly binary for a function-as-a-service, it is sent to all edge nodes in the platform. Then, the WebAssembly binary is compiled, on each node, to machine code.
A. Overview The goal of MEWE is to provide moving target defense (MTD) for WebAssembly binaries. It performs MTD at the application-level without any change in the operating system or Wasm runtime. The core idea of MEWE is to combine the synthesis of diversified function variants with execution-path randomization. Figure  2  provides an overview of how it works. MEWE takes as input a binary that is to be diversified. The implemented binary format is LLVM's intermediate representation (LLVM IR), it can be obtained from any language with an LLVM frontend such as C/C++, Rust or Go. In Step 1 , the binary is passed to CROW  [17] , which is a superdiversifier for Wasm, it generates a set of variants for the functions in the binary. Step 2 packages all the variants in one single multivariant LLVM binary.
In Step 3 , we use a special component, called a "mixer", which augments the binary with two different components: an HTTP endpoint harness and a random generator, which are both required for executing Wasm at the edge. The harness is used to connect the program to its execution environment while the generator provides support for random execution path at runtime. The final output of Step 4 is a standalone multivariant WebAssembly binary that can be deployed on an edge-cloud computing platform. In the following sections, we describe in greater details the different stages of the workflow.
B. Variant generation MEWE relies on the superdiversifier CROW  [17]  to automatically diversify each function in the input llvm binary (Step 1 ). CROW receives an LLVM module, analyzes the binary at the function block level and generates semantically equivalent variants for each function, if they exist. CROW variants are verified as semantically equivalent with an SMT solver. Here, we define a function variant as: Definition 1: Function variant: Let F be a function, F is a function variant of F for MEWE if it is semantically equivalent (i. e. , same input/output behavior), but exhibits a different internal behavior through tracing. In Listing 3, we illustrate two semantically equivalent Wasm functions according to Definition 1. The left most listing corresponds to the Wasm module shown in Listing 2.
The right most listing is a variant for this function. We can appreciate that the multiplication of the original code, in the third and four lines, is replaced by an addition, making the variant to have the same semantic but executing different instructions. CROW synthesizes variants by enumerative synthesis based on code transformation. The most relevant transformations are: constant inferring to replace control flow statements, arithmetic's equivalent replacement, and loop unrolling. CROW performs stacked transformations, this means that it can synthesize variants of different size, i. e. , from smaller to larger variants than the original. The variants created by CROW are artificially synthesized from the original binary. CROW checks for semantic equivalence of both codes, original and variant using the symbolic execution.
D. MEWE's Mixer The MEWE mixer has four specific objectives: wrap functions as HTTP endpoints, link the LLVM multivariant binary, inject a random generator and merge all these components into a multivariant WebAssembly binary. We use the Rustc compiler  1   Rustc is a compiler able to merge custom Rust source code with arbitratry-compatible LLVM binary. For the generator, we rely on WASI's specification  [19]  for the random behavior of the dispatchers. Its exact implementation is dependent on the platform on which the binary is deployed. For the HTTP harnesses, since our edge computing use case is based on the Fastly infrastructure, we rely on the Fastly API 2  to transform our Wasm binaries into HTTP endpoints. The harness enables a function to be called as an HTTP request and to return a HTTP response.
E. Multivariant Binary Execution at the Edge When a WebAssembly binary is deployed on an edge platform, it is translated to machine code on the fly. For our experiment, we deploy on the production edge nodes of Fastly. This edge computing platform uses Lucet, a native WebAssembly compiler and runtime, to compile and run the deployed Wasm binary  3. Lucet generates x86 machine code and ensures that the generated machine code executes inside a secure sandbox, controlling memory isolation. Figure  4  illustrates the runtime behavior of the original and the multivariant binary, when deployed on an Edge node. The top most diagram illustrates the execution trace for the original of the endpoint bin2base64. When the HTTP request with the input "HelloWorld!" is received, it invokes functions f 1, f 2 followed by 27 recursive calls of function f 3.
F. Implementation The multivariant combination (Step 2 ) is implemented in 942 lines of C++ code. Its uses the LLVM 12. 0. 0 libraries to extend the LLVM standard linker tool capability with the multivariant generation. MEWE's Mixer (Step 3 ) is implemented as an orchestration of the rustc and the We-bAssembly backend provided by CROW. For sake of open science and for fostering research on this important topic, the code of MEWE is made publicly available on Github https://anonymous. 4open. science/r/fastly4edge-C532  4 V. EXPERIMENTAL METHODOLOGY In this section we introduce our methodology to evaluate MEWE. First, we present our research questions and the services with which we experiment the generation and the execution of multivariant binaries. Then, we detail the methodology for each research question.
B. Study subjects We select two mature and typical edge-cloud computing projects to study the feasibility of MEWE. The projects are selected based on: suitability for diversity synthesis with CROW (the projects should have the ability to collect their modules in LLVM intermediate representation), suitability for deployment on the Fastly infrastructure (the project should be easily portable Wasm/WASI and compatible with the Rust Fastly API), and possibility to collect their execution runtime information (the endpoints should execute in a reasonable time of maximum 1 second even with the overhead of instrumentation). The selected projects are: libsodium, an encryption, decryption, signature and password hashing library which can be ported to WebAssembly and qrcode-rust, a QrCode and MicroQrCode generator written in Rust.
E. RQ2 Diversity Preservation After Compilation After a WebAssembly binary is uploaded to the Edge platform, it is translated to machine code. In the case of Fastly, the Lucet's code generator processes the WebAssembly binary to generate x86 machine code. This machine code is the one executed every time a user requests the service. Lucet's performs some normalization and optimization passes when translating from Wasm to x86. Thus, some variants synthesized by CROW might not be preserved, i. e. , Lucet could generate the same machine code for two Wasm variants. In RQ2, we check that these translation passes preserve the variants synthesized by CROW. We retrieve the multivariant call graph for both code representations, Wasm and x86. Then, we compute the number of possible execution paths in each version of the graph.
H. RQ5 Performance For each endpoint listed in Table  II , we measure the performance impact of the multivariant binaries created by MEWE with the following metric: Metric 3: Execution time: For a deployed binary, the execution time is the backend-space time between the receiving of the user request to the returning of the function as the response. We refer to the backend-space as the time measured directly in the edge node, i. e. , we instrument the code measure the time for the endpoint execution. We collect 100k execution times for each binary type, original and multivariant. We perform a Mann-Withney U test  [20]  to compare both execution time distributions. If the P-value is lower than 0. 05, the distributions are different.
If the original execution path contains function for which MEWE is able to generate variants, then, there is a combinatorial explosion in the number of execution paths for the generated Wasm multivariant module. The increase of the possible execution paths theoretically augments the uncertainty on which one to perform, in the latter case, approx. 140 000 times. As Cabrera and colleagues observed  [17]  for CROW, a large presence of loops and arithmetic operations in the original function code leverages to more diversification. Looking at the #Dispatchers and #Variants columns of the 'Multivariant WebAssembly binary' section of Table  II , we notice that the number of variants generated per function greatly varies. For example, for both the invert and the bin2base64 functions of Libsodium, MEWE manages to diversify 2 functions (reflected by the presence of 2 dispatcher nodes in the multivariant call graph).
B. RQ2 Results. Compile-time diversity preservation We translate each WebAssembly multivariant binary with Lucet, to determine the impact of this translation to machine code on the function variants and the diversity of paths in the multivariant call graph. The 'x86 code' section of We identified where the optimizations are done in Lucet's compiler,  6. It performs optimization-like transformations that are simpler than the ones introduced by CROW. With this result we also encourage to avoid the usage of the insertion of nop instructions either in Wasm or machine code. nop operations could be easily detected and removed by a latter optimization stage. Moreover, the last three endpoints have a path preservation ratio that is less than 0. 25, even with more than 87% of individual function variants that are preserved.
In other words, someone who runs these services over and over with the same input cannot know exactly what code will be executed in the next execution. These very high entropy values are made possible by the millions of random choices that are made along the execution paths of these endpoints. While there is a high degree of diversity among the traces exhibited by each endpoint, they all have the same length, except in the case of random. This means that the entropy is a direct consequence of the invocations of the dispatchers. In the case of random, it naturally has a non-deterministic behavior. Meanwhile, we observe several calls to dispatchers in during the execution of the multivariant binary, which indicates that MEWE can amplify the natural diversity of traces exhibited by random. For each endpoint, we managed to trigger all dispatchers during its execution.
05 with a Mann-Withney U test). In particular, in all cases, the distributions for multivariant execution times are spread over a larger range of values than the original binary. This phenomenon is a direct consequence of the execution path randomization. The choice of function variant is randomized at each function invocation, and the variants have different execution times as a consequence of the code transformations, i. e. , some variants execute more instructions than others. Consequently, the time for one endpoint execution is randomized and the distribution of a series of endpoint execution is more spread with the multivariant binary than with the original.
Second, MEWE interconnects hundreds of variants and several randomization dispatchers in a single binary, increasing by orders of magnitude the runtime uncertainty about what code will actually run. By executing in parallel two or more functionally equivalent variants it is possible the detection of inconsistencies during runtime. If one of the variants is compromised due to a potential attack, the system can detect it and halt or report the error  [26] ,  [27]. Voulimeneas et al. recently proposed a multi-variant execution system by parallelizing the execution of the variants in different machines  [28] , their usage of heterogeneous ISAs also increases the diversity between variants. MEWE randomly selects the variants at runtime, increasing the unpredictability of execution behavior. The detection of anomalies by executing variants in parallel is done after the potential attack is performed while MEWE is a preemptive technique.
Narayan et al. [9]  remarked that the security model of We-bAssembly for edge-cloud computing platforms is still is vulnerable to Spectre attacks. This means that WebAssembly endpoint sandboxes can be hijacked to leak memory. They proposed to modify the Lucet compiler used by Fastly to incorporate fence instructions in the machine code generation, trying to avoid speculative misstraining. Johnson et al. [29] , on the other hand, proposed a static SFI checking of the WebAssembly binaries before they could be submitted to the edge-cloud platforms. MEWE uses a preemptive technique, it is not meant to tackle known vulnerabilities. Besides, MEWE is agnostic from the last-step compiler that translates Wasm to machine code, which means that the multivariant binaries can be deployed on any edge-cloud platform that can receive WebAssembly endpoints.
There are significant previous work in the space of moving target defenses. Taguinod et al. [30]  and Christodorescu et al. [31]  proposed to diversify different layers of web applications by using preexisting diversity. In the same machine, they constantly switch the application's logic between SQL database engines and web servers implemented in different languages such as PHP, Python, Java and Ruby. Similarly, Roy et al. [32]  harnessed diverse machine learning algorithms for the same classification task at the Edge, creating a moving target defense against adversarial learning attacks. These works try to break reconnaisance stages from potential attackers. The usage of preexisting variants limits the diversification space. MEWE creates artificial diversity instead of using preexisting variants.
However, as previous works remarked, it does not protect yet against application-level attacks. MEWE is the counterpart, it provides runtime diversification and provides a practical MTD for edge-cloud platforms, at software level. VII. DISCUSSION Specialising, optimizing, improving performance In section IV we validated the key features of MEWE: automatically generate multivariant binaries, which exhibit random execution paths at runtime. Several aspects of these procedures can be optimized. For example, the generated code can be optimized by inline function variants in the dispatchers. This minimal change will decrease the number of function calls. On the other hand, the number of times a dispatcher is called can be bound. As discussed in RQ4 and RQ5, the dispatchers are massively invoked at runtime, which is great for randomization, but also a challenge with respect to the execution time of the services.
Fuzzing and security The diversification created by MEWE can unleash hidden behaviors in compilers like Lucet. One "holy grail" in the fuzzing of compilers is the ability to reach latter stages in the machine code generation pipeline. By generating several functionally equivalent, and yet different variants, deeper bugs can be discovered. During the writing of this work, an error was discovered during the execution of one of the variants provided by MEWE. Fastly acknowledged our work as part of a technical blog post that describes the bug and the patch. The link to the post will be provided with the deanonymized version of this paper. MEWE is platform agnostic: Several components of MEWE are implemented to operate at the level of the LLVM intermediate language. These components are compatible with other LLVM frontend and backend.
Furthermore, we intend to engage with study registration sites (EU-PAS, ClinicalTrials. gov, ISPOR-ISPE-Open Science Framework RWE Registry) to address registration of comprehensive protocols for RWE studies that estimate causal effects of clinical or policy interventions. On EU-PAS, the longest established registration site for observational studies, 57% of studies were registered without a protocol. 5 e work stream of this task force was specifically aimed at setting expectations regarding what needs to be in a study protocol to ensure more reproducible and reliable results. However, addressing key issues in protocol registration  61  and having policies that support it as an expectation for the field has potential to increase the ability of end-users to evaluate RWE study quality and therefore, their utility for decision-making.
ACKNOWLEDGMENTS Shirley V. Wang  and  Sebastian Schneeweiss  were supported by  NIH :  NHLBI RO1HL141505  and  NIA R01AG053302. Nicole Pratt  was supported by  NHMRC   GNT1157506  and  GNT1196900. Sinead Langan  was supported by a  Wellcome Trust   Senior Research Fellowship in Clinical Science  ( 205039/Z/16/Z ). This research was funded in whole or in part by the  Wellcome Trust  ( 205039/Z/16/Z ). For the purpose of Open Access , the authors have applied a CC BY public copyright license to any Author Accepted Manuscript (AAM) version arising from this submission. We would like to thank  ISPE  and  ISPOR  for their support and endorsement of this work.
Introduction Electromagnetic (EM) modeling routines play a key role in studying and interpreting subsurface electric conductivity distribution. They are widely used in academia and industry because of their capacity to reduce ambiguities in interpreting geophysical datasets through mapping conductivity variations in the subsurface. As a result, there are abundant schemes to implement 3D EM forward modeling algorithms (see Avdeev  [1] , Börner  [2]  for a detailed review). For inversion of EM datasets, a large number of forward modeling computations are needed. Therefore, 3D EM modeling (and inversion) algorithms should be particularly sought for: (i) Providing accurate solutions in a feasible run-time, although the uncertainties associated with domain discretization and numerical approximations still exist.
g. , transmitter vicinity). To increase the  order on specific regions without sacrificing computational performance, we consider a constant number of dof per element. To compute synthetic EM responses, we have used the PETGEM code  [12] , which has been shown as an efficient modeling routine on massively parallel computers. We point out that our numerical scheme and its results are independent of the electric field formulation (e. g. total or secondary field formulation), transmitter type (e. g. electric or magnetic dipole), transmitter signal (e. g. time-harmonic, direct current or transient), and conductivity material properties (e. g. isotropic or anisotropic). Still, to preserve brevity, we particularized our study to 3D CSEM modeling for marine and land applications in the context of energy reservoirs characterization (oil & gas, and geothermal) based on synthetic and experimental data.
Parallel implementation The supervised adaptive mesh refinement scheme described in the previous section has been implemented in a fully distributed fashion (MPI standard) using Python language and mpi4py  [31]. Our implementation is based on and extends the PETGEM code. The algorithm supports general anisotropic cases and takes advantage of the inherent features within PETGEM for parallel computations. This section only provides a brief outline for understanding the HPC implementation. For a comprehensive introduction to the PETGEM code and its computational performance, we refer to Castillo-Reyes et al. [12] , Castillo-Reyes et al. [15] , Castillo-Reyes et al. [32] , Castillo-Reyes et al. [33]. The PETGEM workflow is composed of four main phases: preprocessing, assembly, solver, and post-processing.
The first one is responsible for providing functions to change input data related to mesh (ℎ-refinement) into a more suitable representation for PETGEM. These are, in particular, the nodal spatial coordinates, the mesh connectivity, and boundary conditions. Further, additional information needed for handling matrix storage allocation is retrieved here. The assembly phase encapsulates information and functions coming from the HEFEM and -refinement. This phase particularly comprises the computation of the curl-conforming basis functions and the computation of the elemental FE matrices. Further, in the solver phase, the system of linear equations is solved directly using MUMPS  [34]  or iteratively via the petsc4py package  [35]. These libraries offer a large selection of parallel iterative Krylov solvers and multifrontal direct methods.
ℎ-adapted meshes for a synthetic marine layered model As a second example, we assess the performance of the ℎ-adapted meshes. More concretely, we perform a convergence test to determine the number of nodes per skin-depth   and the resolution number   required to design ℎ-adapted meshes that satisfy a given error threshold. For this experiment, we consider a VTI synthetic layered model that consists of 3. 5 km of air layer ( air = 10 8 Ω m), 1 km of seawater ( sea = 0. 3 Ωm), followed by 2 km of sediments with VTI ( h = 4 Ωm and  v = 6 Ωm), and finally 1 km of isotropic basement ( basement = 1000 Ωm). We execute our simulations in parallel with 480 processors. The system of equations is solved using the PETSc implementation of the GMRES solver. The reference solution for a 3 Hz -directed dipole transmitter is computed semi-analytically using the empymod code  [40].
Acknowledgments The work of O. C-R. has received funding from " HPC Technology Innovation Lab ", a  Barcelona Supercomputing Center  and  Huawei  research cooperation agreement ( 2020 ). O. C-R. has been also 65% cofinanced by the  European Regional Development Fund (ERDF)  through the  Interreg V-A Spain-France-Andorra program  ( POCTEFA2014-2020 ). POCTEFA aims to reinforce the economic and social integration of.
Code availability The PETGEM code is freely available at the home page (petgem. bsc. es), at the PyPI repository (pypi. org/project/petgem), at the GitHub site (github. com/ocastilloreyes/petgem), or by requesting the author (octavio. castillo@bsc. es, ocastilloreyes@gmail. com). In all cases, the code is supplied to ease the immediate execution on Linux platforms. User's manual and technical documentation (developer's guide) are provided in the PETGEM archive.
B. The MOUSEWORLD testbed The second integration is with the Mouseworld testbed  [14]. Its reference architecture, depicted in Figure  3 , follows the Digital Twin Network (DTN) concept proposed by the network management research group (NMRG) of the IRTF  [15]. The Mouseworld testbed is employed to generate realistic labelled datasets that feed the ML Orchestrator in order to train ML models applied to both offensive and defensive tools employed in the SPIDER cyber range exercises. Mouseworld relies on the ETSI Open Source MANO (OSM) orchestrator stack to provision both VNFs and CNFs on top of OpenStack and Kubernetes Virtualized Infrastructure Managers (VIMs). The Service Mapping Model component is in charge of the instantiation of the network twin leveraging on a set of interconnected virtualization servers, allowing the independent execution of multiple scenarios, and the generation of the associated traffic and telemetry.