dataesr/scientific-paragraphs-categorization huggingface dataset:
Basic resources Figure  7  shows the syntax of our Cerise program logic based on Iris. In this subsection, we present the underlying concepts of Iris used to define the Cerise program logic. We keep the presentation high level, and refer to  Birkedal and Bizjak [2022]  for a complete and pedagogical presentation of the Iris logic. We write iProp for the universe of propositions. These feature the standard connectives of higher-order logic and separation logic, including the separating conjunction * and the magic wand -- * (read as an implication). The proposition ⌈𝜙⌉ asserts that the pure proposition 𝜙 holds, where 𝜙 is a proposition from the meta logic. Iris assertions can be divided in two categories: ephemeral assertions and persistent assertions. Ephemeral assertions describe facts or resources that are available at a given point but might become false or unavailable later.
Informally, a word is safe if it cannot be used to break any previously established logical invariants. We will then prove that, as long as some arbitrary code only has access to safe machine words, its execution indeed preserves logical invariants. Interestingly, we can establish this result while staying within the framework of the Cerise program logic exposed in the previous section. This illustrates the generality of said program logic: verifying specifications for known programs or specifying the behavior of arbitrary code are only two of its possible applications.
Thus, being able to execute code within a memory region does not yield additional access to memory compared to what was available by simply reading the memory region (it only leads to additional machine behaviors). Is this definition of safety trivial? One might wonder whether the definition in Figure  9  is trivial, meaning that any machine word 𝑤 will in fact be considered safe. This is thankfully not the case; let us illustrate concrete cases where a memory word 𝑤 is not considered safe to share with unknown code. At a high level, E is not trivial because establishing E (𝑤) requires proving that a full execution of the machine, starting from 𝑤, preserves logical invariants. This requirement is not explicit in the definition, but comes from the definition of the Cerise program logic. The definition of V (𝑤) is also not trivial because, e.
It is important to note that the distinction between "known" and "adversary" code only exists at the logical level: there is no such distinction at runtime. We can have two components that have been verified separately, and that do not mutually trust each other. In this case, from the point of view of each component, the other component is considered as being the adversary. Additionally, we note that "adversary" code is meant to denote code that has not been independently verified, and as such can only be reasoned about using a universal contract, which holds for any arbitrary capability machine program. Alternatively, since the Cerise separation logic enjoys all the advantages of a higher-order separation logic, it also supports the composition of two verified components via abstract and modular specifications.
The rule follows directly from the definition of V for values of 𝑝 different from e; when 𝑝 = e, an additional application of the FTLR (Theorem 2) is required. Notice that the pre-condition of the rule matches the resources that one gets in the Adequacy theorem (Theorem 1) for the adversary region. When using the Adequacy theorem, we will thus be able to conclude that capabilities pointing to the adversary region are safe. Corollary 2 (Jump to a safe word 23 ). V (𝑤) -- * ⊲ ∀reg. updatePcPerm(𝑤); * (𝑟, 𝑣) ∈reg,𝑟 ≠pc 𝑟 ⇒ 𝑣 * V (𝑣) ⇝ • Corollary 2 gives us a specification for the execution of the machine after a jump to an unknown word 𝑤, assuming that 𝑤 is safe. Recall that updatePcPerm(𝑤) corresponds to the value of the program counter after jumping to 𝑤 (see the machine semantics in Figure  6 ).
REASONING WITH CAPABILITIES: TWO EXAMPLES In this section, we return to the motivational examples introduced in Section 2, and show how to prove that they enforce the desired properties, using Cerise's reasoning tools, laid out in the previous sections. Let us recall (on the right) the code for our buffersharing program, previously introduced in Figure  3. The labels code, data, secret and end denote addresses in memory. We wish to prove formally that the program can share the data between addresses data and secret (excluded), while protecting the integrity of the data at address secret.
Fortunately, invariants are persistent, so they remain available for proving the callback's safety. Then, let us name 𝑤 0 the contents of register r 0 : we get to assume V (𝑤 0 ) (as for the contents of other registers). By using Lemma 4 (the specification for the increment routine) with rules FragFrame and SeqFull, it is enough to prove the following goal, which asserts safety of the execution after passing control back to unknown code by jumping to 𝑤 0 : Goal: ⊢ updatePcPerm(𝑤 0 ); ∃𝑛. r 0 ⇒ 𝑤 0 * r 1 ⇒ 0 * r 2 ⇒ 𝑛 * * (𝑟, 𝑣) ∈reg,𝑟 ∉{pc,r 0 ,r 1 ,r 2 } 𝑟 ⇒ 𝑣 * V (𝑣) ⇝ • Informally, the increment routine returns to the unknown code by passing control to some unknown word provided in r 0 : it is safe to do so, since such word can be assumed to be itself safe. Formally speaking, we know V (𝑤 0 ), so we apply Corollary 2 which concludes the proof.
13. Program passing a read-only capability to unknown callee program prog is given access to the malloc and assert routines. The adversary program adv is given access to malloc. We assume that prog contains the code and a table that has been filled by a linker with capabilities giving access to the two routines. Likewise, we assume that adv contains its program and data (arbitrary integers and capabilities pointing to its own region) and a table filled by the linker with the capability to the malloc routine. Similarly to the first adequacy theorem, the theorem states that if the capability machine starts with the capability pointing to prog in the program counter, and if it has been proved in the program logic that the machine can run until completion, then the assertion flag is never modified.
DISCUSSION AND PERSPECTIVES In this paper we have introduced Cerise, a program logic for reasoning about a low-level capability machine. Moreover, we have shown how Cerise can be used to define a logical relation for reasoning about unknown code. Thanks to the logical relation and the fundamental theorem from Section 5, Cerise can be used for robust verification  [Sammler et al. 2020; Swasey et al. 2017] , i. e. , to verify correctness of software that interacts with unverified components. The Cerise program logic is the culmination of ideas used in a sequence of earlier papers  [Georges et al. 2021; Skorstengaard et al. 2018 Skorstengaard et al. , 2019a;; Van Strydonck et al. 2022 ] and this paper is intended to give an accessible and didactic introduction to Cerise and the application of Cerise to program verification in the presence of untrusted code, accompanied with new results on a heap-based calling convention and implementations of sophisticated object-capability patterns.
Throughout the paper we have introduced increasingly complex examples, which demonstrate how fine-grained abstractions can be implemented on a capability machine and reasoned about using Cerise. Our examples from Section 7 and Section 8 are modeled after examples from a paper about a high-level object capability language  [Swasey et al. 2017]. Because of the more low-level nature of our capability machine, we had to implement some abstractions ourselves (such as the calling convention in Section 7. 3) but we think it is otherwise fair to say that our examples faithfully represent the examples used by Swasey et al. , using the same granularity of encapsulation and attacker interaction. As such, this paper demonstrates that the low-level security primitives offered by our capability machine are expressive enough to implement high-level language abstractions, despite the stronger attacker model of a low-level adversary.
At the same time, the examples show that Cerise is expressive enough to reason about these abstractions. Cerise is the first instantiation of the Iris framework to such a low-level language and thus this work also demonstrates that the key features of Iris (such as guarded recursion, ghost state, and invariants) are equally applicable in this low-level setting as in the high-level settings they were originally intended for. The proof effort is similar to that of other Iris mechanizations, and took around two to three person years to finalize, including the full program logic, logical relations model and case studies. While using Cerise to verify the non-trivial dynamic sealing case study required a manageable proof effort (Cerise comes equipped with simple but useful tactical support for stepping through straight-forward instructions and for reasoning about address arithmetic, which is useful for the tedious but otherwise trivial parts of the proof), the user experience would be improved with support for more sophisticated automated reasoning.
Since Cerise is implemented in Iris, one could for example apply similar techniques to existing automation support in Iris  [Keuchel et al. 2022; Mulder and Krebbers 2023; Mulder et al. 2022; Sammler et al. 2021]. Since Cerise, we have seen more instantiations of low-level languages in Iris. For example,  Sammler et al. [2022]  present Islaris, which can used to verify machine code against authoritative ISA semantics of Armv8-A and RISC-V, and  Liu et al. [2023]  introduce VMSL, a novel separation logic, which can be used to reason about virtual machines which communicate through a hypercall API. To reason about stored code, the latter work introduces a new kind of weakest precondition (called single-step weakest precondition), which could probably be used to slightly simplify the formal treatment of stored code in Cerise.
In fact, we believe universal contracts offer a general and powerful approach for formalizing ISA security guarantees. Such security guarantees are stated in informal ISA specifications but they have not yet been incorporated in formal definitions of ISAs  [Armstrong et al. 2019; Bourgeat et al. 2021 ]. As such, a promising application of universal contracts like the one from Section 5 is to incorporate them into the ISA definition to formalize intended ISA security guarantees. Inspired by Cerise,  Huyghebaert et al. [2023]  have proposed a general method for verifying security guarantees in the form of universal contracts in separation logic on Sail specifications of ISAs, supported by a general verification tool called Katamaran. One of their case studies is a custom capability machine ISA called MinimalCaps which extends Cerise and for which they establish a very similar universal contract as ours, but they don't verify capability-machine assembly software as the ones shown in Section 8.
Earlier variants of Cerise and Related Frameworks Earlier variants of Cerise focused on showing how capabilities can be used to implement a secure, stack-based calling convention  [Georges et al. 2021; Skorstengaard et al. 2019a,b]  and nested security wrappers  [Van Strydonck et al. 2022]. Skorstengaard et al. [2019a]  were the first to show that capabilities can be used to implement a secure stack-based calling convention, i. e. , a calling convention where the security guarantees of function calls at the machine code level are faithful to the high-level notion of a function call. They employed an additional kind of "local" capabilities and stack clearing to achieve security. Their work follows a similar methodology as the one described here, that is, they define a logical relation which characterizes a notion of safety.
However, their proofs were not mechanized and the logical relation was defined using a non-trivial concrete model; in contrast we use the Cerise program logic to define and prove properties about our logical relation, which means that our development is done at a higher-level of abstraction and thus we, e. g. , do not have to solve any recursive domain equations. In follow-up non-mechanized work,  Skorstengaard et al. [2019b]  achieved similar security guarantees with a novel calling convention based on so-called "linear" capabilities; capabilities that can never be duplicated. Although this calling convention avoids the stack clearing required in the previous work, linear capabilities come with certain architectural restrictions [see, e. g. ,  Skorstengaard et al. 2019b, §6. 2 ]. An efficient implementation of linear capabilities has so far not been demonstrated.
Acknowledgements. Thanks to  Léon Gondelman  and  Cécilia Pradic  for feedback on earlier drafts of this document. This work was supported in part by a  Villum Investigator grant  (no. 25804 ),  Center for Basic Research in Program Verification (CPV) , from the  VILLUM Foundation ; by the  Research Foundation -Flanders (FWO) ; by  DFF  project  6108-00363  from The  Danish Council for Independent Research for the Natural Sciences (FNU) ; by the  Air Force Office of Scientific Research  under award number  FA9550-21-1-0054 , by the  Research Fund KU Leuven ; and by the  Flemish Research Programme Cybersecurity. Thomas Van Strydonck  held a  Research Fellowship  of the  Research Foundation -Flanders (FWO)  during the work on this project. Amin Timany  was postdoctoral fellow of the  Flemish Research Foundation (FWO)  during parts of this project.
We observe that the offset progressively decreases between the Pazarcık and Karasu segment, where the rupture direction is smoothly changing (Fig. 4d ). Considering the on-fault displacement (Fig. 4b ), three additional fault sections may be considered within the Karasu segment: the Nürdagi, Hassa and Kirikhan fault sections. A delineation of the fault in 5 segments is in agreement with the models derived from seismic and geodetic datasets  7, 11. The diffuse deformation is computed from the on-fault and total offsets (see Methods for details) and an average diffuse deformation of 58% is found for the Mw 7. 8 rupture. It shows high variability along the fault (Fig. 4c ) with fault width and diffuse deformation increase at segment limits and at the extremity of the fault. In between the structural complexities, very localized deformation on very narrow fault zones occur and are susceptible to having hosted supershear rupture  41, 42.
Conclusion The rupture traces of the 2023 Kahramanmaraş doublet occurred along the known faults of the active faults database  15  although sometimes slight offsets are observed as well as new fault splay and branches. The main observation is that the rupture does not always propagate along the most expected path, especially in the eastern extremity of theÇardak fault, where the rupture propagates along a previously unmapped strandinstead of continuing on the Sürgü fault. The currently available models report maximum slip from 8 m  7, 11, 28, 47  to 10 m 48 for the Mw 7. 8 earthquake and from 6 m 48 to 12 m 7 for the Mw 7. 6 earthquake. This value would lead to a shallow slip deficit of 7 to 25% and of 0 to 12. 5% for, respectively, the Mw 7. 8 and Mw 7. 6 rupture. These values and the geometrical properties of the fault trace tend to indicate that both faults are mature  49.
Acknowledgements Our first thoughts are for the population of Türkiye and to the victims of the earthquakes. The Sentinel-2 satellite optical imagery is freely available by Copernicus and ESA (scihub. copernicus. eu). The authors thank Data-Terra/ForM@Ter (Data and Service Hub for the Solid Earth: poleterresolide. fr), the  EOST/A2S High Performance Computing (HPC) infrastructure of University of Strasbourg  (1. 5 Tier Mesocentre) and the  Geohazards Exploitation Platform  (GEP: geohazards-tep. eu) for their contributions to the development and the exploitation of the GDM-OPT-ETQ processing chain. The processing was carried out on the GEP and supported by the  ESA   NoR  Project ID:  NoR  -project  1c15aa , and by ForM@ter. Field investigations were supported by  CNRS  and the research laboratories ITES and EOST.
Data availability The Sentinel-2 scenes are available from the Copernicus Open Access Hub at https://scihub. copernicus. eu/. The GDM-OPT-ETQ service is developed and maintained by Data-Terra/ForM@Ter (Data and Service Hub for the Solid Earth: poleterresolide. fr) and exploited on the EOST/A2S High Performance Computing (HPC) infrastructure of University of Strasbourg (1. 5 Tier Mesocentre). The service is accessible on-demand through the ForM@Ter webservice (en. poleterresolide. fr/ 260 servicesen/gdm-en//optic) and/or through the Geohazards Exploitation Platform (GEP: geohazards-tep. eu). The datasets generated during the current study are available in a Form@ter repository with an CC-BY-NC license under doi:10. 25577/EWT8-KY06.
e. 10 m x 10 m). The GDM-OPT-ETQ processing chain is deployed on the HPC calculation cluster (A2S) of the University of Strasbourg. The final products were obtained within 10 hours. The first pair of images were processed on February 9, 2023 and the dataset has been released publicly (10. 25577/EWT8-KY06  54  ). The co-seismic displacements are estimated between the Sentinel-2 acquisition of January 25, 2023 and February 9, 2023. The presence of snow in the image of February 9, 2023 creates artifacts, visible mainly in the North-South component (Fig. S1a, b ), implying much higher estimation of the co-seismic displacements. In order to remove the artifacts generated by the snow and increase the spatial density of measurements, a second pair of images is considered with the Sentinel-2 acquisition of May 25, 2022 and May 5, 2023 (i.
Modern software-based systems are highly configurable and come with a number of configuration options that impact the performance of the systems. However, selecting inappropriate values for these options can cause long response time, high CPU load, downtime, RAM exhaustion, resulting in performance degradation and poor software reliability. Consequently, considerable effort has been carried out to predict key performance metrics (execution time, program size, energy consumption, etc. ) from the user's choice of configuration options values. The selection of inputs (e. g. , JavaScript scripts embedded in a web page interpreted by Node. js or input videos encoded with x264 by a streaming platform) also impacts software performance, and there is a complex interplay between inputs and configurations.
, 2020). To address these issues, researchers typically apply machine learning (ML) techniques  (Guo et al. , 2013; Temple et al. , 2017b)  to learn DBMS  (Zhang et al. , 2019 ) such as SQLite. All these kinds of inputs might interact with the configuration space of the software  (Ding et al. , 2015; Alves Pereira et al. , 2020; Mühlbauer et al. , 2023a; Lesoil et al. , 2023). For instance, an input video with fixed and high-resolution images fed to x264 could reach high compression ratios if configuration options like mbtree are activated. The same option will not be suited for a low-resolution video depicting an action scene  (Maxiaguine et al. , 2004)  with lots of changes among the different pictures, leading to different performance distributions, as for input videos in Fig. 1. 1 The interplay between input data and configurations has not caught a great attention in the literature  (Pereira et al.
, 2021; Valov et al. , 2017). Certain transfer learning methods were originally intended to handle changes in computing environments, not actual inputs' changes, necessitating the development of new techniques that could effectively leverage specific input characteristics  (Jamshidi et al. , 2017; Valov et al. , 2017; Jamshidi et al. , 2018; Nair et al. , 2018a; Valov et al. , 2020; Larsson et al. , 2021; Iorio et al. , 2019). The principle is to adapt existing performance models (pre-trained in an offline setting over multiple inputs and configurations) thanks to additional measurements gathered over a specific input to process. The hope is to transfer the model with very few measurements at run time. In this article, we study and compare the cost-effectiveness of these three input-aware approaches over a large dataset comprising 8 software systems, hundreds of configurations and inputs, and dozens of performance properties, spanning a total of 1,941,075 configurations' measurements.
Research questions (RQs) Accounting for the variety of UPs and prediction strategies, we spell out the following three research questions (RQs): 𝐑𝐐 𝟏. How do different machine learning algorithms compare for establishing a relevant performance prediction model? The production of a relevant predictive performance model involves the selection of the most appropriate algorithm for that task. To address this question, we quantify the errors and the benefits of tuning hyperparameters of several relevant algorithms used in the literature. We also compare these results with a non-learning approach to the problem, used as a baseline for comparison. 𝐑𝐐 𝟐. How to select an appropriate set of inputs for training a performance prediction model? Prior to the prediction, we have to select a list of inputs whose measurements will form the training dataset.
Dataset We reused the measurements from 8 configurable systems and their inputs, as they are introduced in  Lesoil et al. (2023)  and referenced in the companion repository. 3 Different elements are shown in Table 2. The total number of measurements taken for a software system is equal to the number of configurations multiplied by the number of inputs and the number of performance properties. For instance, 201 configurations of x264 have been systematically measured along five performance properties and using 1397 videos coming from the YouTube User General Content (YUGC) dataset  (Wang et al. , 2019) , for a total of 1,403,985 measures for x264.
c scripts compiled 3 Our data and measurementprotocol are available and open. by gcc, the size of the file, the number of imports, methods, literals, for and if loops and the number of lines of code (LOCs); for the images fed to imagemagick, the image size, width and height, category (describing the image content, e. g. , ostrich, dragonfly, or koala), and its averaged (r, g, b) pixel value; for SAT formulae processed by lingeling, the size of the. cnf file, the number of variables, or operators, and and operators; for the test suite of nodejs, the size of the. js script, the LOCs, number of functions, variables, if conditions, and for loops; for the. pdf files processed by poppler, the page height and width, the image and pdf sizes, the number of pages and images per input pdf; for databases queried by SQLite, the number of lines for eight different tables of the database; for input videos encoded by x264, the spatial, temporal, and chunk complexity, the resolution, the encoded frames per second, the CPU usage, the width and height of videos 4  ; for the system files compressed by xz, the format and the size.
Unlike Random Forest training different trees, gradient boosting aims at improving one tree by specializing its rules of decision at each step. These are prevalent algorithms and are commonly used for tabular data. We do not include deep learning or neural networks since we do not have lots of measurements in an online setting, which is usually a requirement, and since these methods are still commonly outperformed by random forests or gradient boosting (Shwartz-Ziv and Armon, 2022;  Gorishniy et al. , 2021). We train each machine learning algorithm with its default parameters, if not stated otherwise. The optimal parameters for an algorithm are dependent on the dataset, its size, and the performance property. As a result, they are necessary to be adjusted on a per-case basis.