dataesr/scientific-paragraphs-categorization huggingface dataset:
The Userspace Components: Beignet and libdrm The Open Computing Language (OpenCL) is an open standard for parallel programming of heterogeneous systems. OpenCL allows the parallel programming of modern processors found in personal computers, servers and mobile devices. Beignet  [2]  is an open source OpenCL implementation for Linux supporting two Intel processors: Ivy-Bridge and Haswell. Beignet is composed by two main components: the OpenCL runtime and the Just-in-Time compiler. The runtime consists of a dynamic library which implements the OpenCL API. The Just-in-Time (JIT) compiler uses LLVM to implement the OpenCL C language compiler and to translate the code of the kernel into the ISA of the IGD. The kernel code is compiled through JIT because the OpenCL programs should be device-independent and could be executed on any hardware platform, supported by OpenCL.
Direct Rendering Manager The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for the interface with the GPU. The DRM exposes an API that user space programs can use to send commands and data to the GPU, and perform operations like memory allocation on the GPU memory. Graphics drivers may also use DRM functions to provide a uniform interface to applications for memory management, interrupt handling and DMA. While user-space applications can interact directly with the GPU through ioctls, in many cases developers use the more high-level interface provided by the libdrm library. The DRM supports two memory managers: the Translation Table Maps (TTM) and the Graphics Execution Manager (GEM). In this paper we focus on the GEM, which is used by the Intel graphic driver.
The Intel Graphic Driver The Intel graphic driver, called i915 in the main branch of the Linux kernel, implements a superset of the ioctls defined in the DRM layer (we used the version 3. 14 of the Linux kernel in our experiments). The IGD is controlled by the CPU in two ways: through a set of memory-mapped IO registers, and through the ringbuffers, a set of queues containing the list of commands to be executed on the IGD. In particular, in Haswell there are three different types of ringbuffers: the render, the blitter, and the bitstream buffers. Any application which uses the GPU is called a GPU client. Before submitting a job to the GPU, each client sends a hardware-context creation request to the Intel graphic driver. Hardware contexts are opaque objects which are used to manage context switches between clients.
The graphic card has a specially-reserved area of memory that is not accessible from the CPU. This section is called Graphic Stolen Memory (GSM) and consists of two contiguous ranges, which are configured by the BIOS: the Graphics Translation Tables (GTT) range that stores the virtual to physical graphic translation tables and the Data Range which is a programmable space, used to store graphics data (e. g the framebuffer). A special register called Base of GTT Stolen Memory (BGSM in the Figure ) points to the base address of the GSM. The TOLUD register marks instead the top of the low usable physical memory that is accessible to the CPU. The only way for the CPU to read the GTT memory is through MMIO on the PCI BAR0 of the graphic card. A MMIO on the PCI BAR2 -which is also called the Graphics Aperture -is used to access the Data range.
Indeed, the driver only cares of preserving the coherency between the GGTT and the PPGTT. In this case, the virtual address in the CPU domain continues to point to the original physical page, while the GPU address now points to any arbitrary page in memory. To show the feasibility of this attack we performed a simple test. Our experiment includes a victim application V which contains some sensitive data in a memory area B victim. This application does not use the video card. At the same time, a malicious application M invokes the OpenCL library function clCreateBuffer() to allocate a buffer B dummy of 1024 bytes. The malware then loads a kernel module that performs a number of tasks. First, it finds the physical address of B victim and B dummy and locates the Intel GPU in the PCI device list.
Second, it retrieves the pointer to the MMIO address of the beginning of the Graphic Stolen Memory through the struct drm i915 private data structure. Then, the module scans the two levels of the PPGTT to find the entry pointing to the physical address of B dummy and modifies the entry to point to the physical address of B victim. At this point, the malware unloads and removes the kernel module from the system. Finally, M prepares a kernel task K to overwrite the content of B dummy (that in the IGD domains points to B victim ), it compiles it using the Beignet JIT compiler, and sends it to the video card. Using this technique the malware forced an inconsistent memory mapping between the Linux page table and the GPU page table. An investigator looking at the system memory would see that the process M is using the GPU and that his kernel task has access to a buffer, which still correctly points to the harmless B dummy.
Findings and Discussion Table  1  summarizes the main findings of our study. The first column shows the different techniques we proposed in this paper and that can be used by malware to increase the complexity of a memory forensic examination. The second column shows the requirements of such malware: U for user privileges, S for superuser privileges, and K for super-user privileges with an additional knowledge of the GPU driver internal data structures. On the right side of the table we summarize the consequences for memory forensics, grouped around the three main objective of listing the processes that use the GPU, understanding which kernel code is executed by each of them, and listing the memory ranges that are accessible to such kernels. Memory forensic involves two separate processes: memory acquisition and memory analysis.
Summary and Guidelines As part of our experiments, we developed a set of custom tools and volatility plugins to retrieve a number of information from the system and GPU memory. In particular, from a forensic perspective, we collected and parsed the following data structures: Graphic page tables: this artifact can be used to detect the presence of inconsistent memory map in the system. For IGDs, the Graphic Translation Table (GTT) and Per-Process GTT (PGTT) can be dumped through mmio on the GPU PCI BAR2. Hangcheck flag: This flag is stored in the driver and, as described in the previous section, can be very important to detect sophisticated attacks. List of buffer objects: together with the graphic page tables, these artifacts can be used to detect which memory pages can be accessed by a process, passing through the GPU.
In the case of GEM, this information consists of two doubly-linked lists that can be obtained from the struct drm i915 private. List of contexts: this artifact can be used to get information on the GPU kernels and understand which processes are using the GPU. In IGDs this can be done through the context list field in the struct drm i915 private data structure. Register file: it contains information on the internal state of the GPU and can be accessed through mmio on GPU PCI BAR0. Among the IO registers the RING TAIL and the RING HEAD deserve a special mention. These registers are used to control how the ringbuffer is accessed by the CPU and can be very useful for the analyst to understand if there were any tasks running during the acquisition process.
Beyond our Case Study The variety of GPU ecosystem poses a big challenge for the forensic community. In the worst case, a different tools should be developed for each possible combination of GPU model and Operating system. Nonetheless, for what concerns Linux, the presence of the DRM layer can ease this task. Other than the Intel driver, also other drivers (e. g. tegra, nouveau, radeon,. ) are compliant with both the DRM and the GEM memory manager. For such drivers, most of our considerations remains the same. For other closed-source drivers, more work is required to reverse-engineer their internal data structures. Few additional observations can be done by looking at Table  1. For example, the information stored in the system memory (marked with the sign in the table) are likely to be the same for most GPUs.
Some PoC tools are more invasive and they prevent the kernel from loading additional drivers  [14]. The goal of anti-analysis techniques is instead to prevent the correct analysis of the memory dump. They perform DKOM to prevent the memory analysis tools from finding some fundamental kernel variables which are used as starting point for the analysis (e. g. the KDDEBUGGER DATA64 data structure). Haruyama et al. [7]  show how the modification of one-byte on some kernel variables can break the memory analysis process. Stuttgen et al. [20]  show that hooking memory enumeration and memory mapping API can hinder the analysis. This is substantially different from the Incosistent Mapping presented here. Indeed, even in the presence of the improved memory acquisition technique proposed in  [20] , the GPU page table would be marked as not safe to dump and the modified mapping would not be detected.
GPUs can be used as both an anti-acquisition and anti-analysis technique. Indeed, the non-preemptive nature of GPUs can be leveraged to prevent the memory acquisition process of the GPU memory itself. Pixelvault  [22]  locks the GPU to protect the key mate-rial, the same mechanisms can be used to prevent the memory scanner from getting the dump of the GPU memory. Furthermore, since GPUs are not considered during the memory-forensic analysis by current tools, using the GPU to run malicious code can prevent the correct analysis of the memory dump.
There are currently no software solutions that offer both local ancestry inference using dense marker data and disease association statistics. Results: We present here an R package, ALDsuite, which accounts for local LD using principal components of haplotypes from surrogate ancestral population data, and includes tools for quality control of data, MALD, downstream analysis of results and visualization graphics. Conclusions: ALDsuite offers a fast, accurate estimation of global and local ancestry and comes bundled with the tools needed for MALD, from data quality control through mapping of and visualization of disease genes.
Several software packages, ADMIXMAP, ANCESTRYMAP and STRUCTURE, provided good estimates of global ancestry (i. e. the proportion of ancestors from each admixing population for an individual), as well as statistics for association between phenotype and local ancestry (i. e. the population each haplotype was inherited from at a particular locus)  [10] [11] [12]. These early software packages were limited in their ability to analyze dense marker sets, due to their reliance on the lack of local LD among sampled markers. This reliance on sparse marker sets results from the additional complexity involved with the modeling of local LD. An attempt was made in one software package, SABER, to model 2-way LD of a marker with its immediate neighbors, but this was later shown to allow bias into the model from higher order local LD with more distantly linked markers  [13, 14].
The consequences of this bias include a tendency to overestimate the divergence of admixing populations and possible inference of significant admixture in unadmixed individuals  [3]. Two recent software packages, HAPAA and HAPMIX, have modeled local LD in a Bayesian framework similar to that used for genotype imputation, with very good results  [15, 16]. These methods, however, can be computationally intensive, especially with increasingly dense marker sets  [3]. Other recent algorithms, including LAMP-LD, MULTIMIX and RFMix, have mainly focused on local ancestry inference using disjoint haplotype blocks  [17] [18] [19]  (see Table  1  for a list of all currently available ancestry inference software). While this approach is much more computationally efficient and scales well with increasing marker density, many regions do not segregate well into haplotype blocks.
Samples from modernday surrogate populations chosen to represent ancestral, admixing populations are analyzed in the PCA, and PCs accounting for 80% of the observed variation are chosen to model the likelihood of each ancestral population within each window. The transformation of the genotype data using the PC loadings from the l th surrogate ancestral population is illustrated in Equation 1 where the principal component matrix for a window is the matrix multiplication of the phased haplotype matrix, A (one row per chromosome, one column per marker in the haplotype) with the eigenvector matrix, v: PC l (A) = Av l. ( 1 ) A logistic Principal Component Regression (PCR) is then performed to infer the likelihood of each ancestral state within each window as a function of these PCs, and the regression coefficients are used as starting points for local ancestral state probability calculation in the HMM.
Statistical association Local and global ancestry estimates across the genome are reported for each individual. With this information the user can use one of several statistical association techniques for mapping disease genes and/or fine mapping of disease-associated loci. When mapping disease genes by ALD, an association with local ancestry at a locus is the primary association being tested. The caseonly regression model, defined in Equation  6 , compares the difference between local ancestry and global ancestry. Other data (e. g. case-control) can be similarly modeled as defined in Equation  7. In both of these models, regions with statistically significant regression coefficients for local ancestry are inferred to harbor disease modifying genes. global ancestry ∼ β 0 + β 1 (local ancestry) + β 2 (covariates) (6) link(Y ) ∼ β 0 + β 1 (local ancestry) + β 2 (global ancestry) + β 3 (covariates) (7) When a disease locus is identified, a fine mapping analysis is needed to identify specific variants most strongly associated with the disease outcome.
Results and discussion While sparse marker panels are more cost effective and have proven powerful in the detection several important disease risk genes, dense data provide more accurate ancestry inference and a finer resolution of recombination points  [13]. One strategy that has been used is to follow up a MALD study with fine typing around an associated locus  [43]. With ALDsuite both sparse and dense marker data are analyzed in combination, resulting in better global ancestry estimates, while being able to infer local ancestry on a much finer scale in areas of particular interest. This program should increase the utility of dense marker datasets available from many large cohort studies that include African Americans. ALDsuite provides accurate inference of local ancestry, while indirectly modeling local, higher order LD remaining from ancestral populations.
The analysis of our simulation resulted in 96. 3% accuracy of local ancestry inference, compared to the 98. 1% accuracy of PCAdmix and the 98. 7% accuracy of MULTIMIX, which is on par with other leading analysis software  [16, 32]. Comparison of chromosomes from an analysis of the ASW population using ALDsuite, MULTIMIX and PCAdmix also shows a good degree of concordance between the methods used (see Figure  2 ). One striking difference between the results shown in Figure  2  are the differing window sizes. The binning of markers in MULTIMIX and PCAdmix is done by arbitrarily grouping a fixed number of markers into each bin. In more densely sampled areas, such as those closer to the center of the chromosome, the window sizes are quite small, while other less densely sampled areas have much larger window sizes.
The region at the beginning of the chromosomes in Figure  2 , for example, cover as much as 4 cM. Binning of markers in ALDsuite is done by genetic distance, rather than the number of markers, creating a more constant window size across the genome. In more densely sampled regions, this helps maintain better computational properties, since fewer windows can be used to cover the same region, while in sparsely sampled regions a more precise estimate of the boundaries of ancestral haplotypes can be obtained. Another key feature of ALDsuite that all other densemarker admixture software lacks is direct access to statistical methods needed to map disease phenotypes. Not only does ALDsuite provide utilities directly supporting admixture mapping and fine mapping studies (see Implementation section), but many other proposed methods can be easily implemented in R, using the output provided by ALDsuite  [44] [45] [46].
Conclusion Admixture inference software can be categorized using a few different metrics including the number of admixing populations it can simultaneously infer, the way it models local LD when analyzing dense marker data, the number of admixing populations it will simultaneously infer and support of disease gene mapping (see Table  1 ). There are currently no software solutions which both offer analysis of dense marker data from more than two admixing populations and disease association statistics, requiring the use of several software programs, often with very different input and output data formats. ALDsuite offers a fast, accurate estimation of global and local ancestry with the tools needed from data quality control through mapping of disease genes, along with the rich statistical and graphical utilities provided with R.
Acknowledgements This project has been funded in whole or in part with federal funds from the  National Cancer Institute, National Institutes of Health , under contract  HHSN26120080001E. The content of this publication does not necessarily reflect the views or policies of the  Department of Health and Human Services , nor does mention of trade names, commercial products, or organizations imply endorsement by the  U. S. Government. This Research was supported [in part] by the  Intramural Research Program  of the  NIH, National Cancer Institute, Center for Cancer Research.
These test data are generated from scratch using step-wise transformations and assuring that certain constraints (a. k. a. metamorphic relations) hold at each step. To show the feasibility and generalizability of our approach, it has been used to automatically test several analysis tools in three variability domains: feature models, CUDF documents and Boolean formulas. Among other results, we detected 19 real bugs in 7 out of the 15 tools under test. KEY WORDS: Metamorphic testing, automated testing, software testing, software variability either at the problem or at the solution level. At the problem level, variability is managed in terms of features or requirements, using VMs such as feature models  [35] , orthogonal variability models  [51]  or decision models  [59]. At the solution level, variability is modelled using domain-specific languages such as Kconfig in Linux [8], p2 in Eclipse  [39]  or WS-Agreement in web services  [47].
Some examples are the FaMa framework [28] and the SPLAR tool  [45, 58]  in the context of feature models; the CDL [64] and APT [21]  package configurators in the context of operating systems; or the dependency analysis tool integrated into Eclipse  [39]. Variability analysis tools are complex software systems that have to deal with also complex data structures and algorithms, e. g. the FaMa framework has more than 20,000 lines of code. Analysis operations are usually far from trivial and their development is error-prone, increasing development time and reducing the reliability of analysis tools. In this context, the testing of variability analysis tools aim at detecting faults that produce unexpected analysis results. Roughly speaking, a test case in the domain of variability analysis is composed of a VM as the input, and the expected result of the analysis operation under test as the output.
INTRODUCTION Modern software applications are increasingly configurable, driven by customer demands and dynamic business conditions. This leads to software systems that need a high degree of variability, i. e. the capability to be extended, changed, customized, or configured to be used in a particular context  [60]. For example, operating systems such as Linux or eCos can be configured by installing packages, e. g. Debian Wheezy, a well-known Linux distribution, offers more than 37,000 available packages  [22]. Modern software ecosystems and browsers, configurable in terms of plugins or extensions, are another example of software variability, e. g. the Eclipse Marketplace currently provides about 1,650 Eclipse plugins  [26]. Recently, cloud applications are becoming increasingly flexible, e.
• CUDF documents. These VMs are textual documents used to describe package-based Free and Open Source Software distributions  [2, 61]. We present four metamorphic relations for CUDF documents and an associated test data generator. For its evaluation, we automatically tested two analysis operations, including an upgradeability optimization operation, in 3 CUDF reasoners. We detected 2 faults. • CNF formulas. Among its applications, Boolean formulas in Conjunctive Normal Form (CNF) are extensively used for variability representation and analysis at a low level of abstraction. Many VMs such feature models or decision models can be automatically analysed by translating them into CNF formulas and solving the Boolean satisfiability problem (SAT)  [7, 59]. Also, SAT technology is used to deal with variability management in software ecosystems such as Eclipse or Linux  [37, 39].
Five metamorphic relations for CNF formulas and a test data generator relying on them are presented in this article. For its evaluation, we automatically tested the satisfiability operation in 9 SAT reasoners. We detected 5 faults. In quantitative terms, this article extends and generalizes our previous works by automating the detection of faults in two new variability domains, CUDF and CNF formulas. Also, we present 10 new metamorphic relations (out of 14) and a thorough empirical evaluation with more analysis operations (from 6 to 22), tools (from 2 to 15) and detected faults (from 4 to 19). The rest of the article is structured as follows: Section 2 introduces the variability languages used in our empirical evaluation as well as a brief introduction to metamorphic testing. Section 3 presents the proposed metamorphic relations for the variability languages under study.
CUDF documents The Common Upgradeability Description Format (CUDF) is a format for describing variability in package-based Free and Open Source Software (FOSS) distributions  [2, 61]. This format is one of the outcomes of the Mancoosi European research project  [43] , intended to build better and generic tools for package-based system administration. CUDF combines features of the Red Had package manager and the Debian packaging systems, and also allows to encode other formats such as metadata of Eclipse plugins  [39]. A key benefit of CUDF is that it allows to describe variability independently of the distribution and the package manager used. Also, the syntax and semantics of CUDF documents are well documented, something that facilitates the development of independent analysis tools. Fig.
The default value is false. In Fig. 2 , package arduino is installed while the package php5-mysql is not. The CUDF document concludes with a so-called request stanza which describes the user request, i. e. the changes the user wants to perform on the set of installed packages. The request stanza may include three properties: a list of packages to be installed, a list of packages to be removed and a list of packages to be upgraded. Version constraints are allowed in all cases. In the example, the user wishes to install the packages apt, apmd and kpdf version 6 and remove the package php5-mysql. The automated analysis of CUDF documents is mainly intended to solve the so-called upgradeability problem  [2]. Given a CUDF document, this problem consists in finding a valid configuration, i. e. a set of packages that fulfils all the constraints of the package stanzas and fulfils all the requirements expressed in the user request.