dataesr/scientific-paragraphs-categorization huggingface dataset:
In nearly all cases the failure handler executes in user space (the privilege level CPL is 3). The only exceptions to this rule are Windows 8 and newer, which implement the special interrupt number 0x29 ( _ KiRaiseSecurityCheckFailure) for this purpose. When this interrupt handler is called, the program is terminated without accessing any of the potentially corrupted memory in userspace. Windows can fall back to the old user-space failure routine if a call to IsProcessorFeaturePresent(PF _ FASTFAIL _ AVAILABLE) returns zero. On Windows OS versions newer than 7, the Noise level is the lowest, as they support an interrupt specifically designed for this purpose. Older versions call 8 functions in kernel32. dll and collect information about the current register state before terminating (TerminateProcess) the application with return code 0xc0000409 (Security check failure or stack buffer overrun).
OpenBSD, when detecting a corrupt stack canary, infers the program's name from a (safe) location in the global variable section of the currently loaded standard library and prints one line of information into the system log. Linux's C standard libraries implement __ stack _ chk _ fail in different ways: musl libc does not provide any output and terminates execution using a hlt instruction, accounting for a minimal Noise level. diet libc prints a static error message and terminates the program with an exit syscall. Bionic logs a static message, which required to allocate dynamic memory, and finally terminates the program via a SIGABRT. The Noise level culminates on Linux with glibc prior to version 2. 26: where we measured that the __ stack _ chk _ fail function performs as many as 69 calls to other functions, dispatching at least three calls using (PointGuard protected) writable global static function pointers to create a stack trace by unwinding the attacker controlled stack before exiting the process.
(1) If the attacker can write null bytes and the application is mapped at a static address in memory: all vulnerable implementations stack canaries can be completely bypassed by overwriting Can and Ref with the same value chosen by the attacker. As all program addresses are known, this case directly reduces to an ordinary Return Oriented Programming (ROP) attack. (2) If the attacker is not allowed to write null bytes or the application's code section is not mapped at a static address (e. g. , Position Independent Executable (PIE)): the attack can still succeed on Linux with glibc. The attacker will target the PointGuard value, which is also stored in the TCB, directly following Ref. Equations 3 and 4 show that in PointGuard any protected pointer is first rotated by a fixed number of digits and then xored with the PointGuard value (i.
e. , an attacker controlled number) in the considered setting. The function in charge of terminating the program after a failed stack cookie check in glibc eventually ends up demangling a pointer to pthread _ once. It is obvious that by the simple arithmetic used during pointer demangling, the attacker can detour the execution flow by a fixed offset to this function. From here on, no generic attack vector exists, but we want to point out that there are code paths in glibc that execute the assembly-equivalent of execve("/bin/sh")  [22] , which constitute valuable attack targets in our case. The likelihood of this attack succeeding heavily depends on the memory layout imposed by the dynamic loader on libraries. In our experiments we never observed a distance greater than 2 24 between pthread _ once and a gadget that eventually lead to remote code execution.
Impact The tested Linux-based platforms (Android, Arch Linux, Debian, and Ubuntu) can be clustered into two different categories. Architectures which have dedicated TLS access registers (x86, x86_64, s390x, and PowerPC) that store the Ref in the TCB and architectures without a direct register access to the TLS (ARM). We have also analyzed the source code of glibc and categorized further architectures as TLS-based stack canary implementations: IA64, SPARC, and TILE. While we expect that our results can be extended to those architectures we did not had access to such hardware and did not include them in Table  1. The TLS-based SSP for all the libc implementations are vulnerable to our attack in a multi-threaded environment by overwriting the Ref via a stack-based buffer overflow  6. SSP implementations where the Ref is located in the Global section are more robust as it cannot be modified by an buffers overflow on the stack.
This result can be seen in the loc column in Table  1. Our evaluation also shows that most implementations fail to separate other data regions from the location of Ref. This might be exploitable if the program uses thread-local variables. If one of the variables can be overflown, an attacker may overwrite the reference canary Ref. In this case, the attacker needs two overflows (to change both Ref and Can). This is a difficult attack which also affects single-threaded applications, and therefore less critical issue. Interestingly, diet libc defaults to storing the reference canary in the TLS, even if the application is not multi-threaded. Thus also the main thread stack is adjacent to the used TLS. Note that the main thread's stack and its TLS region are separated in the other implementations.
Attack Mitigations Re-randomizing Ref on process creation (e. g. , after forking) is a promising idea to increase canary entropy, as demonstrated by RenewSSP  [14]. This approach mitigates our attack partially, but we also propose to modify the thread library to randomize Ref for each thread. Frantzen et al. [23]  argue to relocate Ref to the PCB data structure, but unfortunately this introduced more deficiencies. We extend this idea by proposing the generation of per-function stack cookie values by xoring the static canary with the current stack pointer value to borrow randomness from mmap. Similarly, we can xor Ref with the return address of the protected function. However, this mitigation is only effective for scenarios where the code segment of the protected function is mapped at randomized addresses.
7 andlers running in a corrupted program context should strive to quit execution as fast as possible. Glibc's __ stack _ chk _ fail handler is a bad counter-example. It passes control through several layers of code which uses attacker controlled values from the stack. This opens the possibility for further exploitation. Clearly, the approaches taken by Microsoft Visual C (MSVC) and musl libc are preferablethe handler quits as fast as possible and, in case of MSVC, any reasoning about the crashed program's state (if at all) is performed using run-time data from the OS's kernel only. Finally, the TCB must not be mapped adjacently to any memory structure that contains user-controllable buffers. The most direct way to achieve this is the introduction of a mandatory guard page mapped with no access protection at the bottom of the stack.
Improving Sophisticated Protection Mechanisms To highlight how stack canaries can improve application security, we consider the C program in Figure  1. Depending on the mitigation mechanisms added when compiling this program, the authentication bypass can be trivially triggered. We consider this example in the context of two software protection mechanisms: SafeStack: SafeStack  [8]  is a State-of-the-Art CPI implementation that logically separates the architectural stack into a safe and unsafe region. The safe region contains all control-flow related data while the unsafe stack contains user-controlled data (e. g. , arrays). Stack Canaries: We use the standard implementation employed by LLVM. When compiling with SafeStack enabled, the variables password and admin _ hash are allocated in the unsafe stack, whereas the return addresses are in the safe stack.
The stack-based buffer overflow in the auth function make bypassing the security check trivial: an attacker first overflows the password buffer and then overwrites the admin _ hash with the hash matching the provided password. When stack canaries are enabled the attack is no longer trivial. After filling the password buffer, an attacker has to overwrite Can to reach the admin _ hash. Once the auth function returns, the canary corruption will be detected and the program will terminate. The same security properties (protecting buffers of adjacent stack frames) are achieved regardless of the usage of SafeStack. To reach the admin _ hash buffer, an attacker has to overwrite the Can value. As corrupting Can should result in program termination-the fact that the return address ret is also reachable by the overflow becomes irrelevant.
Iron ore direct reduction is an attractive alternative steelmaking process in the context of greenhouse gas mitigation. To simulate the process and explore possible optimization, we developed a systemic, multiscale process model. The reduction of the iron ore pellets is described using a specific grain model, reflecting the transformations from hematite to iron. The shaft furnace is modeled as a set of interconnected one-dimensional zones into which the principal chemical reactions (3-step reduction, methane reforming, Boudouard and water gas shift) are accounted for with their kinetics. The previous models are finally integrated in a global, plant-scale, model using the Aspen Plus software. The reformer, scrubber, and heat exchanger are included. Results at the shaft furnace scale enlighten the role of the different zones according to the physico-chemical phenomena occurring.
The present shaft model has been built considering these results and on the basis of the most detailed (2D, 3 zones, 10 reactions-named REDUCTOR) shaft model  [6, 14]. However, the goal here is to simulate the whole DR plant, thus it was not practicable to incorporate such a comprehensive, 2D, CFD-type model in the plant simulation software. We selected Aspen Plus, a commercial simulation tool widely used in the chemical industry, as the software. Processes like the steelmaking blast furnace and the reverse chemical looping process are examples of processes somewhat close to the DR process that have been modeled with Aspen Plus. Thus, we had to build an Aspen Plus model of the DR shaft derived from REDUCTOR.
The ones in the reduction and intermediate sections were discretized in horizontal slices. This description, intermediate between 1D and 2D, enables us to retain the advantages of describing the axial variations of the calculated variables and of a short computation time (typically 3 h on a standard PC). The results from this model agree well with both available industrial data and results from previous models. Moreover, the two cases simulated corresponding to plants of different operating conditions and of quite different throughput, this demonstrates the adaptability and the robustness of the model. The overall Aspen Plus model of a DR plant includes models for the principal units: the shaft furnace, the natural gas reformer, the scrubber, and the main heat exchanger. To the best of our knowledge, this is the first published work on a systems model of the whole DR plant using process simulation software.
Funding: This research was supported by the  French State  through two programs 'Investment in the future': (i) one operated by  French Environment and Energy Management Agency (ADEME) , 'Valorization of  CO2  in industry', 2014-18, VALORCO, No. 1382C0245 ; the authors thank  Nathalie Thybaud  and  Aïcha El Khamlichi , and the coordinator, Eric de Coninck; and (ii) one operated by the  National Research Agency (ANR)  and referenced by  ANR-11-LABX-0008-01  ( LabEx DAMAS ).
Background: Traditional surveillance systems produce estimates of influenza-like illness (ILI) incidence rates, but with 1-to 3-week delay. Accurate real-time monitoring systems for influenza outbreaks could be useful for making public health decisions. Several studies have investigated the possibility of using internet users' activity data and different statistical models to predict influenza epidemics in near real time. However, very few studies have investigated hospital big data. Objective: Here, we compared internet and electronic health records (EHRs) data and different statistical models to identify the best approach (data type and statistical model) for ILI estimates in real time.
Google Data For comparison with internet data, we obtained the frequency per week of the 100 most correlated internet queries (Multimedia Appendices 2 and 3) by French users from Google Correlate  [34] , and we used this information to retrieve Google Trends data. Unlike Google Correlate, Google Trends data  [35]  are available in real time, but we had to use Google Correlate to identify the most correlated queries to a signal. The times series passed into Google Correlate are the national flu time series and the regional flu time series (Brittany region) obtained from the French Sentinelles network (see below). The time period used to calculate the correlation is from January 2004 to October 2016. We used the R package gtrendsR to obtain automatically Google Trends data from January 4, 2004 to October 24, 2016  [36, 37].
Data Preparation Based on previous studies that included datasets with very different numbers of explanatory variables according to the used statistical model  [2, 7] , we built two datasets (one with a large number of variables and another with a reduced number of selected variables) from eHOP and Google data, for both the national and regional analyses (Figure  1 ). Each one of these four datasets was completed with historical Sentinelles data. Therefore, for this study, we used the following: 1. eHOP Complete: this eHOP dataset included all variables from eHOP and the historical data from the Sentinelles network with the ILI estimates for the 52 weeks that preceded the week under study (thus, from t-1 to t-52).
Elastic Net Elastic net is a regularized regression method that takes into account the correlation between explanatory variables and also a large number of predictors  [41]. It combines the penalties of the LASSO and Ridge methods, thus allowing keeping the advantages of both methods and overcoming their limitations  [42, 43]. With datasets that may have up to 152 potentially correlated variables, we performed the elastic net regression analysis using the R package glmnet and the associated functions  [36, 44]. We fixed a coefficient alpha equal to. 5 to give the same importance to the LASSO and Ridge constraints. We optimized the shrinkage parameter lambda via a 10-fold cross validation.
Principal Results Here, we show the results we obtained with the four datasets and three models-RF, SVM, and elastic net+residuals fitted by ARIMA (ElasticNet+ARIMA). The model on residuals was required to fulfill the assumptions for elastic net but not for the RF and SVM models. All results are presented in Multimedia Appendices 4 and 5. Moreover, we present two influenza outbreaks, including the 2010-2011 season (flu outbreak period for which the best estimates were obtained with all models) and the 2013-2014 season (flu outbreak period for which the worst estimates were obtained with all models; Multimedia Appendix 8). The calibration plots are in presented in Multimedia Appendices 7 and 9.
Dataset Comparison PCC ranged from 0. 947 to 0. 980 when using the eHOP datasets (Multimedia Appendix 8) and from 0. 937 to 0. 978 with the Google datasets. MSE ranged from 2292 to 866 for the eHOP and from 2607 to 968 for the Google datasets. The mean PCC values during epidemic periods varied from 0. 90 to 0. 96 for the eHOP and from 0. 87 to 0. 96 for the Google datasets. The mean MSE values ranged from 7597 to 2664 for the eHOP and from 9139 to 2805 for the Google datasets.
Dataset Comparison PCC ranged from 0. 911 to 0. 923 (Multimedia Appendix 8) with the eHOP and from 0. 890 to 0. 912 with the Google datasets. MSE varied from 2906 to 2364 and from 3348 to 2736 for the eHOP and Google datasets, respectively. During epidemic periods, the mean PCC value ranged from 0. 83 to 0. 86 and from 0. 70 to 0. 83 for the eHOP and Google datasets, respectively. The mean MSE values ranged from 7423 to 5893 for the eHOP and from 9598 to 7122 for the Google datasets.
Data Here, we show that HBD in combination with flu activity-level data from a national surveillance network allows accurately predicting ILI incidence rate at the national and regional scale and outperform Google data in most cases. The correlation coefficients obtained for the French data are comparable to those reported by studies on US data  [2, 7]. At the national and regional level, the best PCC and the best MSE during the entire study period or during epidemics were obtained using the eHOP Custom dataset. Moreover, the PCC and MSE values obtained with the eHOP datasets were better than those obtained with the Google datasets, particularly at the regional level (PCC 0. 911-0. 923 vs 0. 890-0. 912; MSE 2906-2364 vs 3348-2736, respectively; Multimedia Appendix 8). However, the national signal is smoother and less noisy than the regional signal; the contribution of other data sources, such as hospital data or Web data, in addition to historical influenza data is more important at the regional level (Multimedia Appendices 4 and 5).
The contribution of these external sources being less important at the national level, the differences observed between hospital data and Web data at this scale could be more significant. Like internet data, some HBD can be obtained in near real time, especially records from emergency departments that are available on the same day or the day after. This is the most important data source for our models using eHOP datasets. Some other data, such as laboratory results, are available only on a weekly basis; however, they are not the most important data source for our models. Moreover, in comparison to internet data, HBD have some additional advantages. First, data extracted from CDWs are real health data can give information that cannot be extracted from internet data, particularly information about patients (sex, age, and comorbidities)  [51].
In addition, an important clinical aspect is to determine the epidemic severity. With HBD, it is possible to gauge this parameter by taking into account the number of patients who were admitted in intensive care or died as the result of flu. Second, some CDW data (particularly emergency department discharge summaries and laboratory test results) can confirm that people were really affected by influenza or ILI symptoms. On the other hand, people can make internet queries not because they are ill, but for other people, for prevention purposes or just because it is a topical subject. Third, HBD could also be used to estimate the incidence rates of diseases that do not generate internet activity (eg, diseases without or with little media coverage or that are not considered interesting by the general population).
Fourth, there is a spatial decorrelation between internet data and the regional estimates that were not observed with the eHOP data. It is quite reasonable that hospital-based data give a better estimate of regional epidemics, although currently, we have only data from Rennes University Hospital that might not be representative of the entire Brittany region. A major HBD limitation is that, generally, clinical data are not publicly available. In our case, we could only access the Rennes University Hospital HBD. However, the epidemic peak in Brittany could have occurred earlier or later relative to the national peak, and this could have introduced a bias in our estimation. We can hypothesize that ILI estimates, particularly nationwide, might be improved if we could extract information from HBD in other regions.
Statistical Models Regarding the statistical models, we show that SVM and elastic net with ARIMA model are fairly comparable with PCC ranging from 0. 970 to 0. 980 at the national scale and from 0. 890 to 0. 923 at the regional scale. The SVM and elastic net models in combination with the eHOP custom dataset were the most robust models, although they did not always give the best results. Indeed, they showed the best performance in term of PCC and MSE for the global signal and also for the mean values. Nevertheless, these models have some limits. The main limitation of the SVM model is the very slow parameter optimization when there are many variables. With the SVM model, it can be important to preselect the important variables to reduce the dataset size to improve the optimization speed. For this, one needs a good knowledge of the available data, which may be difficult when using big data.
On the other hand, elastic net shows good performance with many variables, which is an advantage when the most relevant variables to estimate ILI incidence rates are not known in advance. The elastic net model is a parametric model that fulfills certain assumptions on residuals, differently from the SVM model. With elastic net, residuals must be fitted to have a statistically valid model. Nevertheless, if we had to choose a model, we would prefer SVM with the eHOP Custom dataset because it has a better PCC than elastic net at the regional scale. Another limitation is that indicators are better for the global period than for epidemic periods. This implies that models are less efficient during flu outbreaks, while clinical concerns are higher during epidemics when good estimates of the outbreak starting date, amplitude, and end are needed.
Finally, the results of our models with Web data may have been overestimated due to the way we obtained data from Google Correlate. Indeed, Google Correlate used information that we did not have at the beginning of our test period. The time period for our time series passed into Google Correlate is from January 2004 to October 2016. But, the beginning of our test period for our models is January 2010. To be more precise, we should recalculate the correlation coefficients for each week to predict with the data available at that time. In the same way, to custom datasets, we calculated the 3 most correlated variables on a time period including our test period. To compare the results, we built another dataset from eHOP, including the 3 most correlated variables to ILI regional signal between December 2003 and December 2009 (before our test period), and we applied an ElasticNet+ARIMA model.
Perspectives Future research could address clinical issues not only nationally or regionally but also at finer spatial resolutions such as a city like Lu et al did  [54] , a health care institution or in subpopulations. Indeed, by predicting epidemics, it will be possible to organize hospitals during epidemics (eg, bed planning and anticipating overcrowding). Moreover, in this study, we compared internet and HBD data; however, hybrid systems could be developed to take advantage of multiple sources  [55, 56]. For instance, internet data might avoid the limit of the local source linked to the choice or availability of HBD. Data collected by volunteers who self-report symptoms in near real time could be exploited  [57]. Similarly, by combining models, we could retain the benefits of each of them and improve the estimates of ILI incidence rates.
For example, we could use another algorithm, such as stacking  [58] , to concomitantly use the SVM and elastic net models. We could also test other kernels than the linear kernel for SVM models. Finally, we carried out a retrospective study using various models with clinical data in combination with the flu activity from the Sentinelles network to estimate ILI incidence rates in real time. Our models need now to be tested to determine whether they can anticipate and predict ILI incidence rates.