WO2022093186A1 - Exécution de code à l'aide d'un enregistrement de code de confiance - Google Patents

Exécution de code à l'aide d'un enregistrement de code de confiance Download PDF

Info

Publication number
WO2022093186A1
WO2022093186A1 PCT/US2020/057505 US2020057505W WO2022093186A1 WO 2022093186 A1 WO2022093186 A1 WO 2022093186A1 US 2020057505 W US2020057505 W US 2020057505W WO 2022093186 A1 WO2022093186 A1 WO 2022093186A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
trusted
computing device
run
item
Prior art date
Application number
PCT/US2020/057505
Other languages
English (en)
Inventor
Christopher Howard STEWART
Richard Alden BRAMLEY, Jr.
Christopher Ian DALTON
James Misra MCKENZIE
Krzysztof Todeusz UCHRONSKI
Gianluca Guida
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2020/057505 priority Critical patent/WO2022093186A1/fr
Publication of WO2022093186A1 publication Critical patent/WO2022093186A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping

Definitions

  • Computer code e.g. software, firmware, and drivers
  • Some untrusted code may not be trusted to run safely, as it may cause or allow unwanted changes to take place to the trusted code (e.g. In the Basic InpuVOutput System (BIOS)).
  • BIOS Basic InpuVOutput System
  • Figure 1 shows a schematic representation of a computing device to verify that firmware is trusted before executing it, according to an example of the disclosure
  • Figure 2 illustrates a schematic representation of operation of a computing device to verify code as being trusted or untrusted and handling the code accordingly, according to an example of the disclosure
  • Figure 3 shows a schematic representation of a computing device to compare a software program attempting to run with a stored record of trusted software, and execute the code if determined to be trusted, according to an example of the disclosure:
  • Figure 4 shows a schematic representation of a computer program which illustrates how a trusted code record may be obtained and stored, according to an example of the disclosure
  • Figure 5 shows a schemati c representation of a computing device operating a hypervisor in communication with a plurality of virtual machines, according to an example of the disclosure
  • Figure 6 shows an exemplary logical workflow in a computing device to assign different privileges to code dependent on whether the code is trusted or entrusted, according to examples of the disclosure
  • Figure 7 shows an exemplary logical workflow in a computing device to determine if code to be executed is trusted dependent on an address of the code matching that of trusted code in a stored record, according to examples of the disclosure; and [0010]
  • Figure 8 illustrates an example logical workflow which handles code to be run in a plurality of subsets dependent on when the code attempts to run, according to examples of the disclosure.
  • Examples disclosed herein relate to handling trusted and entrusted software.
  • Trusted software may be taken to be code or processor executable instructions which originates from the host computing device, for example, the Basic Input/Output System (BIOS), and/or firmware.
  • Untrusted software may be taken to be code which originates from outside the host computing device, such as software provided by a third party (the term “host computing device” in this sense excludes removal options such as Peripheral Component Interconnect (PCI) cards and Thunderbolt computing devices, since in this disclosure, code loaded from a Peripheral Component Interconnect (PCI) card or Thunderbolt computing device is third party code and therefore entrusted).
  • PCI Peripheral Component Interconnect
  • Thunderbolt computing device is third party code and therefore entrusted.
  • a third party driver which acts to facilitate communication between the Operating System (OS) of the computing device and a third party computing device, is an example of untrusted software.
  • Third party boot loaders and third party applications are also examples of untrusted software.
  • Some third party software may be validated as “secure”, for example, through a signature verifying that the third party software is not malicious. However, such software may still be considered to be untrusted In the sense that it may contain a vulnerability which may allow a malicious attacker to access the trusted software of the computing device via the vulnerability in the third party software.
  • Non-trusted software may be unsafe to run on a computing device in case it allows for unwanted changes to be made, for example to trusted code such as the computing device BIOS.
  • a personal computer may contain a variety of hardware computing devices (e.g., a video controller, fingerprint reader, and/or network controller) from different suppliers. Often, both at an operating computing device level as well as at a firmware level, many of these types of computing devices use a driver from the supplier In order to function. This driver may be considered to be third party software.
  • Such drivers may be built info the firmware itself, or may reside on the card in a way that is discoverable with industry standard mechanisms. Such drivers may be executed in the same address space and with the same privileges as the firmware built into the computing device.
  • Examples disclosed herein apply to a computing device in which both trusted and un be run.
  • a boot phase i e. start-up
  • trusted host software such as Unified Extensible Firmware Interface (UEFI) applications and drivers that are incorporated into the BIOS image
  • untrusted third party software e.g. UEFI applications and drivers that might be loaded during Power-On SelfTest (POST) from other computing devices
  • trusted code is not loaded during start-up of the computing device, it may be wrongly assumed, when an attempt is made to load it, that it is untrusted software and it may be handled as untrusted unnecessarily, thereby producing a processing burden for handling It as untrusted code when it should be trusted and therefore safe to run.
  • BIOS Basic Input/Output System
  • OS Operating System
  • Instructions within a BIOS may be software, firmware, microcode, or other programming that defines or controls functionality or operation of a BIOS.
  • a BIOS may be implemented using instructions, such as platform firmware of a computing device, executable by a processor.
  • a BIOS may operate or execute prior to the execution of the OS of a computing device.
  • a BIOS may initialize, control, or operate components such as hardware components of a computing device and may load or boot the OS of computing device,
  • a BIOS may provide or establish an interface between hardware computing devices or platform firmware of the computing device and an OS of the computing device, via which the OS of the computing device may control or operate hardware computing devices or platform firmware of the computing device.
  • a BIOS may implement the UEFI specification or another specification or standard for initializing, confroiling, or operating a computing device.
  • Exampies disclosed herein provide a computing device, comprising: a memory storing software; and a processor; to: on start-up of the computing device and before nontrusted firmware is run, obtain and store a secure record of trusted firmware to be run on the computing device; and in response to a signal to run a firmware code item, verify the firmware code item is trusted firmware corresponding to the secure record.
  • Examples disclosed herein provide a computing device, comprising: a memory storing software; and a processor; to: receive a signa! to execute a software program on the processor; compare the software program with a stored record of trusted software trusted to run in the memory; and execute the software program in response to the software program corresponding to the stored record.
  • Exampies disclosed herein provide a non-transitory computer-readable medium comprising instructions that, when executed, cause a processor of a computing device to: receive a signal to run an item of software in a memory; compare the item of software with a stored record of trusted software trusted to run in the memory; and run the item of software as trusted software in response to the item of software meeting a matching criterion with an item of trusted software stored in the stored record.
  • Examples discussed herein in terms of a computing device to behave in a described way also encompass a non-transitory computer-readable medium comprising instructions that, when executed, cause a processor of a computing device to behave in the way described. Examples discussed herein in terms of a non-transitory computer- readable medium comprising instructions that, when executed, cause a processor of a computing device to behave in a described way may also be taken to encompass a computing device to behave in the described way. Such instructions may also be considered to encompass computer implemented methods to perform the described features.
  • FIG. 1 shows a schematic representation of a computing device 100 which is to verify that firmware is trusted before executing it.
  • the computing device 100 comprises a memory 104 storing software and a processor 102.
  • the computing device On start-up of the computing device 100 and before non-trusted firmware is run, the computing device is to be run on the computing device 100.
  • a set of instructions controlling the computing device may be comprised in the computing device BIOS and may obtain and store a secure record of trusted firmware at 106.
  • the phase of com puting device operation from start-up of the computing device 100 and before non-trusted firmware is run may be, for example, a Dispatch phase of start-up operation of the computing device 100.
  • the BIOS may hash drivers and applications (as a way of obtaining a secure record) that will not be loaded into memory for the duration of POST before any third-party code can ioad (i.e. during Dispatch in this example).
  • This hash as an example of a secure record of trusted code/firmware, may be sent for safekeeping e.g. to a hypervisor, for use later in POST, should any of these hashed drivers load later in POST.
  • the memory 104 may, for example, comprise firmware (e.g.
  • BIOS Basic Extensible Firmware Interface
  • UEFI Unified Extensible Firmware Interface
  • the memory 104 may comprise data, programs., software, or code, and a set of instructions / software to cause the computing device to operate may be stored in the data, programs, software, or code, not limited to firmware.
  • the “Dispatch" process of the above example may be considered to relate to an UEFI environment.
  • BIOS typically contains code that is loaded into memory and executed before third-party drivers/applications load, and code known to be part of the BIOS (because, for example, it is part of the same collection of firmware executable images that is signed at build time and verified at boot time) that only loads and executes after third party drivers/applications load and execute.
  • the code known to be part of the BIOS may be securely stored as the secure record, for example.
  • the computing device In response to receiving a signal to run a firmware code item at 108, the computing device Is then to verify that the firmware code item is trusted firmware corresponding to the secure record at 110.
  • the firmware code item may be a host computing device driver, or application, which is loaded later in the POST phase. Such applications or drivers, which ought to be trusted, may otherwise be treated as untrusted third-party applications or drivers, because they did not load during Dispatch (I.e. before any third party code was loaded).
  • firmware code item By comparing, for example, a hash of the firmware code item attempting to run, with a hash stored as the secure record, and identifying a match, then it can be determined that the firmware code item is trusted code which did not run during Dispatch but which shouid be allowed to run safety as trusted code.
  • the firmware foilowing verification may then run at step 112 on the processor 102.
  • This example is of firmware atempting to run iater in the POST phase which may be considered to be during start-up of the computing device 100.
  • the signal to run a firmware code item at 108 may be received during a callback procedure after start-up of the computing device. Still in this case, the firmware code item may be compared with the secure record to determine whether or not it shouid be bandied as trusted code (and allowed to run).
  • firmware i.e. BIOS
  • BIOS firmware
  • the processor reads the firmware instructions from its storage iocation, which may be a hardware computing device on the motherboard (e.g. flash memory).
  • the code stored in the flash may have been cryptographically validated as trusted code (e.g. code provided by the host computing device).
  • trusted code e.g. code provided by the host computing device.
  • the firmware code may be broken up into several chunks based on the attributes needed by its usage. For example, there may be early code which is executed directly from the hardware, because the computing device memory has not yet been configured; and there may be other code that is copied into the memory and accessed from there, for example to improve operating speed.
  • EndOfDXE Signal the End Of Driver execution Environment
  • This may be locking system resources such as SIMRAM so that third party code may not be able to access these resources, in an UEFI environment, this EndOfDXE process may occur immediately prior to a ReadyToLock process (locking resources may occur immediateiy after ReadyToLock),
  • One approach to mitigating against untrusted code interfering with trusted code is to take an isolation approach, for example by isolating all security sensitive logic / code in SMRAM so that it is protected from untrusted code tampering with it.
  • this logic / code which is securely stored Is likely to use untrusted code outside of SMRAM to do something to trigger the security sensitive code to execute (e.g., a software SMI).
  • preventing unauthorized triggering of this code may typically involve the following scenarios, for exampie: (a) the code can only be called once; (b) the code can only be called before some event is signalled (e.g., ExitBootServices); or (c) another restrictive measure Is taken to protect the code. These measures may reduce the risk of unwanted tampering from untrusted code, but may be ineffective in some cases. Examples disclosed herein take an approach different to a full isolation approach which may consider whether code is trusted or not, and handle the code accordingly.
  • a hash of all the trusted drivers and apps being stored in memory from the flash may be computed, and this may be stored as an image somewhere safe from tampering (e.g. in SMRAM).
  • This is an example of obtaining and storing a secure record of the firmware, at 106.
  • there may be metadata which describes the layout of the image. Later when the driver is loaded to be executed, at 108 (processes (6) and (8) above) the hash may be verified, at 110, and the metadata may be updated and stored in SMRAM with the hash to contain the address where the driver has been loaded.
  • SMM System Management Mode
  • the address where the call was made may be identified (i.e., the current RIP value is available to SMRAM based code), the hash that has an address range containing the RIP may be identified, the hash for the driver containing that call may be recomputed, and the recomputed hash may be compared to the hash computed and stored prior to EndofDXE. This may be considered to be an example of verifying the firmware code corresponds to the secure record at 110. If the hashes match, SMM can be assured that trusted code is making the call.
  • SMM System Management Mode
  • the hash may be computed over the static portions of the driver in some examples so that runtime changes to its data area do not impact the hash.
  • a similar approach may be applied in other different environments; for example, system calls (e.g, int 0x80) into a kernel, or hypercalls (e.g, Central Processing Unit IDentification (CPUID)) into a hypervisor.
  • system calls e.g, int 0x80
  • hypercalls e.g, Central Processing Unit IDentification (CPUID) into a hypervisor.
  • CPUID Central Processing Unit IDentification
  • UEFI Unified Extensible Firmware Interface
  • DXE Driver execution Environment
  • CPUID calls may be involved, and the hypervisor may determine whether it can trust the RIP of the CPUID invoker. It may be useful to be able to distinguish between, for example, a set of UEFI applications and drivers that are incorporated into the BIOS image, on the one hand (i.e. trusted firmware), and any UEFI applications and drivers that might be loaded during POST from other computing devices, on the other (i.e. untrusted software).
  • UEFI Unified Extensible Firmware Interface
  • DXE Driver execution Environment
  • Trusted drivers may be loaded during a DXE boot phase known as Dispatch (i.e. a start-up process of the computing device).
  • Dispatch i.e. a start-up process of the computing device.
  • the hypervisor receives a CPUID message or traps a fault from an instruction contained within one of these dispatched, trusted drivers, the hypervisor knows that the driver is trusted based on the instruction pointer (RIP) being contained within the memory of the dispatched driver.
  • the hypervisor is able to modify memory pages so that DXE Boot Services drivers, applications, and data can be protected from malicious attacks that might be launched when third party option ROMs are loaded into DXE Boot Services memory from non-BIOS computing devices, such as option cards.
  • Such a hypervisor may operate in the traditional L0 hypervisor context, and a BIOS which operates as a guest in the traditional L1 hypervisor context.
  • the 10 context is where the hypervisor itself executes.
  • the L0 context may set page attributes on memory pages in such a way that the L1 guest may not be able to modify those attributes.
  • the 1.0 context may also trap and handle faults and exceptions that may occur in the L1 guest context.
  • 11 may also frequently communicate with L0, for example through direct communication (e.g.
  • indirect communication may occur if a fault, such as a page fault, occurs when attempting to write to a specific memory location .
  • a fault such as a page fault
  • Part of the fault context may indicate the stack pointer (RSP) and/or instruction pointer (RSP) of the fault.
  • RSP and RIP may contain data that can be tied back to a specific driver or application residing in memory.
  • Examples disclosed herein may provide a way to overcome the issue of being unable to compare the value of RIP to a driver’s known memory location due to the driver/application In the signed BIOS image not being loaded during Dispatch (and therefore, the issue of not being able to verify that the drivers or applications are trusted).
  • examples described herein may cause the BIOS to hash drivers and applications that will not be loaded into memory for the duration of POST before any third-party code can load (e.g. during Dispatch). This hash, as an example of a secure record of trusted code, may be sent for safekeeping e.g.
  • all third-party driver descriptive data may be sent to the hypervisor (i.e. a secure processing environment) when the driver/application loads but before the driver/application begins executing.
  • This descriptive data may comprise, for example, the driver/application contents, its location in memory, and/or its size footprint in memory.
  • the hypervisor may hash the driver/application contents. Then this calculated hash is compared with the hash of trusted software stored at the hypervisor. If this hash matches one of the trusted hashes sent to be stored in storage prior to third-party code executing, then the driver/application is known to be one of those drivers or applications that was contained in the signed BIOS image but not launched during Dispatch. Hence, such a driver/application can be trusted by the hypervisor.
  • This trust impacts the handling of CPUID messages and faults that occur within the context of the trusted driver or application.
  • examples disclosed herein may provide an establishment of trust for drivers/applications that are part of the signed image but not launched during Dispatch.
  • the hashing mechanism as an example of obtaining a secure record of trusted code to be stored in storage and for use in later comparison with code to be executed, allows for trusted code to be verified as such in a secure way, and thus being trusted to run,
  • BIOS guest and firmware hypervisor there are other examples which fall within this disclosure and which involve the issue of needing to establish trust between a high-trust system (like a hypervisor) and a low-trust system (like UEFI DXE Boot Services).
  • a high-trust system is a BIOS SMRAM receiving System Management Interrupt (SMI) calls from a low-trust BIOS DXE Boot Services system.
  • SMI System Management Interrupt
  • Another example is of a high-trust system being an operating system kernel receiving system: call invocations from operating system user-space code.
  • Other similar situations apply, where there is a clear demarcation between levels of trust in two systems that operate simultaneously on a computing device,
  • a driver When a driver is launched during Dispatch, establishing trust Is straightforward, since Dispatch occurs before any third-party code executes. A driver that is loaded into memory and begins execution during Dispatch can always be trusted. However, not all drivers/applications that are part of the secure (e.g. cryptographically signed) BIOS image are launched during Dispatch. Hence, a secure record, such as a hash, of those drivers may be generated and securely stored (e.g. by the hypervisor) during Dispatch, so that should any of these drivers/applications load into memory after Dispatch, the hash may be re-generated (e.g.
  • the hypervisor compared to the protected hashes stored in the secure storage (e.g, the hypervisor), if the comparison succeeds, the driver/application is known to have been part of the signed BIOS Image, Hence, that driver/application Is trusted. If the comparison fails, then the driver/application is known to be third-party code. Hence., it is not trusted by the hypervisor. This enables trust to be established between 11 guest BIOS code and the L0 hypervisor in a secure manner.
  • Figure 2 illustrates a schematic representation of a method of operation 200 of a computing device, such as the computing device of Figure 1 , to verify code as being trusted or untrusted and handling the code accordingly.
  • a secure record of trusted firmware to be run on the computing device is obtained and stored in step 202.
  • the method in this example is then to receive a signal to run trusted code 204, and run the trusted code.
  • the method in this example is also to receive a signal to run untrusted code 208 on the computing device in step 210, In this example, the untrusted code 208 is verified (i.e. determined to be safe) through an additional verification mechanism in step 212 and may be permitted to run as verified untrusted code in step 210.
  • a signal is received to run some further code 214.
  • the secure record obtained on start-up is now used to determine if this further code 214 is to be trusted or not.
  • the code 214 is compared with the secure record of trusted code in step 216. if the firmware code item 214 is verified to correspond to the secure record (e.g. a match is determined between a unique identifying feature of the code 214 attempting to run and the stored record), the method is to run the verified trusted firmware in step 220 as trusted code. However, if the firmware code item 214 is not verified to correspond to the secure record, the method is to generate an error signal in step 218 indicating nonverification of the firmware code item (e.g.
  • trusted code 204 Before any non-trusted code 208 is run, a signal is received to run trusted code 204 and the trusted code can run in step 206.
  • trusted code may be, for example, an early part of the POST phase firmware during computing device startup.
  • the secure record of trusted firmware to be run on the computing device is obtained and stored in step 202 prior to any code running on the computing device, whether the code is trusted code 204 or untrusted code 208.
  • a first portion of trusted firmware code may be run on the computing device in step 206 (before non-trusted firmware is run in step 210) and before the secure record of trusted firmware is obtained in step 202. It may be that this first portion of the trusted firmware code may run before any untrusted firmware code can possibly run. As such, this portion of trusted firmware code may be excluded from the secure record because it runs before any other code runs, so there is no risk that untrusted code may have had access to the memory beforehand.
  • a second portion of the trusted firmware, which has not yet run, may be obtained and stored as the secure record of trusted firmware in step 202 to be run on the computing device after the first portion of trusted firmware has run.
  • Figure 3 shows a schematic representation of a computing device 100 which is to compare a software program attempting to run with a stored record of trusted software, and execute the software program If it is determined to be trusted.
  • the software program may be firmware, a driver, and/or an application in some examples.
  • the computing device 100 comprises a memory 104 storing software and a processor 102.
  • the computing device 100 is to receive a signal to execute a software program on the processor in step 120.
  • the software program to be run is compared with a stored record 404 of trusted software in step 122 which is trusted to run in the memory 104.
  • the software program is executed in response to the software program corresponding to the stored record in step 124.
  • the stored record 404 of trusted software which is trusted to run in the memory 104, may be stored securely, for example, at a hypervisor 504 (as Illustrated in Figure 5).
  • the computing device may then, at step 122, compare, at the hypervisor 504, the software program with the stored record at the hypervisor 504, and execute the software program in the memory In response to the software program corresponding to the stored record in step 124.
  • the computing device may generate an error signal in step 126 in response (and may cause that error signal to be output, for example as a visual Indicator on a display device of the computing device 100).
  • FIG 4 shows a schematic representation of a computer program 400 which illustrates how trusted code 402 may be processed to obtain a secure record 404 for later comparison with code attempting to run.
  • the secure record 404 of trusted software 402 is obtained and stored.
  • the secure record 404 may be obtained by calculating a hash of the trusted software and storing the hash in step 408.
  • The, the secure record 404 may be obtained by securely applying a signature to the trusted software and storing the signed trusted software in step 406.
  • the secure record 404 may be obtained by evaluating the trusted software to ensure it is trusted software in step 410, and storing a copy of the evaluated trusted software.
  • the secure record may be stored at a secure location, for exampie, at a hypervisor 504 as illustrated in Figure 5.
  • Hashing in step 408 or general evaluation in step 410 may be performed before any potentially untrusted code is executed on the computing device, to ensure that untrusted code is not able to interfere with the hashing or general evaluation process.
  • Signature verification in step 406 may be performed whether or not there is untrusted code already executing.
  • FIG. 5 shows a schematic representation of a computing device 502 operating a hypervisor 504 in communication with a plurality of virtual machines 506a-c.
  • a hypervisor 504 which may also be called a Virtual Machine Monitor or VMM, may be implemented as software that can create and run Virtual Machines (VMs) 506a-c.
  • a hypervisor 504 may allow a computing device502 to support multiple guest VMs 506a-c by virtually sharing its resources, such as memory and processors).
  • Hypervisors 504 may support the creation and management of VMs 506a-c by abstracting a computing device’s 502 software from its hardware. Hypervisors 504 may provide virtualisation by translating requests between the physical and virtual resources. Hypervisors 504 may be embedded into a computing device’s 502 firmware at the same level as the motherboard BIOS and may enable the operating system on a computing device 502 to access and use virtualization software.
  • Figure 6 shows an exemplary logical workflow 600 in a computing device to assign different privileges to software code dependent on whether the software code is trusted or entrusted.
  • Figure 7 shows an exemplary logical workflow 700 in a computing device to determine if software code to be executed is trusted dependent on an address of the software code matching that of trusted code in a stored record.
  • Such workflows 600, 700 may be implemented as computer program code, for example stored as instructions (e.g, firmware) on a non-transitory computer-readable medium. When executed, the instructions cause a processor of a computing device to perform one or more functions as discussed herein.
  • Figure 6 illustrates that a signal is received indicating that an item of software 602 (e.g. firmware, driver, or application) is attempting to run in a memory computing device.
  • the instructions receive the signal that software is attempting to run, and compare the software in step 604 with a stored record of trusted software 610 trusted to run in the memory.
  • the instructions may then run the item of software in step 606 as trusted software in response to the item of software meeting a matching criterion with an item of trusted software stored in the stored record 610.
  • the instructions may treat the item of software as entrusted software, for example by allowing it to run with restricted activity in step 608 compared to trusted software. Restricted activity may be, for example, allowing read access but denying write access of the entrusted software to the memory.
  • the software 602 attempting to run may be run as trusted software in a low security computing environment in step 606 in response to the item of software meeting the matching criterion; and run In a high security computing environment in step 608 in response to identifying that the item of software does not meet the matching criterion.
  • the low security computing environment has, for example, greater privileges (e.g.
  • a fault is generated and enforced to prevent the item of software from having write access to the memory (in examples where the item of software does meet the matching criterion, the fault may still be generated but then overridden as the software is determined to be trusted).
  • a hypervisor (as illustrated in Figure 5) may be used to manage the handling of untrusted code.
  • a signal to run the item of software 602 is received.
  • the item of software may then be compared with the stored record of trusted software 610 stored at the hypervisor. The comparison may take place at the hypervisor, for example to isolate the code, which is not yet verified to be trusted, from the computing device processor and memory.
  • the item of software may be run in step 606. Since the software is determined to be trusted, it may run on the computing device processor and memory. In some examples it may still run in the hypervisor.
  • the hypervisor may receive write faults for write requests to the system Input/Output Memory Management Unit (lOMMU). If the hypervisor determines that the lOMMU write should be allowed, the hypervisor may perform the write itself, If the hypervisor determines that the write should not be allowed, then the fault is enforced. In some examples, this approach may be generalized to the handling of more than lOMMU write faults, and in some examples may be applied to all faults.
  • lOMMU system Input/Output Memory Management Unit
  • An example way in which the software may be compared to the stored record to determine if that software is trusted or untrusted is to consider the memory address of the software attempting to run.
  • the memory address may act as a unique identifier in this respect, which is linked to the software and, if found to match the memory address of the software in the stored record, indicates that the software atempting to run is trusted software represented in the stored record.
  • An example of using the address is shown in Figure 7. That is, an address of the item of software is identified in step 704 based on the received signal indicating that an item of software 702 is attempting to run. A corresponding address may be identified in step 706 of an item of trusted software stored in the stored record 710.
  • the code is determined to be trusted and safe to execute. If the code is untrusted, it will not have a corresponding address stored in the stored record of trusted code, and so no match would be identified and the code would not be allowed to execute in the computing device memory.
  • the addresses may be stored in metadata associated with the stored record.
  • the metadata in some examples may be updated in response to the comparison of an address of code attempting to run with code stored in the stored record, to store the address of the item of code atempting to run. In this way a log may be maintained of attempts of software to run and their addresses. That way. if in the first instance of a particular item of software atempting run, a particular set of privileges and/or restrictions is assigned to that software, that same set of privileges and/or restrictions may be implemented if the same item of software attempts to run later (e.g. during a callback procedure), as identified through the address of the software being logged in the metadata.
  • FIG. 8 illustrates an example logical workflow 800 of handling code to be run in a plurality of subsets dependent on when the code atempts to run.
  • a first subset of trusted software to be run before non- trusted software is run is identified in step 804 from a set of trusted software.
  • a second subset of trusted software to be run after non-trusted software is run is also identified in step 806 from a set of trusted software.
  • the second subset of trusted software is securely stored in step 808, thereby creating a secure record of trusted software.
  • the first subset of trusted code identified in step 804 may be considered to be safe since no untrusted code has executed which may have tampered with it.
  • This first set of trusted code identified in step 804 need not be part of the stored record of trusted code, since it need not be verified against a secure record - it is known to be trusted and known not to have been tampered with. After any untrusted code has attempted to run (or has run), any subsequent trusted code needs to be verified against the secure stared record to ensure it is trusted and has not been tampered with.
  • This second subset of code identified in step 806 is therefore stored in the stored record in step 808 as a comparison ready for later verification of trusted code attempting to run,
  • Exampies disclosed herein may enable control of a secure computing environment, such as a hypervisor, regarding whether or not it knows to trust an item of code attempting to run or not, for example, the RIP source of a CPUID hypercall or the RIP source of a write fault.
  • Examples provide the ability to know definitively that certain code (e.g. as identified by its RIP address) can be trusted even when the code does not launch during Dispatch.
  • UEFI applications like a trusted BIOS update UEFI application
  • the establishment of trust is the way to distinguish one from the other, even in the otherwise ambiguous context of a trusted host computing device application that is part of the signed BIOS image but does not launch until after other third-party code launches.
  • a computing device comprising: a memory storing software; and a processor to: on start-up of the computing device and before non-trusted firmware is run, obtain and store a secure record of trusted firmware to be run on the computing device; and in response to a signal to run a firmware code item, verify the firmware code item is trusted firmware corresponding to the secure record
  • a computing device comprising: a memory storing software; and a processor to: receive a signai to execute a software program on the processor; compare the software program with a stored record of trusted software trusted to run in the memory : and execute the software program in response to the software program corresponding to the stored record
  • a non-transitory computer-readable medium comprising instructions that, when executed, cause a processor of a computing device to: receive a signal to run an item of software in a memory; compare the item of software with a stored record of trusted software trusted to run in the memory; and run the item of software as trusted software in response to the item of software meeting a matching criterion with an item of trusted software stored in the stored record,

Abstract

Un dispositif informatique donné à titre d'exemple comprend un logiciel de stockage de mémoire et un processeur pour, lors du démarrage du dispositif informatique et avant que le micrologiciel non sécurisé ne soit exécuté, obtenir et stocker un enregistrement sécurisé du micrologiciel de confiance devant être exécuté sur le dispositif informatique, en réponse à un signal pour exécuter un élément de code de micrologiciel, l'ensemble d'instructions doit vérifier que l'élément de code de micrologiciel est un micrologiciel de confiance correspondant à l'enregistrement sécurisé.
PCT/US2020/057505 2020-10-27 2020-10-27 Exécution de code à l'aide d'un enregistrement de code de confiance WO2022093186A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2020/057505 WO2022093186A1 (fr) 2020-10-27 2020-10-27 Exécution de code à l'aide d'un enregistrement de code de confiance

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/057505 WO2022093186A1 (fr) 2020-10-27 2020-10-27 Exécution de code à l'aide d'un enregistrement de code de confiance

Publications (1)

Publication Number Publication Date
WO2022093186A1 true WO2022093186A1 (fr) 2022-05-05

Family

ID=81383128

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/057505 WO2022093186A1 (fr) 2020-10-27 2020-10-27 Exécution de code à l'aide d'un enregistrement de code de confiance

Country Status (1)

Country Link
WO (1) WO2022093186A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220414212A1 (en) * 2021-06-28 2022-12-29 R3 Ltd. Counteracting fraudulent clock readings and side-channel attacks

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090204964A1 (en) * 2007-10-12 2009-08-13 Foley Peter F Distributed trusted virtualization platform
US20130185787A1 (en) * 2008-05-08 2013-07-18 Google Inc. Safely Executing an Untrusted Native Code Module on a Computing Device
US20140258700A1 (en) * 2013-03-11 2014-09-11 Microsoft Corporation Dynamically loaded measured environment for secure code launch

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090204964A1 (en) * 2007-10-12 2009-08-13 Foley Peter F Distributed trusted virtualization platform
US20130185787A1 (en) * 2008-05-08 2013-07-18 Google Inc. Safely Executing an Untrusted Native Code Module on a Computing Device
EP2963560A1 (fr) * 2008-05-08 2016-01-06 Google Inc. Procédé d'exécution en toute sécurité d'un module de code natif non approuvé sur un dispositif informatique
US20140258700A1 (en) * 2013-03-11 2014-09-11 Microsoft Corporation Dynamically loaded measured environment for secure code launch

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220414212A1 (en) * 2021-06-28 2022-12-29 R3 Ltd. Counteracting fraudulent clock readings and side-channel attacks
US11645385B2 (en) * 2021-06-28 2023-05-09 R3 Ltd. Counteracting fraudulent clock readings and side-channel attacks

Similar Documents

Publication Publication Date Title
US8839455B1 (en) Security domain in virtual environment
US9202046B2 (en) Systems and methods for executing arbitrary applications in secure environments
US9852295B2 (en) Computer security systems and methods using asynchronous introspection exceptions
US10379888B2 (en) Adaptive integrity verification of software and authorization of memory access
JP6142027B2 (ja) ハイパーバイザ環境においてカーネルルートキットに対する保護を実行するシステムおよび方法
US10284591B2 (en) Detecting and preventing execution of software exploits
EP3761208B1 (fr) Procédé et système d'exploitation basé sur une zone de confiance
US20210124824A1 (en) Securing secret data embedded in code against compromised interrupt and exception handlers
CN107690645B (zh) 使用解释器虚拟机的行为恶意软件检测
KR101946982B1 (ko) 가상 머신에서 멀웨어 탐지를 위한 프로세스 평가
JP5055380B2 (ja) 保護エージェント及び特権モード
US8650578B1 (en) System and method for intercepting process creation events
US9372699B2 (en) System and method for processing requests to alter system security databases and firmware stores in a unified extensible firmware interface-compliant computing device
KR102189296B1 (ko) 가상 머신 보안 어플리케이션을 위한 이벤트 필터링
US20090328195A1 (en) Authentication and Access Protection of Computer Boot Modules in Run-Time Environments
US7921461B1 (en) System and method for rootkit detection and cure
US11500787B2 (en) Enforcing code integrity using a trusted computing base
EP3440586B1 (fr) Procédé de protection d'écriture du boot code si l'integrite de sequence boot échoue
WO2022093186A1 (fr) Exécution de code à l'aide d'un enregistrement de code de confiance
Suzaki et al. Kernel memory protection by an insertable hypervisor which has VM introspection and stealth breakpoints
WO2022093184A1 (fr) Gestion de logiciel non sécurisé
CN116684161A (zh) 程序运行方法、装置、电子设备及存储介质
CN115982699A (zh) 基于安全内存的恶意攻击防御方法、装置、设备及介质
CN114556341A (zh) 完整性监视器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20960107

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20960107

Country of ref document: EP

Kind code of ref document: A1