Interrupt handling

Abstract

It is proposed to implement an interrupt that includes the following steps: (a) hardware pushes registers to memory and sets a program counter to an interrupt service routine; (b) a checksum is generated over the registers and the checksum is stored; (c) the code of the interrupt service routine is executed; (d) the checksum is verified using the stored checksum and the stored registers; and (e) the hardware pops the registers from memory and restores the program counter.Alternatively, the following steps can be performed: (a) hardware pushes registers to memory and sets a program counter to an interrupt service routine; (b) performs a verification; (c) generates a checksum over the registers and the checksum and the registers in a buffer; (d) executes the code of the interrupt service routine; and (c) the hardware pops the registers from the buffer and restores the program counter.

Description

[0001] Embodiments described herein relate to interrupt processing.

[0002] According to [https: / / en.wikipedia.org / wiki / Interrupt], ​​an interrupt in digital computers is a request for the processor to interrupt the currently executing code (if permitted) so that the event can be processed in a timely manner. If the request is accepted, the processor suspends its current activities, saves its state, and executes a function called an interrupt handler (or interrupt service routine, ISR) to handle the event. This interrupt is often temporary, allowing the software to resume normal activities after the interrupt handler completes.

[0003] After the interrupt request is accepted, the processor suspends its states (especially registers) in volatile memory, such as RAM. This volatile memory could be subject to an attack that modifies the processor's copy of the registers so that, after the interrupt is completed, processing is based on these modified (spoofed) registers, leading to undefined or undesirable results.

[0004] It is therefore a goal to harden the interrupt against attacks, in particular to prevent the forgery of registers that are temporarily swapped into memory (e.g. stack) during an interrupt.

[0005] This is achieved according to the features of the independent claims. Further embodiments emerge from the dependent claims.

[0006] In particular, the examples proposed herein may be based on at least one of the following solutions. Combinations of the following features may be used to achieve a desired result. The features of the method could be combined with any feature(s) of the device, apparatus, or system, or vice versa.

[0007] A method for performing an interrupt is proposed, comprising the steps: (a) a hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) generating a checksum over the registers and storing the checksum; (c) executing the interrupt service routine code; (d) verifying the checksum using the stored checksum and the stored registers; (e) the hardware pops the registers from memory and restores the program counter.

[0008] It should be noted that steps (d) and (e) may occur in a different order. In particular, these steps may be executed at least partially in parallel. Restoring the program counter may involve setting the program counter to the next instruction that would have been executed had the interrupt not occurred.

[0009] The hardware may be any processing device, a processor, an arithmetic logic unit (ALU), which may in particular include a memory, e.g. register, stack.

[0010] According to one embodiment, the memory is a stack.

[0011] According to one embodiment, in step (b) the checksum is generated by the hardware, software and / or firmware and stored on the stack.

[0012] According to one embodiment, in step (d) the hardware verifies the checksum.

[0013] According to one embodiment - the checksum is generated using a one-way function, - includes the verification in step (d): - calculating a second checksum based on the stored registers using the one-way function; - comparing the second checksum with the stored checksum; - initiating error handling if the second checksum and the stored checksum differ.

[0014] The one-way function can be a hash function. If the second checksum and the stored checksum do not differ, the verification was successful and no error handling is initiated.

[0015] According to one embodiment, in step (b) the checksum is generated by software and the checksum is stored in a buffer.

[0016] This buffer is referred to here as an error detection buffer (FDP).

[0017] According to one embodiment - the checksum is generated using a one-way function, - the verification in step (d) includes: - calculating a second checksum based on the stored registers from memory using the one-way function; - comparing the second checksum with the stored checksum from the buffer; - initiating error handling if the second checksum and the stored checksum from the buffer differ.

[0018] Furthermore, a method for performing an interrupt is proposed, comprising the steps: (a) a hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) conducting verification; (c) generating a checksum over the registers and storing the checksum and the registers in a buffer; (d) executing the interrupt service routine code; (e) the hardware pops the registers from the buffer and restores the program counter.

[0019] According to one embodiment, the checksum is generated using a one-way function.

[0020] According to one embodiment, the verification in step (b) comprises: - Calculating a second checksum based on the stored registers from the buffer using the one-way function; - Comparing the second checksum with the stored checksum from the buffer; - Initiate error handling if the second checksum and the stored checksum from the buffer differ.

[0021] According to one embodiment, the verification in step (b) is performed if an interrupt has previously occurred.

[0022] According to one embodiment, between steps (c) and (d) a pointer is redirected from the memory to the buffer.

[0023] According to one embodiment, the verification in step (b) is performed when no interrupt is being processed.

[0024] Thus, the program in normal operation or another program or routine other than the interrupt can be used to trigger the verification.

[0025] Furthermore, a device for performing an interrupt is provided, the device comprising hardware, software and a memory, and the device is configured to perform the steps: (a) the hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) generating a checksum over the registers and storing the checksum; (c) executing the interrupt service routine code; (d) verifying the checksum using the stored checksum and the stored registers; (e) the hardware pops the registers from memory and restores the program counter.

[0026] The software can be executed as software or firmware on the device.

[0027] According to one embodiment, in step (b) the checksum is generated by the software, hardware and / or firmware and the checksum is stored in a buffer.

[0028] Apparatus for performing an interrupt, the apparatus comprising hardware, software and a memory, and the apparatus is configured to perform the following steps: (a) the hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) conducting verification; (c) generating a checksum over the registers and storing the checksum and the registers in a buffer; (d) executing the interrupt service routine code; (e) the hardware pops the registers from the buffer and restores the program counter.

[0029] According to one embodiment, the verification is performed in software.

[0030] According to one embodiment, the verification step (b) comprises: - Calculating a second checksum based on the stored registers from the buffer using the one-way function; - Comparing the second checksum with the stored checksum from the buffer; - Initiate error handling if the second checksum and the stored checksum from the buffer differ.

[0031] According to one embodiment, the device comprises a processor or an arithmetic logic unit, ALU.

[0032] Embodiments are shown and illustrated with reference to the drawings. The drawings serve to illustrate the basic principle, so that only aspects necessary for understanding the basic principle are illustrated. The drawings are not to scale. In the drawings, like reference numerals denote like features. Fig. 1 shows a schematic diagram comprising steps of a known interrupt handler approach; Fig. 2 shows another interrupt processing that is hardened against attacks; Fig. Figure 3 shows an alternative approach to handling interrupts using software hardening; Fig. Figure 4 shows a variant of a software hardening approach that further reduces the chances of a successful attack during the interrupt.

[0033] Fig. Figure 1 shows a schematic diagram comprising steps of a known interrupt handler approach.

[0034] Step 101: During the execution of normal code stored in memory, each step of the code is addressed by a program counter (PZ, also called an instruction pointer, or IP for short), the code is executed, and the PZ is incremented.

[0035] An interrupt request 102 occurs at a specific time and triggers an interrupt service routine (ISR): Step 103: The hardware pushes the processor's registers onto the stack (memory), the PZ is set to the ISR. Step 104: The ISR is executed. Step 105: The ISR ends, the hardware pops the registers from the stack, the PZ is restored.

[0036] Next, the execution of the normal code (step 101) continues.

[0037] The interrupt begins after interrupt request 102 and ends after step 105. The ISR is executed during step 104.

[0038] Fig. 2 is a modified representation based on Fig. 1, which introduces a certain hardening of the interrupt, in particular of the registers that can be temporarily saved to volatile memory when the interrupt occurs.

[0039] According to step 103, the hardware pushes the registers onto the stack, i.e., the memory. Additionally, in step 201, the hardware generates a checksum of the registers and stores the checksum along with the registers on the stack. The hardware can be the processor (also referred to as the central processing unit, CPU) or a part of it, e.g., an arithmetic logic unit (ALU) of the processor.

[0040] When the hardware fetches the registers from the stack in step 105, an additional step 202 allows the hardware to verify the checksum, also obtained from the stack, with the registers restored on the processor. Verification can be performed by calculating a checksum of the registers obtained from the stack and comparing it with the checksum from the stack (previously calculated in step 301). If a mismatch between the checksums is detected, error handling 203 can be initiated. If no mismatch is detected, execution of the normal code (step 101) continues.

[0041] Error handling may include a security warning, exception handling, processor reset, or notification of any kind.

[0042] The checksum can be calculated using a hash function or any one-way function.

[0043] Fig. 3 shows a modified representation based on Fig. 1, which enables detection of register manipulation by software.

[0044] In Fig. 3, step 104 includes steps 301, 302 and 303.

[0045] In step 301, a checksum is generated over the registers (which have been saved in volatile memory) and this checksum is stored in a buffer, e.g., an error detection buffer (FDP).

[0046] Next, in step 302, the ISR code is executed (according to step 104 in Fig. 1).

[0047] Then, in step 303, the checksum stored in the buffer is verified with a checksum calculated using the registers (stored on the stack by hardware in step 103). If the two checksums differ, error handling 304 is initiated. If no mismatch is detected, the program continues with step 105.

[0048] Error handling may include resetting the processor or providing some type of notification.

[0049] During the execution of the ISR, any manipulation of the registers in memory is detected by the later step 303.

[0050] Fig. Figure 4 shows a schematic representation of a variant of hashing after error detection. Fig. 4 is considered in view of Fig. 1. An error detection buffer (FDP) is used as an example. However, any buffer or memory can be used accordingly.

[0051] After step 103, the processor's registers are pushed onto the stack and the PZ is set to the ISR, which is processed along with some pre- and post-processing within the dashed field 411.

[0052] After step 103, there is a step 407 that calls a function VerifyBuffer() 403. This is explained in more detail below.

[0053] Next, in step 408, the registers are copied from the stack to the FDP, and a checksum CHK1 is generated over the (copied) registers REG. This can be done, for example, using a hash function. CHK1=hash(REG).

[0054] The checksum CHK1 is also stored in the FDP.

[0055] In a subsequent step 409, the ISR code is executed. This essentially corresponds to step 104 in Fig. 1.

[0056] After the ISR code has been processed, in step 410, in order to use the registers REG stored in the FDP, a pointer is redirected to the FDP (for restoring the registers) instead of the stack. This pointer redirection is performed in software and allows the next step 412 to be performed in hardware without the need for any hardware modifications.

[0057] Therefore, in the subsequent step 412, the hardware pops the registers from the FDP (instead of the stack) and restores the PZ to continue the previously interrupted normal program code.

[0058] The VerifyBuffer() function 403 works as follows: If the FDP is empty, e.g. if no interrupt has occurred previously, the VerifyBuffer() function 403 can simply return to the calling entity and no further action is required.

[0059] If the FDP is NOT empty, ie if step 408 was previously executed, the FDP includes the registers REG and the checksum CHK1. Thus, the VerifyBuffer() function 403 can generate another checksum CHK2=hash(REG) based on the same hash function and the registers REG previously stored in the FDP. Then the VerifyBuffer() function 403 can compare the two checksums CHK2=CHK1 ?

[0060] If the CHK2 and CHK1 checksums are identical, the verification is successful. If the CHK2 and CHK1 checksums differ, the verification is unsuccessful. This can result in an error being raised and / or a predefined action being triggered.

[0061] The VerifyBuffer() function 403 may be implemented to return a value or flag that indicates at least the following: - the verification was not successful; - the verification was successful; - no verification.

[0062] For example, each of these options can be assigned a predefined return value. The last option, "no verification," indicates that the FDP was empty and therefore no verification was possible.

[0063] It is also possible that the VerifyBuffer() function 403 returns the error itself, independently or in addition to the return value. This is indicated, for example, by a dashed arrow 404.

[0064] Therefore, the VerifyBuffer() function 403 is called in step 407 (see arrow 406). After the VerifyBuffer() function 403 completes, it returns (arrow 405) to complete step 407.

[0065] Another possibility is to execute the VerifyBuffer() function 403 independently of the ISR. For example, the normal program can call the VerifyBuffer() function 403, which is indicated by an arrow 401, and the VerifyBuffer() function 403 returns (arrow 402) so that the normal program continues. In an exemplary embodiment, the VerifyBuffer() function 403 can return a value of "FF" if the verification was unsuccessful. The normal program could thus implement verification as if verifyBuffer() = FF: ERROR ()

[0066] Thus, error handling ERROR() is only started if the VerifyBuffer() function 403 returns the value FF.

[0067] Error handling may include at least one of several options, e.g., notifications, failure to continue the program, starting at least one dedicated error handler, reset, etc.

[0068] The normal program can call the VerifyBuffer() function 403 on certain events and / or based on a deterministic or non-deterministic algorithm.

[0069] The VerifyBuffer() function 403 refers to the previous interrupt. Each subsequent interrupt overwrites the FDP in step 408.

[0070] During interrupt execution, any manipulation of the registers that may occur during steps 409 and 410 can be detected (later) by the VerifyBuffer() function 403.

[0071] In one or more examples, the functions described herein may be implemented at least partially in hardware, such as specific hardware components or a processor. More generally, the methods may be implemented as hardware, processors, software, firmware, or any combination thereof. When implemented as software, the functions may be stored on or transmitted over a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to a tangible medium, such as data storage media or communications media, including any medium that facilitates transfer of a computer program from one location to another, e.g., according to a communications protocol.In this way, computer-readable media may generally correspond to (1) tangible computer-readable storage media that is non-transitory, or (2) a communications medium, such as a signal or carrier wave. Data storage media may be any available media accessible by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the methods described in this disclosure. A computer program product may include a computer-readable medium.

[0072] By way of example, but not as a limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Furthermore, any connection is properly referred to as a computer-readable medium, i.e., a computer-readable transmission medium.For example, if commands are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair cable, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to non-transitory, tangible storage media.As used herein, disk and disc include compact disc (CD), laserdisc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray Disc. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the aforementioned media should also be included within the scope of the definition of computer-readable media.

[0073] Instructions may be executed by one or more processors, such as one or more central processing units (CPUs), digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable (logic) gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor" as used herein may refer to any of the foregoing structures or any other structure suitable for implementing the methods described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding or integrated into a combined codec.Furthermore, the methods could be fully implemented in one or more circuits or logic elements.

[0074] The methods of this disclosure may be implemented in a wide variety of devices or apparatus, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to highlight functional aspects of devices configured to perform the disclosed methods, but do not necessarily require implementation by different hardware units. Rather, as previously described, various units may be combined into a single hardware unit or provided by a collection of interoperable hardware units, including one or more processors as previously described, in conjunction with suitable software and / or firmware.

[0075] Although various exemplary embodiments of the invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications may be made that achieve some of the advantages of the invention without departing from the spirit and scope of the invention. It will be apparent to those skilled in the art that other components performing the same functions may be suitably substituted. It should be noted that features explained with reference to a specific figure may be combined with features of other figures, even where this has not been explicitly mentioned.Furthermore, the methods of the invention can be performed either in pure software implementations using the appropriate processor instructions or in hybrid implementations using a combination of hardware logic and software logic to achieve the same results. Such modifications of the inventive concept are intended to be covered by the appended claims.

Claims

[1] A method for performing an interrupt, comprising the steps of: (a) a hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) a checksum is generated via the registers and the checksum is stored; (c) the interrupt service routine code is executed; (d) verifying the checksum using the stored checksum and the stored registers; (e) the hardware pops the registers from memory and restores the program counter. [2] The method of claim 1, wherein the memory is a stack. [3] The method of claim 2, wherein in step (b) the checksum is generated by the hardware, software and / or firmware and stored on the stack. [4] A method according to any one of the preceding claims, wherein in step (d) the hardware verifies the checksum. [5] Method according to one of the preceding claims, wherein - the checksum is generated using a one-way function, - the verification in step (d) includes: - Calculating a second checksum based on the stored registers using the one-way function; - Comparing the second checksum with the stored checksum; - Initiate error handling if the second checksum and the stored checksum differ. [6] A method according to any one of claims 1 or 2, wherein in step (b) the checksum is generated by software and the checksum is stored in a buffer. [7] Method according to claim 6, wherein - the checksum is generated using a one-way function, - the verification in step (d) includes: - Calculating a second checksum based on the stored registers from memory using the one-way function; - Comparing the second checksum with the stored checksum from the buffer; - Initiate error handling if the second checksum and the stored checksum from the buffer differ. [8] A method for performing an interrupt, comprising the steps of: (a) a hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) conducting verification; (c) generating a checksum over the registers and storing the checksum and the registers in a buffer; (d) executing the interrupt service routine code; (e) the hardware pops the registers from the buffer and restores the program counter. [9] The method of claim 8, wherein the checksum is generated using a one-way function, [10] A method according to any one of claims 8 or 9, wherein the verification in step (b) comprises: - Calculating a second checksum based on the stored registers from the buffer using the one-way function; - Comparing the second checksum with the stored checksum from the buffer; - Initiate error handling if the second checksum and the stored checksum from the buffer differ. [11] A method according to any one of claims 8 to 10, wherein the verification in step (b) is performed if an interrupt has previously occurred. [12] A method according to any one of claims 8 to 11, wherein between steps (c) and (d) a pointer is redirected from the memory to the buffer. [13] A method according to any one of claims 8 to 12, wherein the verification in step (b) is performed when no interrupt is being processed. [14] An apparatus for performing an interrupt, the apparatus comprising hardware, software and a memory, and the apparatus is configured to perform the steps of: (a) the hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) generating a checksum over the registers and storing the checksum; (c) executing the interrupt service routine code; (d) verifying the checksum using the stored checksum and the stored registers; (e) the hardware pops the registers from memory and restores the program counter. [15] The apparatus of claim 14, wherein in step (b) the checksum is generated by the software, hardware and / or firmware and the checksum is stored in a buffer. [16] Apparatus for performing an interrupt, the apparatus comprising hardware, software and a memory, and the apparatus is arranged to perform the steps: (a) the hardware pushes registers to a memory and sets a program counter to an interrupt service routine; (b) conducting verification; (c) generating a checksum over the registers and storing the checksum and the registers in a buffer; (d) executing the interrupt service routine code; (e) the hardware pops the registers from the buffer and restores the program counter. [17] Apparatus according to claim 16, wherein the verification is performed in software. [18] Apparatus according to any one of claims 16 or 17, wherein the verification step (b) comprises: - Calculating a second checksum based on the stored registers from the buffer using the one-way function; - Comparing the second checksum with the stored checksum from the buffer; - Initiate error handling if the second checksum and the stored checksum from the buffer differ. [19] Apparatus according to any one of claims 14 to 18, wherein the apparatus comprises a processor or an arithmetic logic unit, ALU.

Images