ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

The present document is the property of COMEX SAS. It has been entrusted to the ORPHY laboratory, which scanned and uploaded it. The ORPHY laboratory focuses on major physiological functions, their regulation, interactions, and their contribution to the development and prevention of certain pathologies. The primary mechanisms studied involve metabolic aspects (oxygen transport and utilization, energetics, etc.) and electrophysiological aspects (contractility and excitability), mainly related to respiratory, vascular, and/or muscular functions. These mechanisms are studied under various physiological and physiopathological conditions, ranging from the cellular and subcellular levels to the entire organism. In Europe, the ORPHY laboratory is one of the leaders in hyperbaric physiology and diving research.

Being a major player in innovation and expertise in the field of pressure, COMEX maintains a scientific archive from its experimental diving campaigns. The value of this archive is both scientific and historical, as it documents a remarkable chapter in the history of marine exploration and contains results obtained during dives that are very unlikely to be replicated in the future.

  COMEX (Compagnie Maritime d'Expertises), established in 1962, has positioned itself in the offshore activities sector, where it held a leading international position, becoming the world's foremost company in engineering, technology, and human or robotic underwater interventions. Comex designed a Hyperbaric Testing Center in 1969 and developed its own research programs on various breathing mixtures used in deep-sea diving (helium and later hydrogen). These research efforts led to spectacular advancements in this field, including several world records, both in real conditions and simulations. Comex still holds the world record at -701 meters, achieved in its chambers during Operation HYDRA 10.


Théophile Gousselot
email: theophile.gousselot@emse.frdutertre@emse.fr

Olivier Thomas

Jean-Max Dutertre

Olivier Potin
email: olivier.potin@emse.frrigaud@emse.fr

Jean-Baptiste Rigaud

Lightweight Countermeasures Against Original Linear Code Extraction Attacks on a RISC-V Core

Keywords: linear code extraction, reverse engineering, hardware security, countermeasure, RISC-V

Linear Code Extraction (LCE) is an invasive attack aiming at fully extracting a code from a device's memory for reverse engineering purposes. The core instruction bus is identified and microprobed using Failure Analysis tools. Meanwhile, other microprobes force internal nodes of the core to logic states which allow a full memory linear extraction.

This paper demonstrates the first assessment of a RISC-V core vulnerability to LCE. It evaluates the complexity to extract the code in the right order by freezing the instruction register or by editing the incoming instructions. This paper introduces three original countermeasures to detect an ongoing LCE by monitoring symptoms such as the lack of branch instruction execution. These hardware countermeasures are lightweight and adaptable to other core architectures. We develop an experimental setup based on a functional simulation framework and an FPGA-based demonstration. This setup made it possible to study and assess the LCE vulnerabilities of our RISC-V target and to validate the effectiveness of our proposed countermeasures. The area overhead was measured between 0.52% and 1.47% of the cv32e40p RISC-V core. Depending on the detection latency target, the clock cycle overhead using the Embench™ benchmarks can be null or kept below 1%.

I. INTRODUCTION

Embedded systems execute applications stored in their memories. They may be the target of hardware or software attacks which aim to extract the application code. As introduced in [1, §7.1], reverse engineering the code running on an Integrated Circuit (IC) is popular as it can lead to a profitable business. Manufacturers designing an IC based on a competitor's design reduce their development costs. Manufacturers may also sell low-cost devices which are compatible with a competitor's product. [START_REF] Loebbecke | Pay TV piracy and its effects on Pay TV provision[END_REF] discusses the fact that in the 90s, compatible pirate smart cards to access paid TV services were selling well. Now, peripheral devices as gamepad controllers or ink cartridges are the main targets such as they are increasingly widespread. Some well-funded and organized manufacturers such as Apex Microelectronics sell compatible ink cartridges [START_REF]Compatible ink cartridges selling by Apex Microelectronics[END_REF].

Despite elementary countermeasures against code extraction, such as destroying the embedded memory readback logic after programming suggested in [4, 8.3], the attackers may employ Failure Analysis (FA) tools to extract a code anyway. The instruction bus between the core and the memory may be microprobed as introduced in [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF]. The first step is to locate the bus, for example by imaging the IC layers with a Scanning Electron Microscope (SEM). Then, signals from the instruction bus are routed to the top layer with Focus Ion Beam (FIB) edits, in order to be put in contact with microprobes as carried out in [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF]. All the executed instructions are eavesdropped. To extract all application functionalities, the code must be extracted entirely as discussed in [7, §16.6]. Other microprobes must be set up to force specific internal nodes of the core (e.g., the reset of the instruction register) to logic states which induce an execution of the instructions one after the other, as ordered in memory (i.e., a linear execution). This type of attack is called a Linear Code Extraction (LCE). The targeted internal nodes constitute the attack path of the LCE. The attack paths involve different numbers of microprobes, depending on the targeted core and its Instruction Set Architecture (ISA). To date, there have been no studies on the RISC-V vulnerabilities to LCE, despite its growing use in Embedded Systems. There is no existing infallible countermeasure against LCE. Most efficient ones such as the Probe Attempt Detector [START_REF] Weiner | The low area probing detector as a countermeasure against invasive attacks[END_REF] created a significant area overhead to protect all the core nodes and instruction bus sections. Memory encryption [6, §5] may be circumvented by microprobing the instruction bus after it is deciphered. Using design obfuscation [START_REF] Vijayakumar | Physical design obfuscation of hardware: A comprehensive investigation of device and logic-level techniques[END_REF] does not prevent the instruction bus from being identified.

The main contributions of our research are threefold:

• To assess the vulnerabilities of a RISC-V core to LCE. Theoretical analysis and practical experiments determine three types of attack paths to induce a linear execution: by tampering with the incoming instructions, the instruction register, or the Program Counter (PC) circuitry. Some of them are briefly mentioned in the state-of-the-art in [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF], [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF], [START_REF] Anderson | Cryptographic processors-a survey[END_REF]. Our contribution is to specially study how to take advantage of the RISC-V core considered: the cv32e40p. In particular, we evaluated the complexity in terms of microprobe's number and their locations.

• To introduce three original countermeasures as a way to protect against LCE. Focused on detecting LCE, they are lightweight enough to be integrated into small embedded devices without significant performance degradation. They monitor symptoms of LCE, such as the lack of branch or custom security instruction execution. They are implemented and integrated into the cv32e40p core. Simulations and FPGAbased demonstration allow us to assess and characterize the countermeasures in practice (effectiveness, detection latency, clock cycle overhead, maximum frequency, area overhead).

• To develop and publish an Experimental Setup including one functional simulation framework and one FPGA-based demonstration. It ascertains the complexity of custom LCE attack paths when taking advantage of the vulnerabilities of a RISC-V core. It demonstrates and characterizes the introduced countermeasures.

This paper is structured as follows: Section II introduces additional background on code extraction threats and motivations, the LCE methodology, and the existing countermeasures. Section III describes the Experimental Setup. Section IV reports on the vulnerabilities of a RISC-V core and the experimented LCE attack paths. Section V presents the three conceived countermeasures and their practical implementation. Section VII provides access links to the countermeasure descriptions and the Experimental Setup in order to replicate the paper results.

II. BACKGROUND

This background section reviews the motivations and methods of LCE attacks, as well as the existing countermeasures.

A. Code extraction: threat analysis

Embedded systems are built around a core which executes a program stored in a memory. This program, also called firmware or code, contains instructions and data. The instructions are executed by the core to carry out an application. The code in memory could be targeted by software or hardware attacks. Skorobogatov introduced five reasons to attack a device [1, §7.1]: theft of service, cloning, overbuilding, IP piracy, and denial of service. Extracting a code stored in a memory may lead to achieving these goals. For example, to design a gamepad controller compatible with a video game console, the communication and authentication protocols must be reproduced. For that purpose, code from an original gamepad controller memory has to be reverse-engineered. Therefore, it has to be extracted beforehand.

1) Extraction from external memory interfaces: The extraction can take place on external memory interfaces as described in [START_REF] Vasile | Breaking all the things -A systematic survey of firmware extraction techniques for IoT devices[END_REF]. In order to extract code from memory, some debug interface abuses, JTAG and UART exploits, and raw flash dump can be carried out. Specific voltage glitches may also help to get memory read access, as presented in [START_REF] Bozzato | Shaping the Glitch: Optimizing Voltage Fault Injection Attacks[END_REF]. Countermeasures against these types of attacks exist, such as memory encryption to prevent any use of the extracted code. Removing the external memory interfaces as suggested in [4, §8.3] addresses these extraction approaches.

2) Extraction from the instruction bus: Another way to extract code is to eavesdrop the instruction bus between the memory and the core. Such an invasive attack is carried out using FA tools as illustrated in [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF]. The eavesdropping is accomplished by getting access to the instruction bus in order to probe it electrically with microprobes. Finding the bus and identifying the right probing location is possible by using a SEM and delayering tools as explained in [START_REF] Yap | Delayering techniques: dry/wet etch deprocessing and mechanical top-down polishing[END_REF]. Once the probing locations are known, a FIB etches and deposes silicon oxide and metal to route the instruction bus bits to microprobes. At the time instructions are executed, they are extracted. The extracted instructions may be reordered to rebuild the code. Unfortunately, only the executed instructions are extracted, which also means that application functionalities may be missing. For example, some authentication features may be enabled by the video game console later after commercialization, when the first compatible gamepad controllers appear as noticed in [7, §16.6].

3) Linear Code Extraction: LCE is still about eavesdropping the instruction bus, but in addition, some core nodes are forced into logical states that allow a linear execution. All the memory's instructions pass through the instruction bus and are extracted, including all application functionalities. The reverse engineering of the code is also straightforward, as there is no need to put the instructions back in order.

4) LCE funding: As an invasive attack, performing an LCE is reserved for well-equipped laboratories. Some manufacturers are so profitable by selling compatible products that they finance LCE attacks on targeted devices like Datel, a compatible game console peripheral maker. The market for compatible products is driven by ink cartridges through companies like Static Control Components or Apex Microelectronics. Despite the lack of market data, a trend is apparent. A Market Research Report [START_REF]Ink-cartridge Market Research Report by Type, Application, Region -Global Forecast to 2027[END_REF] indicates that the global revenue for ink cartridges and toners for 2021 was USD 16.96B and is forecasted to reach USD 24.60B by 2027. Furthermore, Hamm revealed in [START_REF] Hamm | Rivals say HP is using hardball tactics[END_REF] that compatible product manufacturers sell 25% of compatible cartridges. According to its growth, it can be concluded that the cartridge market is attractive and profitable (e.g., Ninestar Corp, a major actor in the design of compatible devices and ICs, declared revenue of USD 4.3B in 2019 [16]). Selling compatible products is legal in most countries, as highlighted in [START_REF] Mank | Prudential Standing Doctrine Abolished or Waiting for a Comeback: Lexmark International[END_REF] by the American legal case concerning ink cartridges developed by Static Control Components compatible with the Lexmark printer authentication system. Even though compatible device manufacturers are not authorized to copy IPs that belong to the genuine source, proving these infringements is a difficult task that also requires the reverse engineering of compatible products.

Given the potential profitability, compatible product manufacturers can allocate funding for significant resourcesequipment and knowledge -to carry out LCE attacks on targeted devices on an industrial scale. According to the IBM attacker classification [START_REF] Abraham | Transaction security system[END_REF], these manufacturers should be labeled as attackers of class III: Funded organizations like governments.

B. LCE: principles and methodology

An LCE aims at extracting code in a linear fashion from a memory. Two sets of microprobes are used. One set to eavesdrop the instruction bus and the other set is used to induce a linear execution. This attack principle was introduced by Anderson in [START_REF] Anderson | Security engineering: a guide to building dependable distributed systems[END_REF], [START_REF] Anderson | Tamper resistance-a cautionary note[END_REF] and Kommerling in [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF]. The principle is illustrated in Fig. 1, there are four steps needed when carrying out an LCE on an IC.

1) Attack path definition: Analyzing the targeted core and its ISA highlights potential vulnerabilities. A classical attack path involves forcing the instruction register to reset. Hence, every instruction is turned into a No Operation (NOP) instruction before reaching the decode stage of the core. A linear read of the memory is thus obtained (see below).

2) Hardware identification: Locations for the microprobes according to the attack path must be found. Depackaging, then delayering the IC with chemicals, allows the layers of interest to be imaged with a SEM. Once a picture (as in Fig. 1) is obtained, the memory and the core can be identified. In order to eavesdrop, microprobes should be located on the instruction bus leaving the memory. Following the instruction, bus leads to the identification of the instruction register and its reset input. The reset signal is the target of the microprobe which induces a linear execution.

3) FIB edits to put microprobes in place: Pads like the cross shape in Fig. 2 must be electrically connected to signals of interest. For that purpose, a FIB must etch and depose silicon oxide and metal. Once cross pads are added to the bits of the instruction bus and the reset signal, microprobes can be put in direct contact with pads.

4) Linear code extraction: During execution, incoming instructions are extracted from the bus. When the reset signal of the instruction register is enabled, only NOPs are decoded and executed by the core. The execution of NOPs linearly increments the PC which will successively point to every memory address. The code from memory is extracted in a linear fashion.

LCE is an invasive attack involving FA Tools like SEM and FIB. Note that, only a limited number of microprobes can be put in place simultaneously (for a lack of access space) while minimizing any possible damage to the IC target. This limits the number of instruction bus bits eavesdropped. During one LCE, several extractions have to be performed in a row (generally on different chips).

C. Existing countermeasures against LCE

Some countermeasures against LCE have already been developed. None of them, though are infallible, and the most efficient ones often cause significant overhead in terms of either area or timing.

1) Clock signal randomization: Randomizing the IC clock as introduced in [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF] may avoid the rebuilding of the code from bits extracted at different times. However, microprobing the clock signal is enough to synchronize them.

2) Memory encryption: Encrypting the memory makes the extracted code useless. Nevertheless, as noticed in [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF] the core executes only decrypted instructions, thus, there is a deciphering component. Microprobing the instruction bus after deciphering leads to the extraction of the deciphered code. Recently, Skorobogatov challenged an encrypted ROM of a core to highlight its vulnerabilities against microprobing in [START_REF] Skorobogatov | How microprobing can attack encrypted memory[END_REF].

3) Design obfuscation: Obfuscating the design alters the efficacy of hardware reverse engineering, as shown in [START_REF] Vijayakumar | Physical design obfuscation of hardware: A comprehensive investigation of device and logic-level techniques[END_REF]. Nonetheless, the program memory stays identifiable, and following its instruction bus is feasible.

4) Active shield or mesh: Top metal layers may be converted into an active shield (or mesh) as displayed in Fig. 2. An alarm is triggered when opened or shorted with its neighboring lines. However, a line may be cut and rerouted using a FIB, as the U-shape line in Fig. 2 shows, to open a space in the shield in order to access the inner routing. Otherwise, signals may be microprobed from the backside of the IC as clearly illustrated in [6, Fig. 1].

5) Probing Attempt Detector: As microprobes introduce an additional capacity load on the target lines, a delay between symmetric lines may reveal the microprobe. The detector area is gradually decreasing, as proposed in [START_REF] Weiner | The low area probing detector as a countermeasure against invasive attacks[END_REF], however, in order to protect the line, one detector per signal is still required. Costs may significantly increase to cover every line where instructions are extractable.

6) Restricted PC: The PC may be split in two counters the sum of which is the PC value, as suggested by Kommerling in [5, §3.5]. The smaller one increments linearly. At every jump, the other one is updated with the destination while the smaller one is reset. This limits the size of a one-shot linear extraction. Nonetheless, block-per-block extraction of the entire code remains feasible. Indeed, there is always a jump to execute before being able to extract in a linear fashion a block of code since the smallest counter must not overflow into a nominal mode.

III. EXPERIMENTAL SETUP

We develop an Experimental Setup in order to ascertain the complexity of LCE attacks when taking advantage of specific vulnerabilities of a RISC-V core detailed in Section IV. This Experimental Setup also demonstrates and characterizes the countermeasures presented in Section V. There is one functional simulation framework and one FPGA-based demonstration.

The goal is not to reproduce every step of an LCE: hardware identification, FIB edits, and signal microprobing as [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF] and [START_REF] Skorobogatov | How microprobing can attack encrypted memory[END_REF] did in practice, but rather to quickly assess an attack path and to validate the countermeasures that we have developed in our study.

A. RISC-V and cv32e40p target

As RISC-V cores are increasingly used in embedded systems, we chose to analyze the potential vulnerabilities to LCE on a RISC-V core, since there are no existing studies on the topic. The authors studied the cv32e40p [START_REF]CV32E40P RISC-V IP[END_REF], a 32bit, 4-stage, in-order, core provided by the OpenHW Group as it is representative of small ISA RISC-V cores. It was targeted for experiments, as it is also open-source (i.e., intrinsic countermeasures can be added to its Register Transfer Level (RTL) description).

B. Simulation framework

The functional simulation framework was developed for simulation-based validation of either LCE attack paths or countermeasures effectiveness. It runs fast campaigns of code executions to perform LCE by focusing on various vulnerabilities.

The proposed framework is depicted in Fig. 3. It is based on the core-v-verif framework [START_REF] Group | CORE-V-VERIF: Functional verification project[END_REF] provided by OpenHW group. Simulations are sped up by using the Verilator [START_REF] Veripool | Fast and open-source Verilog/SystemVerilog simulator[END_REF] simulator. They are performed at the RTL level to ensure the accuracy of the observed behavior. From the cv32e40p RTL description and an LCE attack path described in a test bench, an executable Verilator model is built. The cv32e40p core can include a countermeasure. The LCE is simulated by using the fdisplay task and the force statement defined in the IEEE Standard for SystemVerilog [START_REF]IEEE Standard for SystemVerilog-Unified Hardware Design, Specification, and Verification Language[END_REF] instead of microprobes. The fdisplay tasks eavesdrop the instruction bus and save the extracted instructions in a separate file. The force statement induces stuck-at faults to signals targeted by the defined attack path to ensure a linear execution. A code compiled by a gcc toolchain is given to the Verilator model to simulate its execution on the cv32e40p. The executed codes were taken from the benchmark suite Embench [START_REF] Embench | Embench: Open Benchmarks for Embedded Platforms[END_REF] as they are representative of embedded system applications. Simulation outputs like the percentage of correct extracted code, clock cycle overhead, or latency detection are generated by the framework and are compared to theoretical estimations in Section V.

C. FPGA-based demonstration

The FPGA-based demonstration target to quickly assess and observe core behaviors for many LCE attack paths on protected or not core. For that purpose, the Hardware identification and the FIB edits steps are emulated on FPGA. In particular, the software processing to automate the digitalization of extracted bits to rebuild the code is reproduced. The FPGA-based demonstration leads to the same conclusion as the simulator framework to validate the countermeasures and reports the utilization overhead. It is depicted in Fig. 4.

A bitstream of a microcontroller core-v-mcu [START_REF]CORE-V-MCU: microcontroller[END_REF] containing a cv32e40p core and a code in memory is downloaded to an Artix 7 FPGA (xc7a200tsbg484-1) on a Nexys Video board. The LCE is emulated by replacing the microprobes inducing a linear execution by inserting multiplexers on targeted signals (e.g., the instruction register reset in Fig. 1). These multiplexers are driven by switches which select the original input or the forced one. The microprobes eavesdropping the instruction bus are emulated by oscilloscope probes connected to FPGA board outputs. To imitate an attacker who has few microprobes, only four oscilloscope probes are connected to the FPGA board outputs. Bits of the instruction bus are routed to these outputs. Clock and reset signals are also routed for synchronization purposes. Thus, sixteen LCEs are run to extract all the 32 bits of instruction bus. An Integrated Logic Analyzer component allows emulating these sixteen executions. The extracted waveforms are then digitalized and blended by software processing to rebuild the code. This extracted code can be disassembled to be analyzed or compared to the one in Concurrently, other switches enable and select one of the countermeasures integrated into the cv32e40p core. These switches and the probes connected to the oscilloscope are highlighted in the picture of the FPGA board setup in Fig. 5.

IV. EXPLOITING RISC-V LCE VULNERABILITIES

In order to completely extract a code from a core's memory, an LCE entails eavesdropping the instruction bus, while forcing nodes of the core into logic states which allow a linear execution. The microprobing to eavesdrop the instruction bus is quite common to every ISA and core architecture:

Select CM

Select LCE attacks

Eavesdropping emulation microprobes have to be set on the instruction bus between the core and its memory. Yet, the microprobing to force the linear execution and its complexity are highly dependent on the ISA and the core architecture vulnerabilities. For example, resetting the instruction register of a RISC-V core as exemplified in Fig. 1 leads to an exception because instruction 0x0000 is illegal in RISC-V.

To the best of our knowledge, our research study is the first to analyze the complexity of LCE attacks when taking advantage of specific vulnerabilities of a RISC-V core. Contrary to ARM or MIPS ISA, the open-source RISC-V ISA and the open-source cores like the cv32e40p make the identification of vulnerabilities completely feasible.

The complexity of ensuring a linear execution may be defined by the number of simultaneous microprobes and their locations. Recently, Skorobogatov performed eight simultaneous microprobes on a chip in [START_REF] Skorobogatov | How microprobing can attack encrypted memory[END_REF]. The more microprobes that have to be used, the more time the attackers will spend to identify their locations and perform FIB edits, which amounts to an increased risk of destroying the chip.

A. Theoretical identification of vulnerabilities

Notation: going forward, the term Discontinuity Instruction (DI) refers to every instruction able to break a sequential execution (e.g., branches and jumps in RISC-V). The term Continuity Instruction (CI) refers to every other instruction.

Three types of attack paths (depicted in Fig. 6) exploiting distinct vulnerabilities are identifiable: (I) Freezing a CI in the instruction register, (II) Editing the incoming instructions or (III) Tampering with the PC. Some of them are either concisely or roughly mentioned in the state of the art [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF], [START_REF] Helfmeier | Breaking and entering through the silicon[END_REF], [START_REF] Anderson | Cryptographic processors-a survey[END_REF], our contribution is to specially study how to take advantage of RISC-V and cv32e40p vulnerabilities.

1) Freezing a CI (I): Freezing a CI in the instruction register leads to increment linearly the PC. Disabling the write enable (we) or clock inputs of the instruction register will freeze the current instruction, using only one microprobe. Thus the same frozen CI is executed repeatedly, while all the memory's instructions pass through the instruction bus. Caution must be taken not to propagate the forcing value into the core. Finding the instruction register inputs is made possible by following the instruction bus already found in order to set the eavesdropping microprobes. The first instructions of codes are often register-initialization (i.e., CI). Thus, a trial-and-error approach to freeze start times may lead to freeze a CI.

2) Editing incoming instructions (II): Editing specific signals of the instruction bus to turn DIs into CIs leads to increment linearly the PC. Every incoming instruction is transformed into a new one to remove all the DIs. The main pitfall is not raising an exception due to invalid RISC-V fields in the created instructions (i.e., opcode, funct3, funct7) or by misaligning load and store. This would fail the LCE attempt. In order to avoid these pitfalls, the simulator framework is useful to detect if an attack path leads to exceptions. A map of the major RISC-V opcodes, taken from documentation [START_REF] Waterman | The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213[END_REF], is given in Table I. Red cells represent DIs, for all of them: inst[6:5] = 11. Cells with an exponent (e.g., LOAF-FP 2 ) show opcodes only used by RISC-V extensions. Firstly, if these extensions are not implemented in the architecture, then forcing bit 5 or 6 of every instruction to 0 will turn DIs into invalid instructions. Secondly, U-type instructions [27, §2.3] (i.e., AUIPC and LUI) are the only CIs to admit all values for their bits from 7 to 31. As a result, at least 4 bits have to be forced to remove all DI without raising an exception. For example, inst[6]=0, inst[4:2]=101, to transform all instructions into AUIPC or LUI, the orange cells in Table I. When using 16-bit compressed instructions, the same forcing is still available once decompressed.

In comparison, for Armv8-A, bits from 26 to 28 of all DIs (named branches in ARM) are equal to 101, according to the documentation [28, p266]. Flipping one of these bits ensures that no DI will be executed. Maier [29, p7], claims that forcing only one bit is enough to ensure linear execution, but consideration should be taken to ensure that no exception will be raised.

Editing instructions by microprobing can be done using the microprobes already set in place to eavesdrop the instruction bus. Identifying the instruction bus is the only identification task for the attackers, but the number of involved microprobes is high.

3) Tampering with the PC (III): Tampering with the PC circuitry may lead to increment linearly the PC. Forcing the PC multiplexer control signal to select the linear increment input (e.g., the input PC+4 in Fig. 6) ensures a linear execution even if a jump instruction is executed (this attack path does not prevent instructions from being executed). On the cv32e40p core (without enabling the Hardware Loop extension), only one microprobe is needed to force the id stage i.pc set o signal of the decoder stage to 0. Finding this signal is feasible by identifying the PC bus and then following it upstream up to the multiplexer. Other design choices for the cv32e40p could increase the number of multiplexer inputs to be tampered with, which would increase the needed number of microprobes.

B. Practical validation of attack paths

The authors used the simulation framework described in Section III to assess the previously described attack paths. All three LCEs attack paths succeeded in extracting instructions The memory segmentation of the Von Neumann RISC-V architecture used is depicted in Fig. 7. The memory is segmented into several sections. Instructions are stored in .init and .text sections, whereas the data is stored in .rodata, .data, .sdata and .sbss. For every code of the Embench suite, all instructions and then all data were successively pointed by the PC and retrieved. A Harvard architecture, with separate memories for instructions and data, or a limitation of PC range will obviously avoid this data extraction.

As noticed, enabling the reset signal of the instruction register led to an exception because the generated 0x0000 is not a NOP but rather an invalid instruction. As discussed, Editing the incoming instructions (II) in Section IV-A2, forcing bit 5 or 6 to 0 without using Floating Point extensions led to an exception. The same LCE attack paths (I) and (II) were also emulated successfully on FPGA (as expected). Fig. 8 exemplifies the oscilloscope waveforms of the three least significant bits of the instruction bus for the Freezing (I) attack path. Bits 0 and 1 are at a high level, revealing the use of full 32-bit instructions. Bit 2 follows the instruction flow of the bus. Though the Tampering with the PC (III) succeeded by simulation, but failed on the microcontroller due to an error in the AXI bus (another attack path to tamper with the PC should be found).

The Experimental Setup exhibits the complete extraction of the instructions and data from memory by the three identified attack paths. The complexity in terms of the number of microprobes for every attack path was confirmed by simulations, and the exceptions suspected to occur were observed.

C. Attack path complexity

Carrying out an LCE is not always done under ideal condition. The starting address pointed by the PC could be at the end of the .text section. In that case, an iterative approach is possible by progressively delaying the start of the LCE (i.e., when specific signals are forced) until it reaches the execution of a DI jumping to one instruction at the beginning of the .text section. Delaying the start of the LCE is impossible by LASER or FIB editing of the specific signals instead, microprobes must be used. Note that such an iterative approach could also be used to defeat Kommerling's countermeasure presented in Section II-C6, based on PC partitioning [START_REF] Kömmerling | Design Principles for Tamper-Resistant Smartcard Processors[END_REF] by retrieving the memory content piece by piece.

Therefore, in addition to eavesdropping microprobes, microprobes to induce a linear execution have to be set according to the attack path. The most common attack path in the state of the art: Editing the incoming instructions (II) means installing four microprobes on the instruction bus to induce a linear execution of a RISC-V core. Freezing a CI (I) requires placing only one microprobe on the cv32e40p which is easier to locate compared to Tampering with the PC (III). By enabling the cv32e40p Hardware Loop extension or improving the multiplexer design, additional microprobes are required in order to Tamper with the PC (III).

V. COUNTERMEASURES

Countermeasures against LCE are intended to be integrated into relatively simple embedded systems (e.g., inside ink cartridges). They have to be efficient while remaining lightweight.

A. Countermeasure description

Countermeasures must be able to handle the LCE attack paths revealed in Section IV. For the Freezing (I) and Editing (II) attack paths, the instructions coming from the memory are altered. As a result, a full software countermeasure is not possible as the countermeasure instructions could be erased or modified preventing their execution. Thus, the authors chose a hardware-based approach. Nevertheless, from the core point of view, during (I) or (II) LCE attacks, nothing wrong happens. The core receives and executes legal instructions. It cannot detect the occurrence of corrupted ones because it is not able to recognize a corrupted instruction. However, the core can detect some instructions are missing or have been tampered with. This is the operating principle of our first countermeasure.

1) Security Markers Monitoring (SMM):

The SMM countermeasure consists of regularly inserting a custom instruction called Security Marker (SM) into the code, and then checking the steady presence of SMs after the instruction register. When an LCE is performed by Freezing (I) or Editing (II), incoming SMs are erased/edited and will be missing in the checking logic.

An SM monitoring component located after the instruction register is added to count the number of instructions executed between two SMs. Beyond a certain threshold, an LCE killer reaction is triggered. This threshold is configurable and defines the LCE detection latency of the countermeasure, it is called Detection Latency Target (DLT). An SM insertion component is added at the output of the program memory before the instruction bus. It inserts SMs on a regular basis, following the DLT. This insertion works by replacing the incoming instruction with an SM. In order to reread the replaced instructions from memory, SM execution must not increase the PC value. Incidentally, freezing an SM in the instruction register maintains the PC value and does not induce a linear execution. The SM insertion and monitoring components are depicted (in red) in Fig. 9.

The RTL descriptions of RISC-V open-source cores are editable which allows the insertion of components. The opensource RISC-V ISA is designed to easily add custom instructions like SM. The execution of SM created a clock cycle overhead. This overhead can decrease with the growth of DLT as expressed in 1. The cpi SM M is the average of cycles per instruction in the executed code, and n is the number of needed cycles to execute an SM.

Clock cycle

overhead = 1 cpi SM M • DLT n -1 (1)
2) Discontinuity Instruction Monitoring (DIM): The DIM is an enhanced version of SMM to reduce the clock cycle overhead by treating DI as SM. When an LCE is performed by Freezing (I) or Editing (II), every incoming DI is erased. Therefore, DIs are missing after the instruction register. The monitoring component counts the number of instructions executed between two SMs, two DIs or one SM and one DI. Therefore, inserting an SM is only necessary when there are not enough DIs (i.e., when a Basic Block (BB) is longer than the DLT). A BB is a straight-line code sequence without DIs until the end of the sequence.

Reducing the number of inserted SMs decreases the clock cycle overhead as expressed in [START_REF] Loebbecke | Pay TV piracy and its effects on Pay TV provision[END_REF]. The clock cycle overhead depends only on the size |BB i | and the execution numbers e i of every BB i . Knowing the exact path taken on the Control Flow Graph for an execution is the only way to calculate the clock cycle overhead. The simulator framework presented in Section III makes it possible to measure the clock cycle overhead for several codes. The cyc ori is the number of cycles needed to execute the original code.

Clock cycle overhead = 1 cyc ori • n i |BB i | DLT • e i (2)
Checking that there are not too many consecutive incoming branches is a practical way to address an attack path that aims to freeze a branch with a false condition in the instruction register.

3) Linear Addressing Monitoring (LAM): The LAM monitors the length of linear execution sequences by analyzing PC updates. The LAM addresses the three identified attack paths to perform an LCE, including PC tampering (III). Only a monitoring component, depicted in Fig. 9, counts the number of cycles between two non-linear PC addressing (i.e., when the next PC is different from PC, PC+2 or PC+4 in RISC-V). Beyond a threshold, the LCE-killer reaction is triggered. This triggering threshold must be defined, considering the executed codes to never be exceeded in nominal execution. This threshold defines the detection latency, which is usually higher than the DLT of the previous countermeasures. As there is no need to insert any instruction, there is no clock cycle overhead. Many varieties of LAM can be designed, such as monitoring the driving signal of the PC multiplexer instead of the PC.

Theoretical characterizations of the three countermeasures are summarized in Table II, and are compared to the experimental ones in Section V-C. The area overhead is limited to a bit of combinational logic (measured at approximately one percent of cv32e40p in Section V-C) in addition to one counter for the LAM monitoring component. For SMM and DIM, two smaller counters are required: one for SM insertion and one for SM/DI monitoring components. These counters are smaller, as the DLT may be smaller than the LAM threshold.

A low DLT reduces the amount of extractable code before the triggering of the LCE-killer reaction. Clever access mechanisms which successively extract a small amount of code to rebuild the code are conceivable for high detection latency. However, with a small DLT, these clever access mechanisms are difficult to implement. The final instructions of the longest BBs will never be reached before the LCE-killer is triggered.

B. Further countermeasure issues

There are secondary issues to consider in order to better the full operability of countermeasures.

1) LCE-killer reaction: The LCE-killer reaction following detection is not in the scope of this paper. It has to stop the extraction. Basically, the reaction can be the same as for mesh or Probe Attempt Detector: causing a memory or circuit reset to avoid the access of memory-sensitive contents. A generation of null or random instructions from the memory is quite interesting to make attackers believe they succeed.

In order to avoid tampering with the reaction trigger signal, the pattern of "there is no LCE detected" has to be complex. Ideally, it should alternate between 0 and 1 in the nominal mode and at best it should be based on a lightweight ciphering as applied to active shield in [START_REF] Ngo | Cryptographically secure shield for security IPs protection[END_REF]. Thus, circumventing our countermeasures will require more microprobes, a lot of LCE trial and error testing, and therefore more time.

2) Better to insert SMs on-the-fly than at the compilation: Instead of inserting SMs on-the-fly using a hardware component, the SMs could be inserted in the compilation flow. However, the code to be stored in memory is longer due to SMs added. Moreover, SMs must be inserted more often, as all edges of the Control-Flow Graph have to be considered, which ultimately increases the clock cycle overhead. On the other hand, the regularity of the on-the-fly insertion is the lowest one which doesn't exceed the monitoring counter threshold.

These three lightweight and hardware countermeasures are adaptable to every core architecture with an instruction bus and a PC (i.e., all existing cores). Depending on the threat, a specific use of these countermeasures is definable. For example, by using several instances of the DIM and LAM countermeasures to make the LCE very difficult to achieve.

C. Countermeasure practical evaluation

The Experimental Setup made it possible to assess the effectiveness of the countermeasures we created.

1) Countermeasure implementations: The three conceived countermeasures have been implemented in the cv32e40p core. Access links to their RTL description is provided in Section VII. Each CM makes use of a dedicated counter to monitor the core activity and to detect LCE attacks. Table III summarized when it is initialized, its initialization value, and when it is decreased. The role of the counter is to measure the time elapsed between two initialization events (expressed in executed instructions or clock-rising edges. For the LAM the initialization value was set to 105, as this is the minimal threshold value that did not trigger the alarm in nominal mode while testing the Embench codes. For the SMM and DIM countermeasures, ranging DLTs were tested by initializing the counter from 5 to 150, in order to measure the corresponding clock cycle overhead.

Decreasing the SMM and DIM counters at every executed instruction instead of every rising clock edge, allows disregarding instructions executed in several cycles. This leads to less frequent insertion of SMs without extending the detection latency. As the LAM is located on the PC bus, it should operate 2) Practical characterization: Campaigns of simulated executions were following the effectiveness and the characterization claims of the three countermeasures. The Freezing (I) and Editing (II) attack paths were detected by the three countermeasures, while only LAM detected the PC tampering (III).

a) Detection Latency: The measured detection latencies met the DLT for SMM and DIM, and 105 for the LAM. In a nominal mode for LAM, the use of a threshold lower than 105 raised an alarm on at least one of the Embench codes. From the FPGA-based demonstration, the oscilloscope waveform of the reaction trigger signal raised during an LCE is plotted in Fig. 10. The LCE begins from the first rising clock edge and the DLT was set to 15 executed instructions. The detection between the beginning of the LCE and the alarm trigger is about 15 cycles, which is consistent, as instructions executed while an LCE is performed need only one cycle.

b) Clock cycle overhead: There is no clock cycle overhead for the LAM as it does not involve the insertion of SMs. Fig. 11 displays the clock cycle overhead of the SMM and DIM solutions for the Embench codes. It depends on the specificity of each code, as expressed in (1) and (2). Only some Embench codes are displayed for readability issues. As SMs -encoded as JAL x0, 0 -need two cycles to be executed (n = 2), both clock cycles overhead could be reduced by a factor of two if the core was edited to speed up the execution of SMs. The reduction of the clock cycle overhead using the DIM is noteworthy. The DIM graph reveals that codes like cubic or nbody contain BBs longer than 15 instructions which are executed plenty of times. The DIM countermeasure with The effect of DLT on the clock cycle overhead is drawn in Fig. 12. The cpi SM M is approximated to 1. The clock cycle overhead is basically decreasing for a growing DLT. The SMM average overhead matches the theoretical estimation from (1). Additional component logic increases the core logic propagation delays, which may decrease the maximum clock frequency. In the FPGA design flow, after implementation, the Worst Negative Slack was reduced by 2.07% compared to the unprotected microcontroller (from 30.812 ns to 30.173 ns). Countermeasures may therefore slightly limit the maximum frequency of the clock.

c) Area overhead: The area overhead is lightweight but depends on the DLT. The slice LUTs and Registers utilization measured for two DLT values in the FPGA design flow, after implementation, are given in Table IV. The LAM includes only a monitoring component with a DLT of 105 (equivalent to 127), which creates a 0.52% LUT overhead. It is lighter than SMM and DIM. Indeed, those include monitoring and hardware insertion components. Their DLT may be as small as 15, which created a 1.47% LUT overhead. Nonetheless, the increased area overhead for any of the three countermeasures is very low. As a guide, the core-v-mcu microcontroller contains around 48,900 LUTs.

3) Discussions: The authors did not report on the effect of RISC-V extension on the countermeasures design. They did not identify any predictable incompatibility (though it could be ascertained with the proposed simulation framework).

Only the compressed extension challenges the hardware insertion of SMs. The insertion requires replacing the 32 incoming bits with an SM. The risk is to partially replace two incoming unaligned instructions, by an aligned SM, which leads to the creation of two undesired instructions. Information about PC alignment from the core or the memory is needed to address this issue.

The SMM and DIM countermeasures could be enhanced to address the Tampering with the PC (III) attack path, by implementing an original jump or kill mechanism. It would require adding in the code successively: an instruction that jumps over the following instruction and a custom kill instruction which initiates the LCE-killer process if executed. If the jump instruction is not properly executed due to Tampering with the PC (III), then the kill instruction is executed and it triggers the LCE-killer reaction. Implementation and tests could be viable and interesting avenues for future studies.

VI. CONCLUSION

LCE is an invasive attack aiming at fully extracting a code from a device's memory for reverse engineering purposes. The threat is real and routinely exploited by manufacturers of compatible products (e.g., ink cartridges or gamepad controllers) who can fund the required expensive FA tools. The first contribution of this work is to reveal types of LCE attack paths to induce a linear read of the memory of a targeted RISC-V core. Three attack paths were introduced, notably two of which are linked to vulnerabilities of the instruction register and the PC circuitry. The vulnerability based on instruction editing appears more as a theoretical threat than a practical one because it requires tampering with and forcing at least four bits of the instruction bus. The increase in the number of microprobe-required renders this attack path impractical. These vulnerabilities were assessed through simulations or FPGA-based demonstration thanks to our proposed Experimental Setup (both frameworks we developed are made available on an open-access basis).

To address LCE threats on embedded devices, lightweight countermeasures were introduced. The original approach of monitoring the LCE symptoms leads to an area overhead around 1% of the unprotected cv32e40p core. A widespread deployment on many embedded devices is therefore conceivable. Thanks to the configurable DLT, countermeasures can be adapted to every use case. For example, by decreasing the clock cycle overhead to less than 1% with a DLT lower than 25 instructions executed for DIM. The clock cycle overhead is null for LAM. All these countermeasures were implemented, successfully validated, and characterized by the Experimental Setup, in simulations and FPGA-based demonstration.

VII. AVAILABILITY

The RTL description of the three countermeasures integrated in the cv32e40p core and the Experimental Setup are available (https://github.com/theophile-gousselot/linear code extraction). Additional documentation and step-by-step tutorial help to better understand the Experimental Setup and to reproduce the results of this paper. Moreover, original attack paths and countermeasure variants can be tested.

  induce a linear execution : LCE attack effects : Hardware components

Fig. 1 .

 1 Fig. 1. LCE operation on an Integrated Circuit overview.

Fig. 2 .

 2 Fig. 2. Example of a cross pad built by Focus Ion Beam edits.

Fig. 3 .

 3 Fig. 3. Functional simulation framework.

Fig. 4 .

 4 Fig. 4. FPGA-based demonstration framework.

Fig. 5 .

 5 Fig. 5. Setup of the board with probes connected to the oscilloscope.

Fig. 6 .

 6 Fig. 6. Three types of identified vulnerabilities.

Fig. 8 .

 8 Fig. 8. Waveforms of the clock and the three bits of the instruction bus.

Fig. 9 .

 9 Fig. 9. Potential locations for the monitoring component of every countermeasure. SMs are inserted by a hardware component for SMM and DIM.

Fig. 10 .

 10 Fig. 10. Alarm signal raised during an LCE.

c r c 3 2 c u b ic e d n h u f f b e n c h m a t m u lt -i n t m d 5 s u m m in v e r m o n t 6 4 n b o d y n s ic h n e u t a r f in d w ik is o rFig. 11 .

 11 Fig. 11. Clock cycles overhead depending on the DLT for Embench codes.

Fig. 12 .

 12 Fig. 12. Clock cycles overhead depending on the DLT.

  MSUB 2 NMSUB 2 NMADD 2 OP-FP 2 reserved custom-2/rv128 4

			TABLE I RISC-V BASE OPCODE MAP, INST[1:0]=11.
	[4:2]	000	001	010	011	100	101	110
	[6:5]
	00 LOAD LOAD-FP 2 custom-0 4 MISC-MEM OP-IMM AUIPC OP-IMM-32 3
	01 STORE STORE-FP 2 custom-1 4 AMO 1	OP	LUI	OP-32 3
	10 MADD 2
	11 BRANCH	JALR	reserved	JAL	SYSTEM reserved custom-3/rv128 4
	Atomic (A) 1	Discontinuity instructions Floating point (F, D, Q) 2	U-type instructions RV64/128 Base 3 Custom opcodes 4
	and data from memory, without raising exceptions due to linear execution.
	Memory
	.vectors
		.init
			PC
		.text
	.rodata .data .sdata .stack .sbss	Linear code extraction
	Fig. 7. Memory segmenta-tion.

TABLE II THEORETICAL

 II CHARACTERIZATION OF COUNTERMEASURES.

		Countermeasures	Detection latency	Attack path covered	Clock cycle overhead	Area overhead
	SMM	Security Markers Monitoring	configurable (DLT)	(I) (II)	decreasing with DLT	negligible
	DIM Discontinuity Instruction Monitoring	configurable (DLT)	(I) (II)	decreasing sharply with DLT	negligible
	LAM	Linear Addressing Monitoring	higher (code depending)	(I) (II) (III)	null	negligible
	without the information that an instruction has been executed, thus it decreases at every rising clock edge. As explained in Section V-A1, an SM must initialize the counter and not increment the PC. To simplify the implementation, SMs are encoded as JAL x0, 0, since there is none in Embench codes.

The ARSENE project was funded by the "France 2030" government investment plan managed by the French National Research Agency, under the reference "ANR-22-PECY-0004".

This research was also funded by the European Union under grant agreement no. 101070008.


Adrian-Gabriel Chifu

Sébastien Déjean
email: sebastien.dejean@math.univ-toulouse.fr

Josiane Mothe
email: josiane.mothe@irit.fr

Zia Ullah
email: m.ullah@napier.ac.uk

Can we predict QPP? An approach based on multivariate outliers

Keywords: Information Retrieval, Query performance prediction, QPP, Post-retrieval features, Multivariate outlier detection

Query performance prediction (QPP) aims to forecast the effectiveness of a search engine across a range of queries and documents. While state-of-the-art predictors offer a certain level of precision, their accuracy is not flawless. Prior research has recognized the challenges inherent in QPP but often lacks a thorough qualitative analysis. In this paper, we delve into QPP by examining the factors that influence the predictability of query performance accuracy. We propose the working hypothesis that while some queries are readily predictable, others present significant challenges. By focusing on outliers, we aim to identify the queries that are particularly challenging to predict. To this end, we employ multivariate outlier detection method. Our results demonstrate the effectiveness of this approach in identifying queries on which QPP do not perform well, yielding less reliable predictions. Moreover, we provide evidence that excluding these hard-to-predict queries from the analysis significantly enhances the overall accuracy of QPP.

Introduction

A search engine aims to process and answer any user query by retrieving relevant documents. However, the performance of a particular search engine can vary substantially depending on the specific queries it encounters [START_REF] Harman | Overview of the reliable information access workshop[END_REF][START_REF] Deveaud | Learning to adaptively rank document retrieval system configurations[END_REF].

Query performance prediction (QPP) addresses the crucial task of predicting how effective a system will be on a given query [START_REF] Zhou | Query performance prediction in web search environments[END_REF][START_REF] Carmel | Estimating the query difficulty for information retrieval[END_REF][START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF]. This problem is of paramount importance for two primary reasons. Firstly, when a query is expected to be difficult, it may be necessary to adopt a specialized, albeit potentially costly, approach. Conversely, when a query is predicted to be easy, a simpler and more cost-effective method can be employed [START_REF] Cronen-Townsend | Predicting query performance[END_REF][START_REF] Amati | Query difficulty, robustness, and selective application of query expansion[END_REF][START_REF] Déjean | Studying the variability of system setting effectiveness by data analytics and visualization[END_REF].

QPP accuracy is typically assessed by measuring the correlation between the predicted and the actual performance values [START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF][START_REF] Raiber | Query-performance prediction: Setting the expectations straight[END_REF][START_REF] Faggioli | smare: a new paradigm to evaluate and understand query performance prediction methods[END_REF][START_REF] Datta | A'pointwise-query, listwisedocument'based query performance prediction approach[END_REF]. This approach is sound as long as the underlying assumptions and conditions for applying correlation measurements are respected [START_REF] Anscombe | Graphs in statistical analysis[END_REF].

Systems vary in their approach to processing a given query. This variability encompasses processes such as automatic query reformulation, the choice of the weighting/matching function (BM25 [START_REF] Robertson | The probabilistic relevance framework: Bm25 and beyond[END_REF], a Language model [START_REF] Zhai | A study of smoothing methods for language models applied to information retrieval[END_REF], or an LLMbased model [START_REF] Devlin | Bert: Pre-training of deep bidirectional transformers for language understanding[END_REF][START_REF] Liu | Roberta: A robustly optimized bert pretraining approach[END_REF][START_REF] Clark | Electra: Pre-training text encoders as discriminators rather than generators[END_REF][START_REF] Zhu | Large language models for information retrieval: A survey[END_REF], for example), and the application of document reranking models [START_REF] Liu | Learning to rank for information retrieval[END_REF]. Consequently, different systems will perform differently on the same queries [START_REF] Déjean | Studying the variability of system setting effectiveness by data analytics and visualization[END_REF]. QPP is thus considered with regard to the system it predicts the performance for. This implies that a QPP predictor should adapt its behavior to suit a particular system. This could be a reason why post-retrieval QPPs, which use the results of the search, tend to be more accurate than preretrieval ones, which rely solely on the query and the set of documents [START_REF] Hauff | A survey of pre-retrieval query performance predictors[END_REF][START_REF] Jafarzadeh | A semantic approach to post-retrieval query performance prediction[END_REF].

We found for example that LemurTF_IDF, a post-retrieval QPP corresponding to a Letor feature [START_REF] Cao | Learning to rank: from pairwise approach to listwise approach[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF] has a higher correlation with the actual Average precision (AP) obtained with the LGD weighting function [START_REF] Clinchant | Information-based models for ad hoc ir[END_REF] than with the JS weighting function [START_REF] Amati | Frequentist and bayesian approach to information retrieval[END_REF] (resp. 0.522 and 0.504 Pearson correlation). On the other hand, two predictors will behave differently on a particular system (Fig. 1). In Figure 1, we can see that the correlation is relatively weak, which is accurately reflected by the 0.484 (resp. 0.552) Pearson correlation values. Current QPP models lack accuracy. Single features, even post-retrieval ones could not demonstrate high correlation with actual performance [START_REF] Hauff | A survey of pre-retrieval query performance predictors[END_REF][START_REF] Carmel | Estimating the query difficulty for information retrieval[END_REF][START_REF] Faggioli | Query performance prediction for neural ir: Are we there yet?[END_REF]; even the com-bination of predictors, which is out of the scope of this paper, has not been very successful [START_REF] De | Automatic classification of queries by expected retrieval performance[END_REF][START_REF] Zhou | Query performance prediction in web search environments[END_REF][START_REF] Raiber | Query-performance prediction: Setting the expectations straight[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF][START_REF] Mizzaro | Query performance prediction and effectiveness evaluation without relevance judgments: Two sides of the same coin[END_REF][START_REF] Roy | Estimating gaussian mixture models in the local neighbourhood of embedded word vectors for query performance prediction[END_REF].

In this paper, we aim to analyze performance prediction deeper. Past studies showed that predictors do not work well when considering all queries. We hypothesize that prediction accuracy can significantly vary among queries, and our objective is to identify the queries for which the predictor fails to estimate the effectiveness. In other words, we want to predict the predictability of performance and address the following research question: Is it possible to predict the queries for which a QPP can provide an accurate effectiveness estimation for a given system? To put it differently, can we concentrate on those queries that are more likely to yield accurate predictions and perhaps automatically disregard queries that are more challenging to predict? Some queries can be considered outliers (abnormally easy or difficult); similarly, predictions may have abnormal values. We hypothesize that the queries with abnormal prediction values are difficult to predict or get unreliable predictions. To tackle this problem, we consider multivariate outlier detection as a means to identify these hard-to-predict queries. Since a given QPP may behave differently to estimate the effectiveness of a system, the idea is to consider multiple QPPs in the query identification phase.

We consider several effectiveness measures and several benchmark collections. We show that our hypothesis could pave the way for a new research direction on QPP on accuracy predictability.

Identification of difficult to predict queries by TRC

Here, we hypothesize that some predictions are outliers because the queries are difficult to predict. We aim to identify those queries for which we anticipate the QPP will not be accurate.

Johnson defines an outlier as an observation in a data set that appears to be inconsistent with the remainder of that set of data [START_REF] Johnson | Applied multivariate statistical analysis[END_REF]. Univariate methods consider each variable independently, so only observations that appear odd for that variable are detected, while in the case of multivariate outlier detection, the interactions among different variables are compared. Multivariate outliers are a combination of unusual scores on several variables [START_REF] Peña | Multivariate outlier detection and robust covariance matrix estimation[END_REF], and the idea is to detect the observations that are located relatively far from the center of the data distribution [START_REF] Ben-Gal | Outlier detection[END_REF]. To identify outliers, we thus consider here multivariate outliers and identify the queries for which predictions are abnormal for different QPPs.

Mahalanobis distance is a common criterion for multivariate outlier detection. Applied to QPP, the Mahalanobis distance for a given query q i , from a set of n queries Q = {q 1 , q 2 , . . . , q n }, can be defined as follows:

D M (q i , Q) = (q i -q) T V -1 n (q i -q), (1)
where the query vector q i is composed of m (n >> m) predictor values q i = p i 1 , p i 2 , . . . , p i m , q is the mean vector of the queries, and V -1 n is the inverse of the covariance matrix of the queries. The superscript T denotes the transpose of the vector. We used the Transformed Rank Correlations (TRC) for multivariate outlier detection function implemented in R in this paper [START_REF] Béguin | Multivariate outlier detection in incomplete survey data: the epidemic algorithm and transformed rank correlations[END_REF] 7 . Instead of working with the raw data, which might be skewed or have a non-normal distribution, the TRC method works with the ranks of the data. This involves sorting the data from smallest to largest and using their position in this sorted order as their value. It then calculates the Spearman rank correlation or a similar non-parametric correlation measure between all pairs of variables. This helps in understanding the underlying structure and relationships in the data, which is crucial for identifying outliers in a multivariate context. The TRC method calculates a distance measure for each observation in the multivariate space. This distance is typically based on rank correlations and reflects how far away each observation is from the central trend of the data. It then determines a threshold for these distances (default value is set to the 0.95 quantile of F-distribution). Observations with a distance greater than this threshold are flagged as outliers.

Data

In this study, we use TREC adhoc collections: TREC78 with 528K documents and 100 queries (351 -450) and WT10G which consists of 1.692M documents and 100 queries (451 -550). We use Average Precision (AP@1000) [START_REF] Sakai | On the reliability of information retrieval metrics based on graded relevance[END_REF] and normalized Discounted Cumulative Gain (nDCG@20) [START_REF] Järvelin | Ir evaluation methods for retrieving highly relevant documents[END_REF] as measures to evaluate the search engine performance, which are common in adhoc retrieval. Like previous studies on QPP [START_REF] De | Automatic classification of queries by expected retrieval performance[END_REF][START_REF] Zhou | Query performance prediction in web search environments[END_REF][START_REF] Carmel | Estimating the query difficulty for information retrieval[END_REF][START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF][START_REF] Raiber | Query-performance prediction: Setting the expectations straight[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF], we use Pearson correlation as a measure to evaluate the accuracy of the QPP, in addition to plots as recommended in statistics. Pearson correlation measures the linear correlation between the predicted effectiveness of queries and their actual effectiveness. It indicates how well the QPP method predictions align with the actual query performances. Although it may not be a perfect measure [START_REF] Mothe | On correlation to evaluate QPP[END_REF], we kept it in this study. Alternative measures will be used in future work. We will consider other measures such as Mean Squared Error (MSE), Mean Absolute Error (MAE) or its normalized variant. The former measures the average of the squares of the errors between predicted and actual query effectiveness. The latter measures the average of the absolute differences between predicted and actual values. It is less sensitive to outliers compared to MSE. These two measures could help in understanding the magnitude of the prediction errors.

We consider a series of systems that treat the same queries over the same set of documents. In this study, we construct systems using Terrier [START_REF] Ounis | Terrier information retrieval platform[END_REF]. These systems differ on several factors: the scoring function employed and the variant of the query reformulation module utilized, if any. We report the results on the best system according to the considered collection and performance measures, the best in terms of the average effectiveness over the set of queries. We also used a reference system based on LM Dirichlet [START_REF] Zhai | A study of smoothing methods for language models applied to information retrieval[END_REF].

In this study, we consider the first four Letor features which have been shown as among the most accurate for single feature QPP [START_REF] Cao | Learning to rank: from pairwise approach to listwise approach[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF]. Letor features have been initially used for retrieved document re-ranking [START_REF] Cao | Learning to rank: from pairwise approach to listwise approach[END_REF]. Letor features are associated with each (query, retrieved document) pair8 . To obtain a single value for each query for a given letor feature, the values are aggregated over the documents. We used maximum as the aggregation function which has been shown as the most accurate for QPP [START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF]. The four features we kept are LemurTF_IDF, In_expC2, InB2, and InL2, aggregated using the maximum function. We also consider four state-of-the-art QPP: Normalized query commitment (NQC) [START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF], Unnormalized query commitment (UCQ) [START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF], QF (query feedback) [START_REF] Zhou | Query performance prediction in web search environments[END_REF] and WIG [START_REF] Zhou | Query performance prediction in web search environments[END_REF] .

These features will be used individually to predict system performance. Although methods that combine features have been shown more accurate, here the objective is to conduct a first study on how to detect queries that are difficult to predict. We though opted for simple prediction models (single feature); we will analyze the proposed method for more complex models. Complex models that involve several features need to be trained. Here since we are not training a model, we do not need to split the data into train and test. Outlier queries are different according to the considered QPP, which shows the importance of using multivariate outlier detection (Fig. 2). For example, query 403 is a clear outlier for InL2 QPP (top right of the right-side sub-figure) Fig. 3. Outlier queries are correctly identified. Queries that have been detected as outliers by our method are displayed in red. X-axis represents the QPP values and Y-axis is the actual AP. Here the values are calculated for LemurTF_IDF on the TREC78 collection and a model based on the LGD weighting function. 18 out of 100 queries were identified as outliers. The red line is the regression when all the topics are considered while the black one is after the outliers were removed.

Results

but not for the other QPPs. This implies that, if we used a univariate method such as LemurTF_IDF in isolation, we would not have identified this query as one that is difficult to predict, even though it truly is (Fig. 3). Similarly, consider Query 369 (shown at the top left in the left-side sub-figure). It clearly stands out as an outlier when evaluated using the LemurTF_IDF QPP, but does not exhibit the same outlier behavior when assessed by the other three QPPs. These two queries (360 and 403) are indeed not well predicted (Fig. 3). In addition, we can see that query 356 has also been accurately identified as an outlier, as well as some other queries (Fig. 3). If these queries were not considered when calculating the correlation, the correlation would be higher.

We can observe that the correlation when considering the outliers only is very weak (Tab. 1, "LemurTF_IDF -Outliers only" row, left-part). This result was expected since we want to remove these difficult to predict queries. On the contrary, when the outlier queries are removed, the correlation between the QPPs and the actual effectiveness measures is much higher (Tab. 1 "No Outliers" rows). Note that if we use univariate outlier detection using LemurTF_IDF predictor only, the correlation decreases (0.658 compared to 0.700 here) (Tab. 1 "Univariate" rows). Results are consistent across the QPPs for TREC78 collection. This consistency remains valid for the best predictor LemurTF_IDF also for WT10G. We also evaluated the results considering other reference systems (NN-based model will be included in future work) and the results were also consistent (e.g., using In_expB2 weighting function). Results are also consistent when considering the other 4 QPP from the literature. Here we consider one single reference system (LM-based), WT10G and TREC Robust collections (Tab. 1, right side part).

Table 1. Pearson correlation is consistently better when queries our method detects as difficult to predict are removed. Correlation between actual effectiveness (either AP or ndcg) on TREC78 and WT10G. We report the number of outlier queries detected, the correlation when outliers are removed using univariate and multivariate methods and when all the queries are considered for the 4 Letor features and 4 other features. The reference system rows indicate the effectiveness on average for the considered measure and set of queries; this is the system that obtained the highest effectiveness measure over a set of system configurations we tried. A unilateral test of significance for the difference between the correlations with "No Outliers" and "All" were performed using the cocor R package [START_REF] Diedenhofen | cocor: A comprehensive solution for the statistical comparison of correlations[END_REF]. A * after a correlation indicates that the p-value of the test is lower than 0.05.

Conclusion

Studies on QPP generally focus on prediction accuracy [START_REF] De | Automatic classification of queries by expected retrieval performance[END_REF][START_REF] Zhou | Query performance prediction in web search environments[END_REF][START_REF] Carmel | Estimating the query difficulty for information retrieval[END_REF][START_REF] Shtok | Predicting query performance by query-drift estimation[END_REF][START_REF] Raiber | Query-performance prediction: Setting the expectations straight[END_REF][START_REF] Chifu | Query performance prediction focused on summarized letor features[END_REF][START_REF] Faggioli | Query performance prediction for neural ir: Are we there yet?[END_REF], but seldom on the difficulty of that prediction. QPP is clearly a difficult task, since current predictors are not very accurate. In this study we show that difficult to predict queries can be detected. We used multivariate outlier detection for that; it has the advantage to consider different QPPs to detect the queries for which the prediction may not be accurate. We also show that removing these automatically detected queries, we have a higher accuracy of the predictor. That means that we know that the predictor is not accurate for some queries that we can identify. This result pave the way to a new research direction: the prediction of the accuracy of the prediction. Some predictor may be accurate for certain queries and not for others. In future work, we will re-examine the results on more benchmark collections and reference retrieval systems. In this study we considered a single feature at a time to make the prediction. In future work, we will consider trained models that combine several features. That will also allow us to consider methods that allow models to abstain from making a prediction when they are not sufficiently confident.

Fig. 1 .

 1 Fig. 1. QPPs behave differently on the same system and set of queries (TREC78). Predicted AP (X-axis) and actual AP (Y-axis) obtained with LGD weighting function and their Pearson correlation. Left side In_expC2 (ρ=0.484) -Right side LemurTF_IDF QPP (ρ=0.552).

Fig. 2 .

 2 Fig. 2. Outlier queries are different according to the QPP. Queries detected as outliers by our method are in red. The four plots correspond to the four QPPs. The X-axis is not meaningful. Y-axis corresponds to the predicted values by the considered Letor QPP. QQP values are calculated for the TREC78 collection.

https://cran.r-project.org/web/packages/modi/modi.pdf

using Terrier (see http://terrier.org/docs/v5.1/learning.html)


.03

Mathematical modelling

Reverse engineering To model these phenomena in order to develop a reverse engineering approach

Our goals

Bioactivities

Nutrient absorption

Kong and Singh, 2008

Gastric phase = a very complex but crucial step for the whole digestion process

The digestive process pH 6.5-6.8

α-amylase

From Roger Lentle, Massey Univ. NZ

.05 In silico models ( )

Human models

De

12 12 1 1 12 1 whey caswpd aggr caswpd k V m k m    =  -  +  
Le Feunteun et al.

2014, 2020

In vitro static models (infant, adult, elderly) Acid Gel

Rennet Gel Infant formulas: can we create lipid structures biomimetic on the native fat globule?

Formula T1 Formula T2 Formula T3

Interface 100 % phospholipides 40% vegetable oil + 60% milk fat

  understand the mechanisms of breakdown of food matrices and their constituents in the gut and identify the beneficial/deleterious food components released during digestion To determine the impact of the structure of food matrices on nutrient bioavailability

From→

  caseins, 10 g/L whey proteins, 95 g/L lactose and minerals + marker of the meal transit (Cr 2+ -EDTA) → Gastric emptying half-time delayed proteins transit → delayed AA absorption maximal AA concentration in the plasma

•

  More bioactive peptides identified during digestion of acid gel than rennet gel • Nature of peptides is identical (clearly defined by the digestive enzyme specificity) • Kinetics of release are different More than 16000 peptides identified by LC-MS-MS in the jejunum Macroscopic scale Differential behaviour of acid/rennet gels in gastric conditions  Acid/Rennet gel: identical composition, similar pore size  ≠ Time of residence in the stomach (Acid 148 min /Rennet 352 min)  How can we explain this difference? Dynamic in vitro digestion of the 2 and rennet gels in the stomach during in vitro dynamic digestion Formation of a strong coagulum with rennet gel → slow down the gastric emptying of caseins The structure that a food adopts in the stomach is essential to plant-based foods: 2 solids / 2 liquids Protein digestibility with a dynamic in vitro digestion model Dynamic in vitro digestion DiDGi ® with Nile Red and proteins stained with Fast Green. Distribution of non-encapsulated and encapsulated DHA oil in omelets. The particle size of heat-denatured WPI on average is 42 nm. Around 10-25% and 40-70% of ingested TAG can be hydrolyzed in gastric and intestinal phase, respectively (Bauer et al; Carriere et al.

STOMACH NERDT™ : the NEar Real Digestive Tract

	Xiao Dong Pro-Health
	Smart Digestion
	Suzhou University
	Nau F, & Dupont D.
	INRAE, Rennes, France

Macroscopic scale Protein Sequence Activity Reference 4 20 50 105 165 225 315

	s	1-23	EMUL	Shimizu et al. (1984)
	s	23-34	HYP	Maruyama & Suzuki (1982)
	s	30-45	MB	Meisel et al. (1991)
	s	40-52	MB	Adamson & Reynolds (1996)
	s	43-58	MB	Meisel et al. (1991)
	s	91-100	STRE	Miclo et al. (2001)
	s	99-109	MIC	McCann et al. (2006)
	s	167-180	MIC	Hayes et al. (2006)
	s	180-193	MIC	Hayes et al. (2006)
	s	1-24	MB	Miquel et al. (2005)
	s	124-146	MB	Miquel et al. (2005)
	s	183-206	TRAN	Kizawa et al. (1996)
	s	183-207	MIC	Recio & Visser (1999)
	s	189-197	HYP	Maeno et al. (1996)
	s	190-197	HYP	Maeno et al. (1996)
		1-24	MB	Bouhallab et al. (1999)
		33-52	MB	Miquel et al. (2005)
		60-80	OPI	Jinsmaa & Yoshikawa (1999)
		98-105	OXI	Rival et al. (2001)
		114-119	OPI	Jinsmaa & Yoshikawa (1999)
		132-140	HYP	Robert et al. (2004)
		192-209	IMM	Coste et al. (1992)
		193-202	IMM	Kayser & Meisel (1996)
		193-209	IMM	Coste et al. (1992)
		18-24	HYP	Lopez-Exposito et al. (2007)
		106-116	THR	Jolles et al. (1986)
	-lg	32-40	HYP	Pihlanto-Leppala et al. (2000)
	-lg	92-100	MIC	Pellegrini et al. (2001)
	-lg	142-148	HYP	Mullally et al. (1997)

Bioactive peptides released during digestion differ from one matrix to another Barbé et al. 2014 Food Res Int

	Protein	Sequence	Activity	Reference	4	20	50	105	165	225	315
				Adamson	&	Reynolds
	s	40-52	MB		(1996)
	s	43-58	MB	Meisel	et	al.	(1991)
	s	99-109	MIC	McCann	et	al.	(2006)
	s	167-180	MIC	Hayes	et	al.	(2006)
	s	180-193	MIC	Hayes	et	al.	(2006)
	s	1-24	MB	Miquel		et	al.	(2005)
	s	189-197	HYP	Maeno	et	al.	(1996)
		33-52	MB	Miquel		et	al.	(2005)
		166-175	HYP	Hayes	et	al.	(2007)
		193-202	IMM	Kayser	&	Meisel	(1996)
	-lg	92-100	MIC				(8))
	-lg	142-148	HYP				(9))

Microscopic scale

minipigs (20 ± 1kg)

What happens when they become older (140 d)?

Vegetable Dairy Lipids Human milk

If animals are submitted to a nutritional stress (high fat/sugar diet), some differences remain in: * the microbiota composition * the fecal metabolome with different metabolites (including propionate) * the immune system with a reduced susceptibility to inflammation with milk lipids

Conclusion

The structure/composition of food regulate the kinetics of protein digestion in the gastrointestinal tract and the release of amino acids in the bloodstream

Being able to design food structures for controlling the kinetics of hydrolysis of macronutrients will allow to obtain food particularly adapted to specific population Omic technologies (proteomics, peptidomics, lipidomics…) are great tools to identify the molecules that are released in the gut during digestion and assess the bioaccessibility of nutrients Main objective: understanding the mechanisms of food digestion

39

• Harmonize the methodologies and propose guidelines for performing experiments

• Validate in vitro models towards in vivo data (animal and/or human)

• Identify the beneficial/deleterious components that are released in the gut during food digestion

• Determine the effect of the matrix structure on the bioavailability of food nutrients and bioactive molecules

• Develop new in vitro, in vivo and in silico digestion models including some for specific populations (infant, elderly)