dataesr/scientific-paragraphs-categorization huggingface dataset:
In the present study, hippuric acid was often associated with its closest precursor 4-hydroxybenzoic acid (Fig. 4 , hydroxybenzoic acids, compound #07), which itself was one of the most commonly reported metabolites in the database. This compound, like 3-and 4-hydroxyphenylacetic acids, is a product of microbial polyphenol metabolism  [26, 27]  and could account for substantial proportions of the ingested polyphenol doses. This is illustrated by the many pathways associating more particularly parent hydroxycinnamates, flavanols, and flavonols with various phenolic acid metabolites shown in Fig. 4  (hydroxypentanoic acids, hydroxypropanoic acids, hydroxyphenylacetic acids, and hydroxybenzoic acids). In particular, many of these microbial metabolites are formed from various phenolic precursors (see Fig.
3) The finite element method has been used to determine the crack-tip parameters T and K for the an arc of pipe specimens. The structures are modeled by CASTEM 2000 code in two dimensions under plane strain conditions using free-meshed isoparametric quadrilateral elements, with quarter-point singularity elements at the crack-tip. Only one half of the test apparatus has been modelled due to symmetry in the geometry and loading conditions. The mesh generated for the elastic analyses comprises 31485 elements and 63526 nodes. The arc of pipeline fracture specimen geometry is illustrated in Fig. 2a. A fan-like mesh focused at the crack tip (on the plane perpendicular to the crack front, see Fig. 2b ) is employed because this yields more accurate T-stress values. Furthermore, a detailed mesh sensitivity study has shown that further refinement  In Eq.
3 ≤ λ ≤ 2. 8 µm) every 30 s and averaged every half-hour. According to the manufacturer the sensors have an intrinsic accuracy of ±3 %. In turn, the albedo, calculated as the ratio between SW out and SW in , has a compounded accuracy of about 4 %. Nevertheless, the local slope, the tilt of the de- vice, and frost deposition on the sensor can increase the uncertainty. At Mera Glacier the AWS collected data from 9 November 2009 to 10 November 2010 and from 27 November 2012 to 16 November 2013. At Chhota Shigri Glacier the AWS collected data from 13 August 2012 to 2 February 2013 and from 8 July 2013 to 3 October 2013 (Fig. 4 ). Snow and ice albedo are highly sensitive to cloud cover, which affects the ratio of direct and diffuse radiation (e. g. ,  Warren, 1982; Gardner and Sharp, 2010). Therefore, we filtered the data to retain only those collected in clear-sky conditions to be able to compare them to satellite-retrieved albedo.
MOD10A1 products Daily MODIS/Terra Snow Cover Daily L3 Global 500 m SIN Grid (MOD10A1, referred hereafter as MOD10), processed and distributed by the National Snow and Ice Data Center, are available at http://nsidc. org (Hall et al. , 2006). The products provide an estimate of daily blue-sky (BS) albedo, which corresponds to the broadband albedo for the actual direct and diffuse illumination, daily snow cover, and a quality assessment (QA) at 500 m resolution  (Klein and Stroeve, 2002). The daily albedo is calculated from the daily MODIS reflectances corrected from the atmospheric effects (MODIS/Terra Surface Reflectance Daily L2G Global 500m SIN Grid; MOD09GHK). The adjustment of snow and ice anisotropic scattering effects is done using a DIScrete Ordinates Radiative Transfer model (DISORT).
MCD43 products MODIS MCD43A3 products provide white-sky spectral albedo (WS albedo, which corresponds to the albedo of the surface illuminated only by diffuse irradiance), black-sky spectral albedo (which corresponds to the albedo of the surface illuminated only by direct irradiance), and broadband albedo (called WS shortwave albedo), for the seven visible and near infrared bands of MODIS at local solar noon. MCD43A3 products are produced at 500 m resolution every 8 days using 16 days of MODIS Terra and Aqua acquisitions. The separate products MCD43A2 are used to provide quality assessment for the MCD43A3 products. These data are available through the online data pool at the NASA Land Processes Distributed Active Archive Center (https: //lpdaac. usgs. gov/).
MODImLab products MODImLab is an algorithm developed to provide snow and ice albedo with a 250 m resolution  (Sirguey et al. , 2009; Dumont et al. , 2012). It retrieves albedo in mountainous regions from MODIS TOA calibrated radiances corrected with topographic and atmospheric data (see Table  1  for a complete list of inputs and their availability). MODImLab supports both BS albedo and WS albedo, as well as a cloud mask derived from MODIS reflective and emissive bands. We filtered the albedo products to keep only those calculated from images acquired with a sensor zenith angle lower than 40 •. For a complete description of the albedo retrieval method, the reader is referred to  Sirguey et al. (2009) ,  Sirguey (2009) ,  Dumont et al. (2011), and Dumont et al. (2012).
0. 15 for MOD10. Thus the MOD10 albedo retrieval appears to be biased towards lower values at the Mera site. This is in contradiction with other studies that found a bias toward higher values in MOD10 data (e. g. ,  Şorman et al. , 2007). The mean absolute errors are 0. 10 for MODImLab and 0. 16 for MOD10 data. In conclusion, MODImLab and MOD10 retrievals seem to have the same quality in the context of this study. Nevertheless, given the higher spatial resolution of MODImLab and the ability of its cloud detection algorithm to better detect clouds, we choose to mostly rely on MODImLab products for our analyses.
Comparison of cloud masks The performances of the cloud masks calculated by MOD-ImLab and that provided by the MOD35 Cloud product (and used in MOD10 products) were compared through a visual inspection of 13 ASTER images with variable cloud coverage (Table  2 ) covering the Mera Glacier area and corresponding to a total of 13 312 and 3328 pixels for the 250 and 500 m resolutions, respectively (Fig. 6 ). MODIS and ASTER images were acquired at the same time (no more than 5 minutes apart), and were compared using four categories, taking the ASTER mask determined by visual inspection as a reference: - Reference data were obtained via visual interpretation of clouds in simultaneous ASTER images. Category 1 corresponds to cloudy pixels detected as cloudy pixels, category 2 to cloudy pixels detected as cloud-free pixels, category 3 to cloudfree pixels detected as cloudy pixels and category 4 to cloud-free pixels detected as cloud-free pixels.
Albedo and annual glacier-wide mass balance The mean albedo of a glacier has been recognized as being a potentially good proxy for the transient snow line altitude because of the contrast in albedo between snow and ice  (Dumont et al. , 2012). Among selected Alpine glaciers regularly surveyed, the altitude of the transient snow line reaches a maximum at the end of the ablation season which corresponds to the ELA  (Rabatel et al. , 2005). In turn, the mean albedo of the glacier surface reaches a minimum and can effectively be used as a proxy to estimate the ELA. We processed daily MODIS data from May 2000 to December 2013 for the two glaciers. Daily maps of WS albedo were calculated for the two glaciers and averaged over cloudfree glacierized pixels for images with a cloud coverage over the glacier lower than 20 % for Chhota Shigri Glacier and 0 % for Mera Glacier (Figs.
2  and 3 ). WS albedo does not depend on solar zenith angle, and is thus a more relevant variable than BS albedo to compare albedo maps generated at different dates, and therefore with different solar illumination. Variations in WS albedo can be interpreted more readily as a variation in characteristics of the surface. Following  Dumont et al. (2012)  we extracted the minimum value of the albedo signal for the period corresponding to the end of the ablation season of Chhota Shigri Glacier. From field observations and precipitation regime, the snow line was expected to be at its highest elevation between late July and late September. Consequently, we processed images systematically from July to December and only partially for the rest of the year to reduce the amount of L1B data to be downloaded and processed.
Limitations of the optical remote sensing in the study area In this study we first assessed the quality of remotely sensed albedo retrieval techniques using ground-based AWS data, which is rarely possible in the HKH region due to the difficulty in glacier access. Nevertheless, we stress that a direct comparison between satellite products and contemporaneous AWS data is complicated by the inconsistent foot- The relatively high rate of misclassification of cloudy pixels (33 %) in MOD10 products raises questions about the significance of the calculated decadal trend. In addition to the sampling problem associated with the persistent cloud coverage during winter time on Chhota Shigri Glacier and monsoon season on Mera Glacier, the observed decadal trends might not be related to changes in the glacier surface, but could also be related to changes occurring in the atmosphere or due to a drift in MODIS sensors calibration (e.
Acknowledgements. This work has been supported by the  French Service d'Observation GLACIOCLIM , the  French National Research Agency (ANR)  through  ANR-09-CEP-005-01 - PAPRIKA , and  ANR-13-SENV-0005-04-PRESHINE  , and the  French National Space Center (CNES)  through TOSCA and ISIS projects, and has been supported by a grant from  Labex OSUG@2020  (Investissements d'avenir - ANR10 LABX56 ). LTHE, CNRM-GAME/CEN and LGGE are part of LabEx OSUG@2020. This study was carried out within the framework of the Ev-K2- CNR  Project in collaboration with the  Nepal Academy of Science and Technology  as foreseen by the  Memorandum of Understanding between Nepal and Italy , and thanks to contributions from the  Italian National Research Council , the  Italian Ministry of Education, University and Research  and the  Italian Ministry of Foreign Affairs.
This work has been conducted in ICIMOD and LTHE, which are greatly acknowledged for their support. JMS is supported by the  Cryosphere Monitoring Project , which is funded by the  Norwegian Ministry of Foreign Affairs  through the  Norwegian Embassy in Kathmandu. The authors are grateful to  Kimberly Casey  and  Thomas Painter  for their valuable comments which greatly improved an earlier version of this work. Edited by:  A. Kääb.
x[p]=y Assign a graph element y to a port p > 0 of an agent node x. x  [0] =α Change the id of an agent node x into α. push(x,y) Create an equation of two graph element x, y in the stack of equations. stackFree() Dispose of the top element of the equation stack. In this Agent structure, each symbol α 1 ,. , α n for agents is distinguished by a unique id. The length of port corresponds to the number of auxiliary ports of an agent. The stack of equations EQ is initially empty. Intuitively, an element of this stack can be written using the following code fragment in C: typedef struct Equation { Agent *a1; Agent *a2; } Equation; The interface I is a node arrays of fixed size n as the size of the observable interface of a net can be pre-determined (and it is preserved during execution). By using LL0, we encode Simpler calculus.
, e n , N) • We define a translation Compile c from a configuration ( u | Θ ) with a symbol set Σ into a code string c as follows: Compile c (Σ, ( u | Θ )) def = let c 0 = Compile s (Σ); (c 1 , N) = makeN(Name( u | Θ )); c 2 = Compile es (Θ, N); c 3 = Compile i ( u, N); in c 0 + c 1 + c 2 + c 3 end; • We write just Compile when there is no ambiguity. r (α( x) = β ( y) ⇒ Θ) def = let N l = Compile rn ( x, L, / 0); N r = Compile rn ( y, R, N l ); (c 1 , N) = makeN'(Name(Θ) -{ x, y}, N r ); c 2 = Compile es (Θ, N); in "rule {α} {β } {" +"stackFree()" +c 1 + c 2 +"free(L)" + "free(R)" + "}" end; Compile rn ((x 1 ,. , x n ), LR, N) def = let N 0 = N; N 1 = (N 0 (x 1 ) := {LR}[1]);. N n = (N n-1 (x n ) := {LR}[n]); in N n end; Example  13  The results of Compile r (Add(x 1 , x 2 ) = Z ⇒ x 1 = x 2 ) and Compile r (Add(x 1 , x 2 ) = S(y) ⇒ Add(x 1 , w) = y, x 2 = S(w)) are as follows: Back-end of the compilation.
This pushes two agents onto the equation stack. This corresponds to the following code: pushActive(x,y); • stackFree(). This disposes of the top element of the equation stack. In the translation result, it occurs in rule procedures. In this implementation, the function popActive manages the index of the equation stack, and thus no code is required. Next we manage the translated LL0 instructions for rule procedures. A rule procedure in LL0 such as "rule Alpha Beta" is encoded as a function that is named as Alpha Beta, takes two pointers *a1 and *a2 to two elements of the equation, and creates nets according to interaction rules. The special variables L and R in the rule procedures are denoted as *a1 and *a2, and thus L  [1] , L  [2] ,. , R  [1] , R  [2] ,. are expressed as: a1->port  [0] , a1->port  [1] ,.
The protection against those attacks is necessary to ensure that secrets do not leak, and most secure elements are thus evaluated against those attacks. Usual certifications are the common criteria (ISO/IEC 15408), the FIPS 140-2 (ISO/IEC 19790), or proprietary schemes (EMVCo, CAST, etc. ). Power analysis. It is a form of side-channel attack in which the attacker measures the power consumption of a cryptographic device. Simple Power Analysis (SPA) consists in directly interpreting the electrical activity of the cryptosystem. On unprotected implementations it can for instance reveal the path taken by the code at branches even when timing attacks  [KJJ96]  cannot. Differential Power Analysis (DPA)  [KJJ99]  is more advanced: the attacker can compute the intermediate values within cryptographic computations by statistically analyzing data collected from multiple cryptographic operations.
This method consists in automatically inserting the countermeasure and formally proving that the induced code transformation is correct (i. e. , semantic preserving). • We present a formal method (using symbolic execution) to statically prove the absence of power consumption leakage in assembly code provided that the hardware it runs on satisfies a finite and limited set of requirements corresponding to our leakage model. • We show how to characterize the hardware to run the DPL protocol on resources which maximize the relevancy of the leakage model. • We provide a tool called paioli 1 which implements the automatic insertion of the DPL countermeasure in assembly code, and, independently, is able to statically prove the power balancing of a given assembly code. • Finally, we demonstrate our methods and tool in a case study on a software implementation of the present [BKL + 07] cipher running on an 8-bit AVR micro-controller.
Generation of DPL Protected Assembly Code Here we present a generic method to protect assembly code against power analysis. To achieve that we implemented a tool (See App. A) which transforms assembly code to make it compliant with the DPL protocol described in Sec. 2. 2. To be as universal as possible the tool works with a generic assembly language presented in Sec. 3. 1. The details of the code transformation are given in Sec. 3. 2. Finally, a proof of the correctness of this transformation is presented in Sec. 3. 3. We implemented paioli 1 using the OCaml 3  programming language, which type safety helps to prevent many bugs. On our present case-study, it runs in negligible time ( 1 second), both for DPL transformation and simulation, including balance verification. The unprotected (resp.
Formally Proving the Absence of Leakage Now that we know the DPL transformation is correct, we need to prove its efficiency security-wise. We prove the absence of leakage on the software, while obviously the leakage heavily depends on the hardware. Our proof thus makes an hypothesis on the hardware: we suppose that the bits we use for the positive and negative logic in the DPL protocol leak the same amount. This may seem like an unreasonable hypothesis, since it is not true in general. However, the protection can be implemented in a soft CPU core (LatticeMicro32, OpenRISC, LEON2, etc. ), that would be laid out in a Field-Programmable Gate Array (FPGA) or in an Application-Specific Integrated Circuit (ASIC) with special balancing constraints at place-and-route. The methodology follows the guidelines given by Chen et al.
We present how to characterize the targeted hardware to make use of the resources which maximize the relevancy of our leakage model to run the DPL protocol. We then applied our methods using our tool using an implementation of the present cipher on a real smartcard, which ensured that our methods and models are relevant in practice. In our case study, the provably balanced DPL protected implementation is at least 250 times more resistant to power analysis attacks than the unprotected version while being only 3 times slower. These figures could be better. Indeed, they do not take into account hardware characterization which helps the balancing a lot, as we were able to see with the "cheating attacker". Moreover, we have used the hardware characterization data grossly, only to show the added-value of the operation, which as expected is non-negligible.
A paioli The goal of paioli 10  (Power Analysis Immunity by Offsetting Leakage Intensity) is to protect assembly code against power analysis attacks such as DPA (differential power analysis) and CPA (correlation power analysis), and to formally prove the efficiency of the protection. To this end, it implements the automatic insertion of a balancing countermeasure, namely DPL (dual-rail with precharge logic), in assembly code (for now limited to bitsliced block-cipher type of algorithms). Independently, it is able to statically verify if the power consumption of a given assembly code is correctly balanced with regard to a leakage model (e. g. , the Hamming weight of values, or the Hamming distance of values updates). The rest of this section details its features. Adapters. To easily adapt it to any assembly language, it has a system of plugins (which we call "adapters") that allows to easily write a parser and a pretty-printer for any language and to use them instead of the internal parser and pretty-printer (which are made for the internal language we use, see Sec.
3. 1) without having to recompile the whole tool. DPL transformation. If asked so, paioli is able to automatically apply the DPL transformation as explained in Sec. 3. 2. It takes as arguments which bits to use for the DPL protocol, the offset at which to place the pattern for look-up tables (for example, we used an offset of 1 to avoid resorting to the least significant bit which leaks differently), and where in memory should the look-up tables start. Given these parameters, the tool verifies that they are valid and consistent according to the DPL protocol, and then it generates the DPL balanced code corresponding to the input code, including the code for look-up tables initialization. Optionally, the tool is able to compact the lookup tables (since they are sparse), still making sure that their addresses respect the DPL protocol (Sec.
2. 2). Simulation. If asked so, paioli can simulate the execution of the code after its optional DPL transformation. The simulator is equipped to do the balance verification proof (see Sec. 4) but it is not mandatory to do the balance analysis when running it. It takes as parameters the size of the memory and the number of register to use, and initializes them to the set of two DPL encoded values of 1 and 0 corresponding to the given DPL parameters. The tool can optionally display the content of selected portions of the memory or of chosen registers after execution, which is useful for inspection and debugging purpose for example. Balance verification. The formal verification of the balance of the code is an essential functionality of the tool. Indeed, bugs occur even when having a thorough and comprehensive specification, thus we believe that it is not sufficient to have a precise and formally proven method for generating protected code, but that the results should be independently verified (see Sec.
To summarize, this paper makes the following contributions: • We conduct the first study of the impact of GPUassisted malware on memory forensics. In particular, we introduce four possible attack scenarios and discuss their impact for a forensic analyst. For each scenario we implement a different proof-of-concept for Linux and we report under what conditions the memory analysis can be performed through the kernel data structures, the video driver or the GPU memory • We present a detailed case study on Intel integrated GPUs, which are part of all modern processors. Our results show that an adversary can take advantage of these integrated GPUs to obtain full access to any memory page in the host. Even worse, we show how it is possible to obtain a persistent malicious code running on the GPU without any associated process running on the host.
Physical Memory acquisition The dump of the physical memory allows a forensic investigator to extract detailed information about the system state, its configuration, and possible malware infections. However, the amount of useful information that can be extracted from a memory dump strictly depends on the way the memory image is obtained. Modern open-source memory acquisition tools for Linux (such as LiMe  [12]  and pmem  [15] ) load a kernel module and perform the acquisition from kernel space. Both LiMe and pmem automatically select the address ranges that are associated to the main system memory by examining the iomem resource linked list in the Linux kernel and selecting only the address 2 To disambiguate between the operating system kernel and the GPU kernel, the second one will be typed in italic.
Anti-forensic Techniques The operating system, some of its core services (e. g. , X windowing system), and/or the graphic driver usually maintain a number of internal data structures that describe who is using the graphic card and which tasks have been scheduled for execution. Since all of this data resides in the system memory, it may seem that a properly designed memory forensic tool should be able to answer all our three questions without the need to access the GPU memory. In the next section we will see how this is indeed possible in most of the cases. However, malware developers do not need to always play by the rules, and therefore we investigate a number of possible anti-forensic techniques that could be used to reduce the footprint in the system memory. Unlimited Code Execution. Under normal conditions, executing code on the GPU requires a controlling process running on the host.
Case study: Intel GPUs Architecture GPUs can be broadly divided into two categories: (i) discrete GPUs with dedicated device memory and, (ii) integrated GPUs that use a portion of DRAM for graphics. For our analysis, we focus on the integrated GPU of Intel, namely the Intel Integrated Graphic Devices (IGDs). However, the concepts and ideas described in this paper can be also applied to other hardware and software configurations. In particular, in Section 6. 2 we will discuss how our findings can be extended beyond our case study. It is important to note that our study focuses on the Linux Direct Rendering Infrastructure (DRI), a framework to allow userspace applications to access graphics hardware  [6]. In DRI, a userspace application can talk to the graphic drivers in two ways: directly using ioctls or indirectly through the X server.
As it will be described in the following, OpenCL applications uses ioctls to interact with the GPUs. Therefore, in this work we focus on the former case. Nonetheless, in a different context the X server memory could also contain useful artifacts and therefore should also be analyzed to extract forensics information. Figure  2  shows a simplified view of the reference software stack. Note that we represented only the DRI's software components are involved in our study. In the following, we describe briefly each layer. The information contained in the current section has been obtained from several sources including the source code of i915. ko, the official documentation of Intel [8] and unofficial sources such as  [24].