dataesr/scientific-paragraphs-categorization huggingface dataset:
3. 2. 4 Exploitation. Exploitation refers to different exploit techniques applied to the vulnerabilities. RecIPE removes redundant return-to-shellcode exploits in RIPE because they can be protected by the same mechanism like DEP. We keep the well-known exploits return-to-libc and ROP used in RIPE. We add two more exploit techniques, return-to-text and SignalFrame ROP (SROP). Return-to-text are for exploits that transfer control 5  to code which should not be normally called in the. text segment, i. e. , such code is not called if there is no memory error. SROP  [1]  is a more sophisticated form of ROP attack, constructing a fake signal frame on the stack in userspace. While we have only provided some forms of exploits, RecIPE is designed to be flexible to extend and make use of more types of exploits.
Architecture and Implementation Figure  3  shows the overall architecture of RecIPE. To achieve extensibility and scalability, RecIPE is designed into two parts: (i) test case generation; and (ii) defense evaluation. The test generation component, TestGen, generates vulnerable C source code (test cases) via adjustable templates and configurations. We exploit the generated vulnerable test cases using the test evaluation component, DefEval, which applies attacks and their corresponding exploits. The runtime results are collected to distinguish the attack and exploits individually succeed/fail.
The configuration is where users specify testbed details. Figure  4  demonstrates how we generate vulnerable source code from templates and configuration files. We have designed the templates to be compatible with different attributes, e. g. , switching context for different targets, specifying expected memory layout, calculating buffer offset and input size, etc. The templates in Figure  4a  allow values to be used from the configuration in Figure  4b , allowing either replacement of values or enabling/disabling code. For ease of use, the configurations in Figure  4b  are specified in JSON format to specify parameters/details in templates. For example, the configuration file chooses the value  "/tmp/error" as the check file (used to check for exploit success). The corresponding code in the template at line 3 is combined with the JSON configuration value to obtain the source code in 4c.
The ON /OFF option either uses the string from the template or comments it out. We can see that using the templates and configurations allows for almost a "no programming" way of controlling attributes, including region, target, technique, and function. # define BUFFER_SIZE { config [ buffer_size ]}. char check_file []= "{ config [ check ]} "; { config [ exit ]} int off = { config [ rt_offset ]}; { config [ We generate a vulnerable test case by constructing each vulnerability attribute in two steps: (i) Choose a template with specified region and technique, e. g. , Stack_BoundOFlow. Templates include the overall vulnerable code framework, e. g. , definition of buffers and vulnerable read/write. (ii) Specify target, function attributes in templates. Note that exploits are not provided/controlled in TestGen but in DefEval, described next.
Exploit and Analysis. The way attacks work in RIPE is that they are "self-attacks" generated internally in the code. However, self-attacks may be too powerful as the attack code is in the same program which is being tested, hence, less realistic. We believe instead of self-attacks, to mimic an external attacker. Some examples are: (a) a browser attack from Javascript code to a vulnerability in the browser code; and (b) remote exploits where the attacker gives unexpected input triggering a vulnerability in the code. As such, our basic design considers the attack component, called DefEval, to be separate from the (victim) test code. TestGen runs as an independent process from the code being tested, which runs as the "test process". DefEval plays the attacker role, simulating interactions between attacker and victim (test process) to avoid bias from self-attacks.
DefEval will first invoke a binary created by TestGen, read the leaked information which has been output, send an exploit payload and finally analyze attack/exploit results. Support for exploitation. RecIPE has several requirements on exploitations. DefEval does not use self attacks but interacts with vulnerable programs, monitoring program status, sending payloads, and receiving responses. DefEval needs to construct specific payloads for particular exploits. In order to make it easier to apply different and possibly new exploits, DefEval has an interface for constructing payloads. To keep up to date with exploitation, we decided that payload construction, except for some basic cases, can be left to specialized tools that already do this work. As such, RecIPE can then simply use state-of-art attack tools through a suitable interface.
We selected pwntools  [8]  which is designed for rapid prototyping and development and intended to simplify the crafting of exploit creation. For example, exploiting SROP is complicated because it needs a crafted fake signal frame. Using pwntools, we only need to specify register values to create the exploit payload. Pwntools can also help extract details from address information, and we leverage it to dump the GOT addresses for the GOT hijacking attack. We believe that leveraging attack tools such as pwntools is better than writing payloads in C code directly in RecIPE. We employ an interface to be independent of underlying tools used, i. e. , in the future, multiple exploit tools could be used in addition or to replace pwntools. We give examples of the interface used with an example for generating SROP exploits in Appendix A.
4. Address Space Layout Randomization(ASLR)  [27]  is enabled by default as it has little impact on the results. Note that the vulnerable code discloses some address information which is used by attacks in DefEval to mostly get around ASLR and PIE  [28]. Baseline, Default and other combinations. We use two baselines corresponding to the code being compiled with compiler options used on the command line. The first is no compiler defenses turned on, labeled as Baseline. The second baseline called Default follows the compiler's default settings: gcc default: DEP, PIE, StackProtector, FullRELRO clang default: DEP, PartialRELRO In addition, we evaluate selected combinations of defenses indicated with Best-Flags which combines lightweight defenses in the compilers. Further, these are combined appropriately with ASAN and ESan as ASanPlus and ESanPlus as follows: 7  Best-Flags: DEP, PIE, StackPrtAll We represent the evaluation as filled circles showing the effectiveness of the attack or exploit, i.
However, it is more effective in this category than all other sanitizers, detecting all the attacks. This shows that while having limitations, dynamic binary instrumentation can protect all heap buffer overflows since all code can be instrumented. In contrast, the source-based sanitizers are limited to what has been compiled with the sanitizer. SoftBound. SoftBound is one of the first defenses to check against out-of-bounds memory errors. The bounds checking mechanism detects memory errors that escape ASan, as shown by the results, particularly in the NBoundOFlow and NBoundUFlow columns. However, BoundOFlow attacks using bcopy succeed (note the Stack BoundOFlow has a thin black line) as it bcopy is not instrumented by Softbound. Similarly, attacks with read succeed. We remark that the known compatibility issues of SoftBound mean that our evaluation is only to contrast red zone with out-of-bounds checks and is not intended to suggest SoftBound as a replacement for ASan.
As the runtime attack component in RecIPE, TestGen, applies a specific exploit against the RecIPE target under test, it turns out that it failed to generate the input to the tested code given the large offset needed, which can exceed 4GB. Another feature of LowFat/EffectiveSan is "escape checking" where pointers to function calls are checked to see if they are out-of-bounds (w. r. t. to caller context). It is configurable but is the default. Our attacks that use potentially uninstrumented (in this case, it is not instrumented) functions fail because the out-of-bounds pointers to bcopy are detected. Comparing LowFat with ASan, the results show: (i) LowFat can prevent all ATK/EXP in Stack BoundOFlow/NBoundOFlow/N-BoundUFlow because the LowFat allocator layout discussed above and BoundOFlow can still bypass ASan due to attacks from uninstrumented functions; (ii) LowFat is more effective in heap/global NBoundOFlow because out-of-bounds checking is inherently superior to redzone checks in ASan; and (iii) ASan is more effective in the heap/global BoundOFlow due to more functions being hardened, discussion on read in Section 4.
CONCLUSION The spike in zero-days in 2021  [19] , many of them are due to memory errors, shows that memory errors remain one of the main exploitation avenues for attackers and are a serious cause of concern given the range of critical software being attacked. We believe that this shows the importance of having tools that are able to evaluate the effectiveness of a large range of memory defenses. To date, RIPE remains the most widely used evaluation tool. However, we show that it is no longer suitable for modern architectures and environments, giving misleading results. This paper proposes a solution called RecIPE, an effectiveness evaluator to quantify how good memory error defenses are. RecIPE is intended both as a successor to the RIPE benchmark and also as an improved tool. In particular, it is designed to be extensible and customizable, consisting of two components, TestGen and DefEval.
Some surprising results are also shown. ASan using checked and protected versions of system calls may not be well known. We also show differences in implementations of the same defense in gcc versus clang. We also show the value of specific lightweight defenses, which can provide targeted protection missed by more general purposes defenses. Combinations of defenses are shown to be useful. Finally, we see that RecIPE can be useful to see how to improve existing defense mechanisms and give some guidance to practical avenues of preventing/mitigating attacks. Given that it is very easy to customize and extend RecIPE, we expect this to be an evolving tool. In summary, we propose RecIPE as a practical and useful tool for both software developers and researchers to understand and evaluate memory defenses given the large space of alternatives and combinations.
ACKNOWLEDGEMENTS We thank the anonymous reviewers and our shepherd  Chengyu Song  for their suggestions to improve the paper. This research was supported in part by the  Ministry of Education, Singapore  (Grant No. MOE2018-T2-1-142 ), and by  National Research Foundation, Singapore  under its  National Cybersecurity R&D Program  (Award No. NRF-NCL-P2-0001 ). Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not reflect the views of  National Research Foundation, Singapore.
Protein quantitation and identification The Thermo Scientific Proteome Discoverer software (version As a first technical validation of MS results, we compared the values of the insulin-like growth factor I (UniProtKB protein identification code IGF1, UniProtKB accession number P05019) measured using enzyme-linked immunosorbent assay (Figure  A1 ). There, we see a moderate positive correlation between the MS and immunoassay measurements (R = 0. 62, p-value = 4. 9e-07). The identified proteins were checked for confidence (i. e. , number of peptides and protein sequence coverage and if present in both LC-MS/MS replicates or not) and against a reference list of canonical human plasma proteins  [20]. From the total 999 proteins measured, a maximum of 5% of missing value per protein was accepted, giving a final data matrix with 417 proteins and with 99.
Baseline cohort characterization and quantitative proteomic measurements: Plasma proteome profiles of CT subjects Weight for individuals at the different time points is shown in Figure  A2. On average, by V9 only male controls did not lose the weight gained previously. As known, gender can show a strong effect in plasma proteins. In this dataset, gender was strongly associated to the levels of several proteins, shown in Table  A1. We consistently identified the following proteins to be differential between genders: sex hormone-binding globulin (SHBG, P04278), pregnancy zone protein (PZP, P20742), vitamin K-dependent protein S (PROS1, P07225), and neural cell adhesion molecule 1 (NCAM1, P13591). Complement factor D, also known as adipsin (CFAD, P00746), showed a strong gender difference at V6 only (Figure  A3 ).
Both peptide and protein false discovery rates were fixed at 1%, with a two unique peptide criterion to report protein identification. Relative quantitative protein values were exported from Scaffold Q+ as Log 2 of the protein ratio fold changes (FCs) with respect to their measurements in the pool samples, that is, mean Log 2 values after isotopic purity correction but without normalization applied between samples and experiments. Calculation, statistics, and creation of figures were performed using the software environment R, versions 3. 2. 4 and 4. 0. 2 (http://www. r-project. org/) [19]. 1. 4. 0288) was used as data processing interface. Identification was performed against the human UniProtKB/Swiss-Prot database (October 26, 2015 release) including the LACB sequence (20,198 sequences in total).
Study Design The study was a qualitative cross-sectional survey of primary and secondary care physicians involved in the management of post-MI patients in six countries (France, Germany, Italy, The Netherlands, Spain, the UK) carried out from December 2019 to June 2020. A stratified sample of 60 physicians was surveyed in each country. The number of primary and secondary care physicians varied across countries to reflect their role in management of post-MI patients during the first year after the event in each country (Table  1 ). A review of literature, local guidelines, and country-specific guidelines was conducted to define the survey questions. Data were then collected using a structured web-based survey developed using Streiner and Norman methods  [15]. A screener questionnaire was used to select physicians who satisfied the inclusion and exclusion criteria for the survey.
Data Collection For the pilot phase, five respondents for the UK and three in each of the other countries were recruited (20 in total), and these responses were not included in the main dataset. For the main phase, a total of 360 respondents (60 respondents in each of the scope countries) were recruited stratified by specialty. This sample size was calculated at the design stage to be sufficient to address the study objectives with acceptable precision. The questionnaire was translated into local languages with two-step verification; participants completed their responses in their native language. Responses were obtained using a structured questionnaire, administered between December 2019 and June 2020. Descriptive analyses of the main phase data were conducted overall (for the primary endpoints) and for each country individually.
Continuous variables were summarized using the mean and standard deviation as well as the median and interquartile range to understand the distribution of results. For categorical variables, the number and percentage of respondents were calculated for each category. For the primary analyses, the data were analyzed collectively across all countries. Findings for each scope country were analyzed and reported separately. Results were summarized by clinician type and were reported separately for PCPs and SCPs. Data were analyzed using SASÒ (version 9. 4, SAS Institute, Cary, NC, USA).
9%), the requirement for patients to already be on the maximally tolerated statin dose (49. 4%) or ezetimibe (38. 9%), and a requirement for the patient to be pre-authorized for the PCSK9i therapy (30. 4%) (country-specific data are provided in Table  2 ). Physicians were asked whether PCSK9is were included on their formulary. For all participating countries, 68. 6% of physicians reported that PCSK9is were included on their formulary and 31. 4% reported that they were not included. This proportion varied substantially by the physician's specialty. Among SCPs, 84. 1% reported that PCSK9i were included in their formulary, while this proportion among PCPs was only 40. 2%. The largest differences in availability between primary and secondary care were observed in Spain, The Netherlands, and the UK.
These requirements delay the recommended treatment of patients with LDL-C above the threshold recommended by the guidelines. The 2021 ESC guidelines on cardiovascular disease prevention in clinical practice focus on achieving LDL-C levels as close as possible to treatment goals, approaching treatment intensification in a stepwise manner to help physicians and patients pursue treatment goals in a way that fits patient profiles and preferences. For patients at very high risk the physician can proceed directly to treatment escalation to achieve the low LDL-C target of \ 1. 4 mmol/l (55 mg/dl)  [22]. The strengths of this study include that it evaluated treatment practices across both PCPs and SCPs in six European countries, covering a broad range of treatment decisions. The data were collected consistently across all countries, allowing comparison of the results across the countries.
All participants provided informed consent to participate in the study. Data Availability. The datasets generating during and/or analyzed during the current study are available from the corresponding author on reasonable request. Open Access. This article is licensed under a Creative Commons Attribution-NonCommercial 4. 0 International License, which permits any non-commercial use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
ACKNOWLEDGEMENTS The authors thank the study participants for their involvement in the study and  Marie Chivers ,  Adella Peyton , and  Max Thomas  of  PRMA Consulting Ltd , who provided medical writing services and editorial assistance in the preparation of this article respectively. Support for this assistance was funded by  Amgen (Europe) GmbH. Funding. Sponsorship for this study, open access and rapid service fee were funded by  Amgen (Europe) GmbH. Medical Writing and/or Editorial Assistance. Medical writing support was provided by  Marie Chivers  and editorial support was provided by  Adella Payton  and  Max Thomas , employees of PRMA Consulting. Support for this assistance was funded by  Amgen (Europe) GmbH.
Scanning Procedure The examinations were performed on a 256-slice scanner (Brilliance iCT 256; Philips Healthcare, Best, The Netherlands). Scanning protocols differed regarding body weightdependent tube voltage and tube current with collimation automatically adapted to the length of the scan area. Prospective scans A-C applied half of the full rotation angle needed for data collection and not used overlapping angle in the time of diastole of cardiac cycle. In retrospective helical protocol D, the pitch factor was automatically calculated based on the patient's heart rate. Additionally, multicycle technology was used to reach maximum temporal resolution. Specifically, all CT scanning protocols were subdivided into three sections, based on patient weight, to allow the appropriate quality of imaging.
Pre-Scanning Settings Patients were instructed to maintain a normal breathing cycle throughout the study but were asked to follow the operator's verbal commands for breath-hold during active CT scanning. All patients were imaged in a supine position with their arms raised above their heads. Isocentering of the LA was obtained from the anteroposterior and left lateral X-ray views. In all protocols, the target area of interest (LA and surroundings) was precisely located before the start of the scanning procedure by using a standard dual CT radiograph (a surview) (Figure  2a ) and ultralow-dose calcium scoring (Figure  2b ). After precise focusing on an LA, a contrast agent tracker was placed in the middle of the LA (Figure  2c ) and data acquisition was launched. The total amount of Iomeron 400 contrast (Bracco Imaging S.
Pre-Scanning Settings Patients were instructed to maintain a normal breathing cycle throughout the s but were asked to follow the operator's verbal commands for breath-hold during a CT scanning. All patients were imaged in a supine position with their arms raised a their heads. Isocentering of the LA was obtained from the anteroposterior and left la X-ray views. In all protocols, the target area of interest (LA and surroundings) was cisely located before the start of the scanning procedure by using a standard dual C diograph (a surview) (Figure  2a ) and ultralow-dose calcium scoring (Figure  2b ). A precise focusing on an LA, a contrast agent tracker was placed in the middle of th (Figure  2c ) and data acquisition was launched. The total amount of Iomeron 400 con (Bracco Imaging S. p. A.
Statistical Analysis The Shapiro-Wilk test was used to assess the normal distribution of data. For the normal distribution, data were analyzed by ANOVA, followed by the Scheffe test for comparison of samples, and are presented as mean ± standard deviations (SD). The Kruskal-Wallis test, followed by Dunn's multiple comparison test (Benjamini-Hochbergcorrected p-value < 0. 05), was applied for ordinal data, which is presented as medians (25th-75th IQR). A generalized linear model (GLM) for binomial response variable and logit link function was computed to predict software successful integration (categorical variable) in relation to different protocols tested in the present study. Statistical analysis was carried out using SAS (Copyright © 2017, SAS Institute Inc. , Cary, NC, USA).
Study design and population The cohort of patients was collected on the patients' database admitted in our center between 2013 to 2015 having routine measurements of HLA-DR, to evaluate the meaning of mHLA-DR monitoring. The only criteria used to select the cohort was to have had at least one measurement of mHLA-DR performed within the first 3 post ICU admission days. Patients hospitalized for less than 3 days, moribund, or treated with a chronic treatment by immunosuppressive drugs were excluded. Based on the motif for admission, 4 main clusters of life-threatening conditions were observed: (1) sepsis, defined by the criteria of the American College of Chest Physicians/Society of Critical Care Medicine  [14] ; (2) neurologic disorders, related to acute brain injury such as hemorrhagic or ischemic stroke; isolated severe brain trauma; post-neurosurgery; (3) major surgery (abdominal, orthopedic, ENT); (4) miscellaneous etiologies including primary respiratory failure, hemorrhagic shock from gastrointestinal bleeding or obstetric emergencies.