dataesr/scientific-paragraphs-categorization huggingface dataset:
Code availability Figures 4-8 were produced in Matlab. Example code and auxiliary functions to (1) reproduce Figs. 4-6 and (2) run the automated QC checks on the database are available on GitHub (https://github. com/EJJudd/ SciDataSupplement). The paleocoordinates used to produce Figs. 7,8 were estimated using the plate model of Scotese and Wright 707 , implemented in G-Plates (Version 2. 2. 0) 729.
The FABLE Consortium was created in 2017, with the ambition to support countries in designing more ambitious, nationally autonomous, but globally aligned food and land-use strategies. Researchers from universities and national research centers have joined the Consortium, forming interdisciplinary country teams in Argentina, Australia, Brazil, Canada, China, Colombia, Ethiopia, Finland, Germany, India, Indonesia, Malaysia, Mexico, Norway, Russia, Rwanda, South Africa, Sweden, UK, and the USA. Other institutes with a more global lens-Sustainable Development Solutions Network (SDSN), International Institute for Applied Systems Analysis (IIASA), the Alliance of Bioversity International and the International Center for Tropical Agriculture (CIAT), and Potsdam Institute for Climate Impact Research (PIK)-provide support to country teams in the form of free transfer of existing modeling tools, development of new modeling tools, curated datasets, a platform for sharing experience among members, and methods and infrastructure to bridge the gap between national and global scales.
SI). We have developed a biodiversity indicator termed "land where natural processes predominate" that we use to compute the baseline area for this target, which is the union of three datasets: lowimpact areas  (Jacobson et al. 2019) , intact forest landscapes  (Potapov et al. 2017) , and key biodiversity areas (BirdLife International 2019). Climate targets are based on the Paris Agreement requirement of staying within 1. 5 °C of global warming, since the additional risks of 2 °C warming are now understood to be high, particularly for land-use and food systems  (Masson-Delmotte et al. 2018; Arneth et al. 2019). Our global targets are informed by the Integrated Assessment Models (IAM) scenario ensembles  (Popp et al. 2017a, b; Riahi et al. 2021; Rogelj et al. 2018 ) (cf. SI). Due to higher uncertainty in the required mitigation level from Land Use, Land Use Change and Forestry (LULUCF)  (Fyson and Jeffery 2019) , we consider separate targets for emissions from crops and livestock (agriculture), and emissions and removals from LULUCF.
FABLE Consortium members use different models depending on the team's modeling skills, model availability for their country, and policy questions  (Pye and Bataille 2016). Models used need to satisfy a set of minimum requirements: the ability to report on the evolution of imports and exports by agricultural commodity, to report on the evolution of the indicators used to monitor the achievement of the global targets (Table  1 ), and to compare a Current Trends pathway and a Sustainable pathway to highlight the impacts of the main actionable drivers of the systems. But to ensure that all country teams could quickly have access to a model for their country, we built a new modeling tool, the FABLE Calculator (Box 1). An important aspect is transparency. We focus here on four requirements: (1) the general documentation of the model is regularly updated and understandable by nonmodelers; (2) the model's source code is documented and publicly accessible; (3) each publication is accompanied by a public database that covers the key results and additional data necessary to analyze the results of the model (e.
g. , data on assumed productivity changes); (4) modelers inform stakeholders of limitations in model functionality, correct any flawed reasoning about the model, and identify where there is poor data and evidence to support decisions  (Nikolic et al. 2019). We acknowledge that this list of requirements is demanding in terms of practical model-based analysis work. Model simplicity certainly increases the model transparency and eases use of the model itself but sometimes stakeholders expect a very detailed representation of a sub-sector or a specific process. This requires finding the appropriate balance between adding model complexity, and still allowing a model's accessibility to many users. All FABLE Consortium members are encouraged to keep things as simple as possible when doing new model developments.
Box 1: the FABLE Calculator An Excel-based tool, the FABLE Calculator  (Mosnier et al. 2020) , has been created to quickly provide a model to each country team in the FABLE Consortium to make projections of their food and land-use systems up to 2050. It is a public mass-balance model that does not require programming skills, solves in a few seconds, and can test a wide range of parameters' values, resulting in millions of alternative pathways. The FABLE Calculator covers the main domains of food and land-use systems: food and nutrition security, land-use and land cover change, water use, some proxy indicators for biodiversity impacts, and GHG emissions from agriculture and land-use change. The agricultural sector is at the core of the model with the representation of > 60 products. Each country model is one Excel file that includes the national database, computation formulas, scenarios selection options, and a dashboard to monitor national targets.
FABLE can play an important role by making several datasets from different sources coherent with each other, e. g. , the land cover map obtained through satellite data and the agricultural production statistics, to build a coherent baseline model, which is the starting point for testing alternative sustainable pathways. This means that the same baseline model can be used to inform the climate mitigation strategy from agriculture and land (AFOLU), and the biodiversity strategy, so that they can be modeled together. The national FABLE models can thus identify synergies and trade-offs between the policy levers that can be used to reduce emissions from agriculture, increase land carbon sinks, and bend the curve of biodiversity loss  (Leclère et al. 2020). The FABLE approach can also facilitate the comparison and technical review of the submissions across countries, through standard reporting aligned with the international guidelines (comparability), the open model and documentation (transparency), and automatic verification and comparison of key model outputs with multiple benchmarks (accountability).
Progress toward global targets There are assessments of national pledges compared to the ambition and action required to meet the Paris Agreement targets, but they often exclude land-use change emissions due to large uncertainties and lack of reliable data  (Fyson and Jeffery 2019; Christensen and Olhoff 2019). Moreover, they come after the submissions of the revised NDCs and targets. The FABLE approach links the global ambition with national priorities, as well as the international trade dynamics that influence countries' courses of action, which can help countries prepare revisions of their NDCs, knowing in Fig. 2  The iterative bottom-up approach to ensure consistency between national and global scales 1 3 advance the remaining gaps to global climate targets. The FABLE approach can be used to discuss countries' contributions in light of the principle of common but differentiated responsibilities and respective capabilities (CBDR).
We are working on new model developments and linkages with open and complementary existing tools to fill these gaps. Assumptions on the evolution of future crop and livestock productivity have large impacts on the results and our capacity to meet all our sustainability targets. But what will be the extent of productivity growth, how this will be achieved, and how it will be impacted by more frequent climate shocks are subject to large uncertainties. Working with other modeling teams and the private sector to build open databases on improved technologies that could support the transformation of food and land-use systems would be of great value. Because socio-economic aspects are very sensitive for most governments, our priority will be to include the impacts of our pathways on jobs, production costs, and incomes.
International networks such as FABLE would benefit from more funding opportunities that aim at strengthening the science-policy interface, i. e. , ensuring a good balance between scientific innovation and policy impacts. The right incentives should be put in place to encourage researchers to make their work more transparent and freely available because it often implies compromising between academic and policy targets. For example, documenting the model and databases, engaging stakeholders, or training others require resources and time that may slow down production of publications and innovative model developments that remain at the core of the scientific performance evaluation.
Side channel attacks are powerful attacks for retrieving secret data by exploiting physical measurements such as power consumption or electromagnetic emissions. Masking is a popular countermeasure as it can be proven secure against an attacker model. In practice, software masked implementations suffer from a security reduction due to a mismatch between the considered leakage sources in the security proof and the real ones, which depend on the micro-architecture. We propose ARMISTICE, a framework for formally verifying the absence of leakage in first-order masked implementations taking into account modelled micro-architectural sources of leakage. As a proof of concept, we present the modelling of an Arm Cortex-M3 core from its RTL description and leakage test vectors, as well as the modelling of the memory of a STM32F1 board, exclusively using leakage test vectors.
A. Abstract Model As we have access to the Cortex-M3 RTL description through AAA, we go for a white-box approach to model the processor micro-architecture, which involves Verilog source files eye-ball analysis and Verilog simulations. 1) Under the Processor's Hood: The Cortex-M3 implements the ARMv7-M ISA composed of 32-bit and 16-bit instructions. It is a 3-stage pipeline processor comprising a Fetch, a Decode and one or two Execute stages depending on the instruction. As the Fetch stage does not manipulate data, we do not consider it further in the context of this paper. The main components found in the Cortex-M3 core, depicted in Fig. 2 , are: • A register file (RegFile), containing the general purpose registers (GPR), that has two read ports, named port A and port B, and one write port, named port D.
B. Sources of Leakage In this section, we present the leakage test vectors, or test vectors for short, designed in order to 1) confirm or disprove with experimental measurements our findings from the RTL analysis regarding the data path components involved in the execution of an instruction 2) quantitatively evaluate the leakage due to the different components and 3) analyse and model the memory subsystem using a black-box approach. 1) Experimental Setup: All measurements are performed on NewAE's ChipWhisperer Pro (CW1200) with a STM32F1 target board  [24]  embedding a Cortex-M3 configured to run at 7. 37MHz. The CW1200 acquires four samples per CPU cycle. Depending on the test vector, we acquire from 10,000 up to 500,000 power consumption traces, each with different random inputs generated with a Mersenne Twister RNG.
For each test vector, several specific t-tests are performed using the Hamming Weight of expressions composed of logical or arithmetic operations on the test vector's random input values (32-bit or less). A concluding specific t-test (i. e. with a tvalue higher than 4. 5) on the exclusive-or between expressions (e. g. , input values) shows that there is a transition leakage induced by a micro-architectural component between these expressions. An example is given in Lst. 3: it is composed of two exclusive-OR instructions (eor), each with different source GPR operands holding different random input values. The destination GPR operands are also distinct. We perform a specific t-test on the traces resulting from the execution of the code given in Lst. 3 to measure the interaction between the consecutive values of the first (resp.
4) Leakage Test Vector Suite: We have carefully designed 77 test vectors: 31 devoted to the analysis of the data path components involved in each class of instructions, 5 devoted to forwarding mechanisms, 7 devoted to writing back into the register file and 34 devoted to the analysis of the LSU and memory. Test vectors enable us to assess and confirm the potential leakage on the different buses and internal registers as well as leakage due to memory transfers in the Cortex-M3 core of our STM32F1 target. Contrary to the ARM processor core whose RTL must not be modified (apart from selecting some configurable options), the memory subsystem implementation varies between targets with an identical core  [17] : the (offcore) memory subsystem on our STM32F1 target is thus a black box. Test vectors dedicated to the memory and LSU enable us to model the memory subsystem.
As a consequence, the extraction is performed during a small amount of time on the data read in the previous cycle. This provokes some intra-word leakage in the first loaded data. • Write Side: Due to the duplication of data in case of byte (resp. half-word) write in the memory, a stored byte can interact with all other bytes (resp. aligned half-word) of the data sent to the memory in the previous cycle. When two store instructions are not issued in consecutive cycles, the stored bytes only interact with the ones at the same index in the previously read or written data. On our STM32F1 target, the DataOut bus seems to be reset between writes and there is, seemingly in the off-core memory, a one-word buffer which contains the last piece of data read or written, as explained next. • Read Write Interaction: Consecutive memory instructions (load-store, store-load), even separated by non-memory instructions, do interact.
III with a 3-stage pipeline (DEC, EXE1, EXE2). Modelled hardware components comprise GPR, internal CPU and memory registers, data memory as well as multiplexers and buses. At each simulation cycle, each modelled hardware component is updated according to the instruction processed in the corresponding pipeline stage. Note that the Arm ISA is a subset of the Arm Cortex-M3 one. Currently, the execution trace is generated using the symbolic engine angr  [26]. For the formal verification of symbolic expressions, we selected LeakageVerif which has been shown to be the most efficient, accurate and appropriate for verifying first-order probing security of expressions representing intermediate computations of masked software  [19]. Example: The example in Fig. 6  illustrates how symbolic expressions are constructed in both models, focusing on Port A and Port B for the Arm Cortex-M3 model.
Focusing on the components Port A and Port B, this creates the following two transitions: m1 → 0 and m0 → k ⊕ m0. The resulting expressions, respectively m1 and k, show that there is no secret leakage on Port A, but that a secret leakage in transition is present on Port B. The subsequent writes in r6 and r8 do not result in a secret leakage, as for the Arm ISA model. Back to the motivating example: Let us now consider again our software implementation of the ISW AND algorithm, with a C code implementation shown in Lst. 1, and its compiler-emitted assembly code from Lst. 2. The results of the ARMISTICE analysis on Cortex-M3 in the transition leakage model are reported in the tables from Fig. 7. The upper table displays, for each instruction, which micro-architectural elements are leaking, together with a link to the expression and the secret values (a, b, c) leaked by that expression in the lower table.
ARMISTICE is likely to detect leakages at ISA and micro-architectural level. We also select 4 Arm assembly-level masked implementations. Arm-Add and Arm-Add-opt are two masked implementations of an addition of two secrets split in two shares  [30]. They are provided as Arm assembly code and are, to the best of our understanding, designed to be masked in the first-order transition-based probing security considering GPR. ARMISTICE should then not detect leakages due to writes in the RegFile. Dil-And is a 32-bit masked logical AND and Dil-A2B is a 32bit conversion from arithmetic to boolean masking. These two functions are provided as part of a masking scheme of the Dilithium algorithm for the Cortex-M3  [31]. Both versions have been implemented using an enhanced version of the MAPS simulator.
B. Leakage Analysis For each benchmark, a verification is performed on both the Arm ISA and Arm Cortex-M3 processor models. Tab. 8 presents a synthesis of the analysis results for the Cortex-M3 processor model per benchmark. Namely, it gives for each modelled component of the Cortex-M3 the number of secret data leakages in the value-based leakage model (#VL column) and in the transition-based one (#TL column). As expected, the results for the GPR (line "R0 to R14") are the same, and so stand for both this model and the Arm ISA processor model, in which only the GPR are considered as sources of leakage. This also comprises values read from and written to memory as they necessarily pass through a GPR. At ISA level, for Secmult, AES-KS, AES-Herbst and AES-Yao, the analysis in the value-based leakage model confirms there is no leakage in the GPR, hence nor in memory, as claimed by their authors.
Unfortunately, the leaking expressions are too big for a manual analysis (more than 800 KB per leaking expression). Therefore, we rather performed a manual analysis of the leaking expressions reported for the Dil-And program. Both leakages on DataReg and ReadWriteBuffer happen when writing back in memory the two shares of the result. If the two stores have been separated by a logical instruction to clean the data path, this instruction does neither erase the content of the Data Reg, nor the one of the ReadWriteBuffer. Consequently, the two stores of the two shares reveal the secret results in these two hardware elements. We show in the next section that this secret leakage can be experimentally observed at the ARMISTICE's reported time in the power trace. These results show that the ISA level or the value-based leakage model are not good abstractions of the real power consumption.
Yet, future work includes understanding why such stall cycles occur. For the third experiment, we modify the assembly code of the previous experiment to remove all the possible secret leakages detected by ARMISTICE. Some of them, occurring in the memory, were not taken into consideration as they require modifying the memory data layout of the program. For each detected secret leakage, we add one or several instructions in order to clean the parts of the data path involved in the leaking transition. The added instructions can have three different kinds: for transitions happening in the arithmetic and logic data path, we use a orr lr, lr, lr instruction, not a nop neither a mov instruction, in order to be sure to clean regA and regB; for transitions happening in the AGU, LSU or memory, we use either a load or a store by making sure that the address is secret independent and that the value read or written is a constant; finally, for transitions happening in a GPR, we use a orr rX, lr, lr to erase the content of the register with a constant value before the new one.
Once all instructions are added, the new code is run again on ARMISTICE to ensure that no more leakage is found. Fig. 11  shows the t-test values obtained for all the expressions after patching the code: all leakages have disappeared. This second experiment shows how ARMISTICE can help designers remove all the potential secret leakages in a code,  by exhibiting the specific leakages, along with where and when they happen. This information allows ones to write the minimal code patch to remove such leaking transitions. The patched code can eventually be analysed by ARMISTICE in order to verify the absence of leakage. To conclude, ARMISTICE is a valuable tool that detects secret leakages happening during the execution of a masked software on a processor. It can also help patch a code to suppress leakages, and verify a patched code.
As shown in our paper, the decoding stage of the Arm Cortex-M3 processor induces different leakage effects depending on the binary encoding of the instruction, thus requiring as many instruction specifications as the number of encodings per instruction. Moreover, the user would have to explicit the instruction encoding in his implementation expressed in the scVerif's input language. A verification using the binary code as we propose seems more appropriate for avoiding putting the burden on the user. Finally, as scVerif executes sequentially the instructions, it cannot model the effects of the forwarding mechanism. Coco  [15]  is an approach for formally verifying if a masked software would securely be executed on a CPU. Leakages are searched for at gate-level, comprising glitches. Authors show several weaknesses in the RISC-V IBEX core related to the register file, ALU and LSU units that can be removed with small changes.
VII. CONCLUSION We presented ARMISTICE, a framework for formally verifying the absence of leakage considering first-order value-based or transition-based probing security in masked software implementations. Using an accurate model of a target core and memory subsystem, ARMISTICE allows to take into account microarchitectural leakages in the verification process. We presented the modelling of an Arm Cortex-M3 based STM32F1 board based both on a white-box analysis of the core and on a blackbox analysis of the memory subsystem via leakage test vectors. We experimentally showed that our modelling is relevant for detecting micro-architectural leakages as well as for manually removing them thanks to the ARMISTICE's output, comprising leaking instructions and hardware components where leakages stem from.
The signals from 4 pixels were combined during acquisition with SPCM software to give 127 × 127 pixels × 256 time channels images (48. 8 ps/time channel, 0-12. 5 ns time range, maximum intensity decay at 1. 33 ns; 13. 4 s/image; 104 µs/binned pixel). In vivo 3D multiphoton imaging: 2PEF-FLIM (4 time channels)/SHG z-stacks. Multiphoton imaging (DermaInspect™, Jenlab, Germany) was performed as previously described  45. For each experimental condition, we acquired two adjacent 3D z-stacks (70 images; 2. 346 µm z-step). Image characteristics: 511 × 511 pixels (0. 255 µm/pixel) × 4 time channels (2. 08 ns/time channel), 0-8. 33 ns time range (when acquiring 4 time channel images, the time range needed to be decreased from 12. 5 ns to a software predefined value of 8. 33 ns in order to achieve the ~ 2 ns temporal binning for the Pseudo-FLIM analysis), maximum intensity decay at 1.
We also apply an open area filter to remove the isolated regions of interest with an area smaller than the approximated 1 µm 2 melanosomal area. The influence of the temporal binning and of the maximum intensity peak position on Pseudo-FLIM results is described in supplementary materials and methods (Fig. S1 ). We implemented Pseudo-FLIM analysis with both Python in Multiphoton Skin Tools Suite (MPSTS) software  50  and using a home-written macro with Fiji/ImageJ. In vivo 3D automatic skin layers segmentation and constituents quantification. The global 3D analysis of z-stacks of combined 2PEF-FLIM (4 time channels)/SHG images was performed with MPSTS software  50  to identify skin layers, characterize DEJ 3D-shape and extract quantitative parameters on skin constituents and layers (Fig. 2 ; see Supplementary materials and methods).