dataesr/scientific-paragraphs-categorization huggingface dataset:
Mitigation Mitigation schemes strive to contrast the effects of ransomware attacks. Works in this category frequently adopt some declination of the moving target technique (also part of the Data Flooding against Ransomware mitigation mechanism), e. g. , "masking" user files, so that the ransomware skips them during the attack. For example,  Lee et al. (2019)  analysed ransomware families and proposed a method that changes the extensions of files to formats normally skipped by ransomware. Another example is  Gómez-Hernández et al. (2018)  where the authors proposed a general methodology called R-Locker to thwart crypto-ransomware actions. It is based on the deployment of honeypot archives, designed for the Linux system, to expose the ransomware when it accesses these. In addition to that, this approach can automatically launch steps to solve the infection.
Mitigation The mitigation phase represents a reaction to an ongoing ransomware attack, which a DFaR-based tool counteracts by flooding target folders-such as where the ransomware is performing its attack but also, as a preventative measure, locations with files critical to the user-with decoy files. The principle is to stall the attack by confounding the authentic files of the user with a multitude of decoy ones, which the malware would waste time encrypting. Since Ranflood builds on the principles of DFaR mitigation, we use the description of this phase to introduce the general behaviour of Ranflood and dedicate Section 4. 1 and Section 4. 2 to respectively detail the three flooding strategies we implemented in Ranflood and the salient points of its software architecture. To aid our presentation, we depict in Figure  2  a scheme of the action of some representative ransomware (top) and its interaction with a DFaR-based mitigation tool (bottom)-in the picture, we represent this tool with the Ranflood logo.
Algorithm 1: Random Data Flooding The code in Algorithm 1 achieves (1), (2), and (3) to a satisfying degree. In particular, we deem (2) and (3) of good level for two reasons. One, because we use a variant of Xorshift  ( Marsaglia, 2003 )  for fast randomness (the first for loop in Algorithm 1 ) to quickly generate random content for files of random sizes-in the [ minSize , maxSize ] interval, e. g. , Ranflood uses file sizes in the range minSize = 2 8 and maxSize = 2 22 as default values, but the user can also configure these. Moreover, we make the format of the file (declared by its extension) and its header match-the first instruction that append s to the cnt array the byte sequence related to its extension ( getHeader ). The rndFilePath function generates a random file path (location, file name) under the given path and with the given extension.
The solution we develop to tackle this issue is to add a preliminary "snapshooting phase" to save a list of the valid files, later used during flooding for efficient discrimination. Saving such a list trades a small occupation footprint on the disk with an increase in the efficacy of the flooding. Specifically, the snapshooting procedure reported in Algorithm 2 saves a digest (e. g. , MD5) of the content of the user files and uses it as an integrity verification code to validate the files during the flooding phase (Algorithm 3 ). For simplicity, in Algorithm 3 , at each iteration we read ( readBytes ) the files from disk and write ( copy ) them, if valid. the possibility to lose files between iterations. 2  To avert this risk, Ranflood runs a more sophisticated version of Algorithm 3 , not shown here for the sake of clarity, that caches the content of the files read once from the disk and then iterates their replication (trading memory occupation for efficiency).
We close the description of On-The-Fly noting a subtle detail: saving snapshot lists exposes the strategy to failure due to the action of the ransomware, which could encrypt the list itself. This is a general problem of any software that uses secondary memory for its functionality (e. g. , for configuration, runtime, etc. ) and one can mitigate it a) via remote file storage, like NAS and the Cloud, and b) using locations and (random, exotic) file extensions for lists, which ransomware usually skip. Since the problem is orthogonal to the core of the flooding approach, we omit to discuss it here and plan to address the subject in future extensions.
Software Architecture The implementation of the strategies from Section 4. 1 in Ranflood are more sophisticated, technically complex, and tuned to ex- ploit the maximal degree of concurrency available on the attacked node-maximising both IO access contention and the file generation rate. Hereinafter, we report on the salient elements of the software architecture of Ranflood which support this high degree of concurrency. The Ranflood Architecture Two components determine the behaviour of Ranflood. First, the Ranflood engine implements refined versions of the algorithms shown in Section 4. 1. We call these elements operations , e. g. , one operation can be an instance of the Random flooding strategy or the snapshooting routine of the On-The-Fly strategy. While, in Section 4. 1 , we represent strategies as indivisible units, in Ranflood one operation corresponds to several executable tasks without a priori bounds, e.
The basic interface for the latter is Flooder , which the Random , On-the-Fly , and Shadow flooders implement. The On-the-Fly and Shadow strategies also have a snapshooting phase, which they realise by implementing the Snapshooter interface. The Daemon interacts with these components to obtain tasks that operate on files, ran in parallel by the Task Manager -which implements the Proactor's logic. The faded Detector interface indicates that the Ranflood Daemon is organised to support the integration of (generic, i. e. , not necessarily DFaRbased) detectors. Ranflood (both its client and daemon) (at the time of writing at version 0. 5. 9-beta) is an open-source project 3 written in Java, uses the RxJava 4 library for the basic components of its task manager and, through the GraalVM 5 compiler, it is available as native binaries for Windows, macOS, and Linux systems, besides its Java executable.
Hence, we take 4 fixed delays which represent increasing worst-case activation scenarios (we discuss the actual times in Section 5. 1 , which are inspired by studies from the literature). Future work can focus on studying the relationship 3 https://github. com/Flooding-against-Ransomware/ranflood. 4 https://github. com/ReactiveX/RxJava. 5 https://www. graalvm. org/. between different families and implementations of detection techniques and Ranflood. To this aim, one would need to systematically review the literature on ransomware detection, select a set of representative families of detectors, select implementations for each of these families, and establish and run statistically-relevant batteries of benchmarks. The combination of the ransomware samples, the activation delays, and the flooding strategies gives us 72 different run scenarios, totalling 78 considering also the 6 baseline runs where we do not let any Ranflood strategy run (called "None" configurations).
Benchmarking Method Target Operating System and Data To select the target operating system, we choose to adopt the one with the wider market share on desktop machines in the last year (at the time of writing). To find it, we used the data made available by StatCounter 6  , which reports a marked share of around 75% held by Microsoft Windows 10. Thus, we use this operating system as the target. The target data is the set of files attacked by ransomware. Since the ransomware samples we consider mainly attack the profile of the user in the machine, our target data corresponds to a representative set of files of an ordinary user  ( Akbanov et al. , 2019; Continella et al. , 2016; Kharaz et al. , 2016 ). There are mainly two ways to obtain a profile of this type. The first is organic, i. e. , drawn from a real environment used by a regular user for a certain amount of time.
Testbed To run the tests, we assembled a testbed made of a cluster of test nodes with hardware representative of today's ordinary office/desktop personal computers. The test nodes ran isolated Windows 10 virtual-machines, orchestrated by a central gateway running Ubuntu 21. 04 (to further avoid possible interactions with ransomware samples in the cluster). The gateway of the testbed was the only terminal with network access (this avoided problems like the escape of some ransomware, e. g. , due to unknown network exploits, and the execution of unexpected processes, e. g. , update routines, which might interfere with the performance). Figure  4  reports a schema of the testbed, where "PVE" prefixes the test nodes. The main point of assembling this testbed was to automatise and standardise the tests and make our data as reliable as possible.
Regarding the nodes, we used four desktop computers each equipped with an Intel i3-4170 (3. 70GHz) dual-core, four-thread CPUs, 12GB of RAM, and a Hard Disk Drive 7  (HDD) of 500GB. These machines run ProxMox version 7. 0-8 on GNU/Linux. We built the template for the virtual machines from the one provided by Microsoft of Windows version 10 (x64) Stable 1809. Each node runs one virtual machine with a dual-core, four-thread CPU, 12GB of RAM, and 40GB of disk. The test configurations using Ranflood are 72. In addition to these, we gather baseline rate-loss values for each ransomware, run without Ranflood, totalling 78 configurations. We run each configuration 4 times for a total of 312 runs and gather the results for each scenario as the average of the related runs. Each test run follows the steps: 1.
Section 3. 2. 4 ). Concretely, the Filechecker includes two phases. First, before an attack, it records all the signatures (hashes) of the files in the target directories in a reference database (this is similar to how OTF snapshooting works, cf. Algorithm 2 ). Second, after an attack, it checks the files present on the disk against the recorded signatures. The Filechecker preserves a file if its signature corresponds to a recorded one. In the case of decoy files that are copies of the original ones (which have a different path than the one corresponding to a recorded signature), if the original is missing we replace it with the copy.
Results and Analysis The complete set of data gathered from our experiments is available at https://doi. org/10. 5281/zenodo. 6587519. We report the results of our tests in Figure  5  , as percentages of lost, saved, and copied files in each attack scenario. For the sake of clarity, we included only the average result computed across the multiple runs of each test, because the standard deviation is generally low among the cases. Specifically, the highest standard deviation occurs in tests related to Phobos, whose average percentage standard deviation is ca. 8% (with average standard deviation of 13). The cells in Figure  5  are composed as follows: the central area shows the percentage of valid (non-encrypted) files. Since copybased flooding strategies allow the restoration of lost original files,  we break down the percentage of valid files into a blue one (original) and green one (restored), reporting the related percentages respectively at the bottom and at the top of the bar.
Copy-based Overhead and Restoration Aside from the performance benchmarks of the mitigation, we benchmark both the initial overhead derived from the snapshooting routines of the On-The-Fly and Shadow flooding strategies and the performance of the Filechecker (i. e. , a possible implementation of the restoration phase). In particular, the former is interesting to describe the footprint of the software during the normal operations of the user. We present the performances in Table  2  as the average over eight experiments and the standard deviation of these sampleswe report the baseline in the first row (30 sec. ) of each table for reference. We deem the overhead of both the On-The-Fly and the Shadow strategies compatible with the regular operations of users (interactive) and servers (batch), as they allow for other processes to execute concurrently and not take a lot of time to complete-this is not different from having an antivirus scan running alongside other processes.
Finally, we notice that the reported measures have a small-yetnon-negligible standard deviation. Indeed, the measures are influenced by several factors which increases the stability of the performance. In particular, regarding the performance of the Filechecker, we notice: • differences between the operating systems: the Filechecker runs on Linux, where we mount the NTFS disk of the virtual machine through the "qcow2" driver, while the signatures and archive generations run directly in the Windows virtual machine, using the virtual device; • scheduling and parallelism: the Filechecker runs in sequential mode while the signatures and archive generation run in a multithreading application. While these performance results are encouraging, we deem an important future work setting out specific tests that would allow us to profile the algorithms and runtimes of the tools, refine them, and increase their performance.
Comparison with Empirical Evaluations of Related Work To conclude our empirical assessment of Ranflood, we put our results in perspective against those from empirical evaluations of related work. In doing so, we underline that it is not possible to directly compare the results of the considered evaluations, given that they have been drawn from diverse hardware and software settings, on different sets of ransomware samples, and with disparate experimental set-ups. Moreover, the considered tools are sensibly different in terms of the phases they target to contrast ransomware (detection, mitigation, restoration), the technique they rely upon, and the usage requirement-e. g. , a solution like Ranflood is closer to installing an antivirus while e. g. , ShieldFS is a more involved one, which requires the user to recompile the operating system kernel.
Acknowledgement We thank  Stefano Cattani  for supporting and encouraging the collaboration between  ARPAE  and  UniBo ,  Claudio Dall'Osso  for creating the context that sparked this project,  Laura Pozzessere  for proofreading the first version of the manuscript, and the anonymous reviewers whose constructive feedback contributed to the improvement of the article. This work was partially supported by project  SERICS  ( PE0 0 0 0 0 014 ) under the  MUR National Recovery and Resilience Plan  funded by the  European Union -NextGenerationEU.
3D-stacked macropixel array architecture This work is built on the RETINE  [13, 14]  MPA. It is a 3D-stacked vision chip whereby an array of backside-illuminated photodetectors are bonded directly on top of an array of macropixel processors (MPX-p) (see Fig. 1 ). Specifically, an array of 16x16 photodetectors communicate vertically via sixteen analog-to-digital converters and write the sensed data directly into a local register file (RF) memory that exists within each macropixel processor (MPX-p) -each with a total capacity of 384 bytes. Each MPX-p also contains sixteen local processing elements (PEs) that execute programmed microcodes in a single-instruction multiple-data fashion. These microcodes are generated through compiling a custom assembly language. The sixteen PEs write into and read from one of sixteen corresponding columns in the RF in parallel and perform logic and arithmetic operations on this data (i.
e. , add, multiply, shift, etc. ). Furthermore, RF data can be shifted in parallel, to the left or right, between data columns within the register file and also between neighbouring in any direction. This local MPX-p memory can also be written to and read from by an on-chip 98 KB SRAM in a highly parallel and low latency fashion via a crossbar circuit. This might be done, for example, to load the weights of a convolutional kernel that will be applied to the pixel data stored in the RF. These 3D-stacked MPX-p are tiled in a 16×12 systolic array -permitting massively parallel and distributed in-sensor computation on 256×192 pixels captured by the top layer of photodetectors on the chip at a rate of up to 5500 frames per second. RETINE can also be configured to operate in a higher image resolution mode of 1080x768 pixels.
A bit-shift scaling factor N is introduced into the ReLU operation applied to the weighted sum per layer. This acts to divide the weighted sum by a factor of 2 N such that the distribution of weighted sums over the training dataset falls within the permitted range of activations between zero to fifteen  [19]. In order to respect the memory constraints of the RETINE MPA, the input image is binarized and, in a post-training quantization step, the weights and activations are quantized to 4 bits (twos-complement signed integer for weights and unsigned integers for the activations) after training. Note that our implementation supports an intermediate precision in the weighted sum of up to 17-bit signed integer precision. At this level of quantization on RETINE, the accuracy on the MNIST digit test set is 96.
End-to-end implementation on the MPA architecture The neural network is implemented on RETINE by a series of microcodes that execute the operations required to implement the four layers of our adapted LeNet-5 model in a continuous pipeline. In addition to the functional codes that implement the required core operations (convolutions and fully-connected operations), pre-processing codes are also required before each layer in order to organize and distribute the data (input features (IF) We first detail the end-to-end pipeline, as depicted in Fig. 2 , and then in the following section provide more detail relating to how the core functions (i. e. , convolution, multiply and accumulate) are realised. All of the intermediate feature maps and vectors shown in the figure correspond to those which resulted on the MPA due to the input digit eight shown in the figure.
Pre-processing CONV1 In order to apply the sixteen filters of the first convolutional layer (CONV1) in parallel, the input ROI is duplicated fifteen times on the MPA. This is done first by copying the ROI data to the four southerly MPX-p. The two central MPX-p columns containing the ROI are then duplicated over the width of the MPA. After duplication of the input, the weights for the CONV1 layer are then loaded into the MPA from the on-chip SRAM. Each square group of four MPX-p which contain the input ROI are programmed with the weights of one the sixteen different convolutional filters.
Pre-processing CONV2 The CONV1 OF maps are then duplicated over vertically such that each column of the entire MPA contains one OF. This is achieved in two steps. In the first, the two central rows of MPX-p are filled with the OF. Then, in a highly parallelised fashion, data from the first line of MPX-p are transferred to the upper part of the matrix while data from the second line are transferred to the lower part. At this point, the CONV2 layer inputs are duplicated twelve times (on the twelve MPA rows). Crucially, this permits the simultaneous execution of twelve filters. Since the second convolutional layer requires twenty-four filters, the kernels can be applied in two passes. Before each pass one set of filter weights are loaded into the MPA such that each MPX-p contains twenty-five weights -corresponding to the 5x5 kernel of a channel for a filter.
This is achieved by executing an addition tree microcode (Fig. 5 ). Simply, the addition tree sums up, along the rows of the MPA, all of the partial results stored in each MPX-p (i. e. , for each channel). It is executed in parallel for the twenty-four filters whereby the sum converges, over four addition branches, towards a central column of MPX-p. Between each addition branch, the partial sums are bit-shifted between neighbouring MPX-p where a different number of shifts are performed at each step. The final 17-bit signed weighted sum is then finally passed through a ReLU activation and quantized to 4-bits. At the end of this layer, the twenty-four 4×4 OF maps are located in the MPA central column as represented in Fig. 2. Within each MPX-p, the data is organized such as that the feature maps are contained within the memory of eight of the PEs.
Description of core functions In the pipeline described above there are two core functions that underpin the neural network model : convolution operations and vector-matrix multiplications (i. e. , fullyconnected layers). These operations are well known and widely used on CPU and GPU architectures, but their efficient implementation on a specific architecture such as a highly parallel MPA architecture is a challenging task. One of the main issues is to exploit the computing power in parallel without adding too much data movement time. The following section details, from the perspective of register file of an MPX-p, how these operations are implemented to exploit the MPA parallelism.
Addition tree Since partial products are computed in a parallelized fashion across the MPA, their elements are required to be summed together in order to calculate the final weighted sum. The addition tree moves data stored in a given RF section to neighboring MPX-p's where it is added to data stored in the same section. The register file memory of each MPX-p is simply divided into two sections. The first section, which is configured to store data up to a 17-bit signed precision, contains the input data to accumulate. The second section is used to communicate between neighbouring MPX-p. In the loop, the data in the first section is written into the communication section which is then shifted as many times as necessary to move the data into the communication section of a neighbouring MPX-p.
Results The above detailed end-to-end pipeline was implemented on the RETINE MPA chip at a clock frequency of 100 MHz. The results and intermediate states achieved on the chip implementation correspond exactly to those observed in the quantized software version of the model. The latency, for each pre-processing and functional step in the pipeline are shown in Tab. 2. The total time taken to classify an input digit was measured to be 3. 8 mscorresponding to a frame rate of 265 frames per second (FPS). Among all of the steps, the second convolutional layer incurred the largest latency, 1. 6 ms in total, while the second fully-connected layer was the fastest to execute -only 6. 1 µs. For the first three layers, the pre-processing steps, responsible for preparing the data and loading the weights into the MPX-p, correspond to between 10% and 20% of the time taken for the following functional step.
In contrast, the pre-processing latency required for the second fully-connected layer is almost two orders of magnitude greater than the execution time of the layer itself. This is due to the more complex mechanism required to regroup together the results from across the MPA and duplicate this data in ten of the MPX-p compared to the relative simplicity of the operations required to realize the second fully-connected layer. In order to better visualize how each step contributes to this total latency, we plot the percentage of the total time of each step in the outer pie chart of Fig. 6. An additional inner pie-chart shows the theoretical computational complexity of each layer -simply the total number of additions and multiplications per layer. This comparison offers an insight to the efficiency of the implementation of each layer.