VEHICLE COMPUTER SYSTEM AND PROCEDURES

Abstract

A system can comprise data processing hardware and storage hardware that communicates with the data processing hardware. Instructions can be stored in the storage hardware which, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include requesting a hardware security module (HSM) via a host module's boot manager to verify the host module's application software and, through the verified application software, configuring a memory protection unit (MPU) to "Do Not Execute" and / or "Do Not Write" for at least one area of ​​the host module's memory. The operations further include executing the application software with the HSM enabled.

Description

INTRODUCTION

[0001] The information contained in this section is intended to provide a general context for the disclosure. Work by the presently named inventors, to the extent described in this section, as well as aspects of the description that may not otherwise be prior art at the time of filing, are not expressly or impliedly admitted as prior art to the present disclosure.

[0002] The present disclosure generally relates to a vehicle computer system and method for preventing software tampering during runtime.

[0003] Secure boot is a security control commonly used for embedded devices. Secure boot is configured to ensure that only authentic software is executed by the embedded device. The authenticity of the software is typically verified at each boot through secure boot. However, the software can be silently modified during a software runtime if the software is only authenticated at boot time. For example, the device is typically configured to shut down automatically, so if the previously authenticated software is modified, the device may not shut down to perform a reset and prevent potential malware execution. SUMMARY

[0004] In some aspects, a computer-implemented method, when executed by computing hardware, causes the computing hardware to perform operations including receiving code from flash memory at a hardware security module (HSM), verifying an authenticity of the code via the HSM, and initiating a host module in response to the verified code, the host module comprising a boot manager, a bootloader, and application software. The operations also include receiving a programming session request to the boot manager to execute the bootloader and configuring a memory protection unit (MPU) via the bootloader to set at least a portion of a memory of the host module to "do not write" and / or "do not execute."The programming session is executed to modify the host module's memory and update the host module's application software using the verified bootloader, and a microcontroller containing the HSM and the host module is reset to execute the updated host module's application software.

[0005] In some examples, initiating the host module may include determining, via the boot manager, which of the bootloader and application software should be executed, and verifying the bootloader with the HSM may include allowing modification of the host module's memory except in a bootloader location and preventing modification of the host module's memory prior to executing the programming session request. Optionally, configuring the MPU may include setting a stack area and a data area of ​​the host module's memory to "do not execute" via the MPU and setting a hold area of ​​the host module's memory to "do not write" and "do not execute" via the MPU.

[0006] The microcontroller can be reset by completing the programming session and starting the application software.

[0007] In some implementations, executing the programming session request may include disabling a protection function of the HSM, where the protection function may be configured to protect the memory of the host module, and executing updates to a code area of ​​the memory. The hold area of ​​the memory may be set such that a first hold area is set to "do not write" and "do not execute" and a second hold area is set to "do not write" and "do not execute." The first hold area may be defined between the stack area and the data area, and the second hold area may be defined between the data area and the code area. In some cases, executing the programming session may include triggering a reset in one of the first or second hold areas in response to a data write overflow.Optionally, the bootloader can be verified by the HSM by obtaining a position and length of the bootloader from the boot manager and generating a key for the bootloader.

[0008] In other aspects, a system may include computing hardware and storage hardware in communication with the computing hardware. Instructions may be stored in the memory hardware that, when executed on the computing hardware, cause the computing hardware to perform operations. The operations include requesting a hardware security module (HSM) via a boot manager of a host module to verify application software of the host module and, via the verified application software, configuring a memory protection unit (MPU) to "do not execute" and / or "do not write" to at least a portion of memory of the host module. The operations further include executing the application software with the HSM enabled.

[0009] In some examples, configuring the MPU may include setting a stack region and a data region to "do not execute" and setting a hold region to "do not write" and "do not execute." Setting the hold region of the memory may include setting a first hold region to "do not write" and "do not execute" and a second hold region to "do not write" and "do not execute." The first hold region may be defined between the stack region and the data region, and the second hold region may be defined between the data region and a code region.In some implementations, the operations may include receiving a programming session request at the HSM and marking the programming session request at the host module to request execution of a bootloader of the host module and resetting a microcontroller, and verifying the bootloader by the HSM in response to the programming session request. The operations may also include: (i) disabling a protection feature of the HSM, where the protection feature may be configured to protect the memory of the host module, (ii) executing the programming session request to modify the memory of the host module and update the application software using the verified bootloader, and (iii) resetting the microcontroller, including the HSM and the host module, to execute the updated application software of the host module.Optionally, the operations may also include initiating the host module and preventing the host module from modifying the host module's memory via the HSM.

[0010] In still other aspects, a vehicle may include an electronic control unit (ECU) configured to receive programming session requests containing executable code, and a microcontroller communicatively coupled to the ECU. The microcontroller includes computing hardware and memory hardware. A hardware security module (HSM), a host module, and a memory protection unit (MPU) are stored in the memory hardware, and the HSM is configured to cause the computing hardware to perform operations. The operations include initiating the host module. The host module includes a boot manager, a bootloader, and application software. The operations also include determining, via the boot manager, what the bootloader and application software should execute, and verifying the bootloader and / or application software via the HSM.The operations further include configuring the memory protection unit (MPU) via one of the bootloader and the application software to "do not write" and / or "do not execute" at least a portion of a memory of the host module, and executing one of the bootloader and the application software via the host module.

[0011] In some examples, the operations may include receiving a programming session request containing the executable code at the HSM and verifying it via the HSM, verifying the bootloader and / or application software, and verifying the bootloader via the HSM in response to the programming session request. Optionally, initiating the host module may include restricting modification permissions of the host module's memory via the HSM. In some implementations, configuring the MPU may include setting a stack area and a data area of ​​the host module's memory to "no write" and "no execute" and setting a hold area to "no write" and "no execute." The hold area may be defined between the stack area and a code area of ​​the host module's memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings described herein are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Fig. 1 is a perspective view of a vehicle having a hardware security module and a host module according to the present disclosure; Fig. 2 is an example box diagram of a secure boot system for an electronic control unit of a vehicle according to the present disclosure; Fig. 3 is an example schematic diagram of an embodiment of an electronic control unit (ECU) according to the present disclosure; Fig. 4 is another example of a schematic diagram of an embodiment of an ECU system according to the present disclosure; Fig. 5 is an example flowchart for an ECU according to the present disclosure; Fig. 6 is another example of a flowchart for the ECU of Fig. 5; and Fig. 7 is an example flowchart for an ECU according to the present disclosure.

[0013] Corresponding reference numerals designate corresponding parts throughout the drawings. DETAILED DESCRIPTION

[0014] Example configurations will now be described in more detail with reference to the accompanying drawings. Example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details are set forth, such as examples of specific components, devices, and methods, in order to provide a thorough understanding of embodiments of the present disclosure. Those of ordinary skill in the art will appreciate that specific details need not be employed, that example configurations may be embodied in many different forms, and that the specific details and example configurations should not be construed to limit the scope of the disclosure.

[0015] The terminology used herein is for the purpose of describing specific example configurations only and is not intended to be limiting. As used herein, the articles “a,” “an,” and “the” include the plural forms unless the context clearly indicates otherwise. The terms “comprise,” “comprising,” “including,” and “having” are inclusive and therefore specify the presence of features, steps, operations, elements, components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein should not be construed as necessarily being performed in the particular order discussed or illustrated unless they are expressly identified as being in that order of performance.Additional or alternative steps may be applied.

[0016] When an element or layer is described as being "on" or "engaging with" another element or layer, or as being "connected" or "coupled" or "attached" to it, it may be directly on or engaging with, connected, coupled, or attached to the other element or layer, or there may be intervening elements or layers. Conversely, when an element is described as being "directly on" or "directly engaging with" another element or layer, or as being "directly connected" or "directly coupled" or "directly attached" to it, there must be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted similarly (e.g.,(e.g., "between" versus "directly between," "adjacent" or "contiguous" versus "directly adjacent" or "directly adjacent," etc.). As used herein, the term "and / or" includes all combinations of one or more of the related listed items.

[0017] The terms "first," "second," "third," etc., may be used herein to describe various elements, components, regions, layers, and / or subsections. These elements, components, regions, layers, and / or subsections should not be limited by these terms. These terms may only be used to distinguish one element, component, region, layer, or section from another area, layer, or subsection. Terms such as "first," "second," and other numerical terms do not imply a sequence or order unless the context clearly indicates otherwise.Thus, a first element, first component, first region, first layer, or first subsection discussed below could be referred to as a second element, second component, second region, second layer, or second subsection without departing from the teachings of the example configurations.

[0018] In this application, including the definitions below, the term “module” may be replaced by the term “circuit”.The term “module” may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor (shared, dedicated, or grouped) that executes code; a memory (shared, dedicated, or grouped) that stores code executed by a processor; other suitable hardware components that provide the described functionality; or a combination of some or all of the foregoing components, such as in a system-on-chip.

[0019] The term “code,” as used above, may include software, firmware, and / or microcode and may refer to programs, routines, functions, classes, and / or objects. The term “shared processor” includes a single processor that executes all or part of code from multiple modules. The term “group processor” includes a processor that, in combination with additional processors, executes all or part of code from one or more modules. The term “shared memory” includes a single memory that stores all or part of code from multiple modules. The term “group memory” includes memory that, in combination with additional memory, stores all or part of code from one or more modules. The term “memory” may be a subset of the term “computer-readable medium.”The term "computer-readable medium" encompasses non-transitory electrical and electromagnetic signals propagating through a medium and can therefore be considered tangible and non-transitory storage. Non-limiting examples of non-transitory storage include tangible computer-readable media, including non-volatile memory, magnetic storage, and optical storage.

[0020] The devices and apparatus described in this application may be implemented partially or entirely by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory, tangible, computer-readable medium. The computer programs may also include and / or be based on stored data.

[0021] A software application (i.e., a software resource) may refer to computer software that causes a computing device to perform a task. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0022] Non-transitory memory may be physical devices used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program state information) for use by a computing device. Non-transitory memory may be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware such as boot programs). Examples of volatile memory include random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), phase-change memory (PCM), and disks or tapes.

[0023] These computer programs (also referred to as programs, software, software applications, or code) contain machine instructions for a programmable processor and may be implemented in a procedural and / or object-oriented high-level language and / or in assembly / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, device, and / or apparatus (e.g., magnetic disks, optical disks, memories, programmable logic devices (PLDs)) designed to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal designed to provide machine instructions and / or data to a programmable processor.

[0024] Various implementations of the systems and techniques described herein may be realized in digital electronic and / or optical circuits, integrated circuits, purpose-built ASICs (Application Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementation in one or more computer programs executable and / or interpretable on a programmable system comprising at least one programmable processor operable as a special-purpose or general-purpose processor coupled to receive data and instructions from and transmit data and instructions to a storage system, and at least one input device and at least one output device.

[0025] The processes and logic sequences described in this specification can be performed by one or more programmable processors, also known as data processing hardware, which execute one or more computer programs to perform functions by operating on input data and producing output. The processes and logic sequences can also be performed by special-purpose logic circuits, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC). Examples of processors suitable for executing a computer program include both general-purpose and special-purpose microprocessors, as well as one or more processors of any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random-access memory, or both.The essential elements of a computer are a processor for executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer also includes, or is operatively coupled to, one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or to receive or transfer data to or from them, or both. However, a computer is not required to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.The processor and memory can be supplemented by or integrated into special logic circuits.

[0026] To enable interaction with a user, one or more aspects of the disclosure may be implemented on a computer having a display device, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or a touchscreen for displaying information to the user, and optionally a keyboard and pointing device, such as a mouse or trackball, for the user to provide input to the computer. Other types of devices may also be used to enable interaction with the user; for example, the user may receive any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and user input may be received in any form, including auditory, voice, or tactile input.Additionally, a computer may interact with a user by sending and receiving documents to and from a device used by the user, such as sending web pages to a web browser on a client device of the user in response to requests received from the web browser.

[0027] With reference to Fig. 1-4, a vehicle 100 includes an electronic control unit (ECU) 10 configured to execute functional software modules of the vehicle 100. The vehicle 100 of the present application may be an electric vehicle (EV), such that the vehicle 100 is powered by one or more electric motors (not shown). Additionally or alternatively, the vehicle 100 may be powered by an internal combustion engine (ICE) and / or may be a hybrid EV with an ICE. It is conceivable that the functional software modules of the ECU 10 may assist in executing functions of the vehicle 100. For example, the functional software modules may include a braking module configured to execute algorithms associated with braking or otherwise slowing the propulsion of the vehicle 100.

[0028] Although the ECU 10 is described herein with reference to a vehicle 100, it is contemplated that the ECU 10 may also be used in environments other than a vehicle. For example, the ECU 10 may be incorporated into various electronics-based devices that utilize a controller to execute software. The ECU 10 according to the present disclosure is configured to prevent tampering with the software during runtime of the ECU 10. For example, the system and method described herein is configured to prevent unauthorized modifications to the ECU 10. Thus, any practical device, including a vehicle 100 equipped with the ECU 10, may utilize the system and method described herein.

[0029] With further reference to Fig. 1 and Fig. 2, the ECU 10 includes one or more microcontrollers 12. The microcontrollers 12 are configured to execute code and software to perform the functions of the ECU 10. The microcontrollers 12 are equipped with data processing hardware 14 and memory hardware 16. The data processing hardware 14 is configured to execute operations stored in the memory hardware 16 in response to a programming session request 200. For example, the microcontroller 12 may receive executable code 202 as part of a programming session request 200 that triggers a series of operations to be performed by the data processing hardware 14. Stored in the memory hardware 16 are a hardware security module (HSM) 18, which includes a protection function 18a, and a host module 20. The protection function 18a of the HSM 18 is configured to protect the host module 20.The HSM 18 cooperates with the data processing hardware 14 to perform the operations described herein. Additionally or alternatively, the data processing hardware 14 can be used to run the software of the microcontroller 12 in combination with supporting the operation of the HSM 18 and the host module 20.

[0030] Although the HSM 18 is part of the microcontroller 12, the HSM 18 is configured with its own processor and memory. The HSM 18's processor runs a small amount of code that is isolated from external sources, protecting the HSM 18 from potential external tampering. The HSM 18 may also store one or more secret keys for communicating with other ECUs in the vehicle 100 and may contain cryptographic algorithms for securing communication with the other ECUs. The HSM 18 is configured to provide an initial security wall for the memory hardware 16, allowing the HSM 18 to validate the executable code 202 received as part of the programming session request 200. The programming session request 200 is received from an external source related to the ECU 10 and subsequently verified by the HSM 18.

[0031] With reference now to Fig. 1-4, the HSM 18 receives the executable code 202 from the flash memory 204 and verifies the authenticity of the code 202 before initiating the host module 20. The flash memory 204 may be external and / or internal flash memory. For example, the HSM 18 may read the code 202 from the internal flash memory 204. As described further below, the internal flash memory 204 may correspond to a host memory 22 of the host module 20. If the HSM 18 determines that the code 202 is corrupted or has otherwise been tampered with, the HSM 18 resets the microcontroller 12 and, in some cases, the ECU 10 to eliminate the corrupted code 202. When the HSM 18 validates the code 202, the HSM 18 initiates the host module 20. Although described sequentially, it is conceivable that the HSM 18 can simultaneously validate the code 202 and initiate the host module 20.When the host module 20 is initiated, the HSM 18 restricts the modification permissions of the host module 20, as described in more detail below. The host memory 22 includes a boot manager 24, a boot loader 26, and application software 28.

[0032] When the HSM 18 and the host module 20 are running concurrently, the host module 20 first executes the boot manager 24 via one-time programmable (OTP) memory. The OTP memory includes secure code for the boot manager 24 that is protected from external sources. Once the HSM 18 has verified the code 202, the boot manager 24 determines which of the bootloader 26 and the application software 28 should be executed. Both the bootloader 26 and the application software 28 interface with external sources, so it is beneficial to mitigate risks associated with potential vulnerabilities of both the bootloader 26 and the application software 28. The microcontroller 12 utilizes the HSM 18 and a memory protection unit (MPU) 30 to execute various protection protocols to minimize potential vulnerabilities of the bootloader 26 and the application software 28, as described in more detail below.

[0033] Still referring to Fig. 1-4, the memory hardware 16 of the microcontroller 12 is configured to be selectively modified to incorporate the code 202. The areas of the memory hardware 16 include a stack area 32, a data area 34, a code area 36, ​​and one or more intermediate hold areas 38. The stack area 32 is an area of ​​the memory hardware 16 where temporary variables are stored, and the data area 34 stores global variables of the ECU 10. Once the HSM 18 has verified the code 202, the application software 28 sets, for example, a flag 206 in the data area 34 of the memory hardware 16, as described in more detail below. The hold areas 38 may include a first hold area 38a defined between the stack area 32 and a second hold area 38b defined between the data area 34 and the code area 36.Additionally or alternatively, the memory hardware 16 may have a single hold area 38 defined between the data area 34 and the code area 36, ​​depending on the configuration of the memory hardware 16.

[0034] The hold areas 38 are configured to provide a trigger for the microcontroller 12 in the event of an overflow 40. The overflow 40 can occur during a write operation in either the stack area 32 or the data area 34. Therefore, the overflow 40 can also be referred to as a write overflow 40. The overflow 40 is an abnormal reaction to the write operation, such that data 202a (e.g., malicious code) written to the respective area 32, 34, 36 is corrupted. The hold areas 38 are configured as write-protected, so that no write or execution functions are permitted in the hold areas 38. Accordingly, any attempt to further write data 202a to the hold area 38 triggers a reset of the microcontroller 12 and the ECU 10. The reset deletes the data 202a from the memory hardware 16, including the host memory 22.

[0035] With reference to Fig. 1-4, the boot manager 24 of the host module 20 determines, in response to the flag 206 in the data area 34 of the memory hardware 16, whether the bootloader 26 or the application software 28 should be executed. For example, the boot manager 24 may receive the programming session request 200 to execute the bootloader 26. It is conceivable that the bootloader 26 and the application software 28 run separately from each other, so that when one of the bootloader 26 or the application software 28 is executing, the other is in standby mode. The bootloader 26 is configured to receive the new code 202 from the programming session request 200, while the application software 28 is configured to execute the software for the microcontroller 12 and the ECU 10.

[0036] In one example, the boot manager 24 determines that the bootloader 26 should be executed. For example, if the application software 28 is invalid or not programmed, the boot manager 24 determines that the bootloader 26 should be executed. In another example, the boot manager 24 may determine that the bootloader 26 should be executed in response to the programming session request 200. After the boot manager 24 determines to execute the bootloader 26, the bootloader 26 is verified by the HSM 18 before executing the bootloader 26. The HSM 18 generates code to check and verify that the bootloader 26 has not been modified. For example, the HSM 18 receives a location and length of the bootloader 26 from the boot manager 24 and may generate a secret key that might not otherwise be detectable by a third party gaining access to the storage hardware 16.

[0037] Verification by the HSM 18 ensures that the bootloader 26 is free of malware or other unauthorized modifications before the HSM 18 allows the bootloader 26 to write the new code 202 to the host memory 22. Once the HSM 18 has verified the bootloader 26, the HSM 18 allows the boot manager 24 to execute the bootloader 26. Verification of the bootloader 26 allows the bootloader 26 to modify the host memory 22, except in one location of the bootloader 26. In addition to the HSM 18 verifying the bootloader 26, the MPU 30 is configured to prohibit writing to and execution of at least one area of ​​the host memory 22. For example, the stack area 32 and the data area 34 are set to "Do Not Execute" and the hold areas 38 are set to "Do Not Write" and "Do Not Execute" as mentioned above.

[0038] With further reference to Fig. 1-4, the bootloader 26 can write the code 202 to the code area 36. To execute the code 202 in the code area 36, ​​the MPU 30 is configured to allow execution from this area. The HSM 18 controls access to and modification rights to the memory hardware 16, including the host memory 22. Thus, the protection function 18a of the HSM 18 is temporarily disabled to allow the bootloader 26 to modify the code 202 in the host memory 22 and / or the memory hardware 16. As generally noted above, the protection function 18a of the HSM 18 is configured to protect the host memory 22 of the host module 20. Thus, the protection function 18a is disabled prior to execution of the programming session request 200. The verified bootloader 26 may execute the programming session request 200 to modify the host memory 22 and, in one example, update the application software 28.

[0039] As generally mentioned above, when the bootloader 26 writes data 202a to one of the stack area 32 and the data area 34 and an overflow 40 occurs, the hold areas 38 automatically trigger a reset of the microcontroller 12 and the ECU 10 to delete the data 202a from the memory hardware 16. Thus, the hold areas 38 prevent the malicious code from accessing the code area 36. Once the bootloader 26 has completed updating the host memory 22, the bootloader 26 resets the microcontroller 12 and the ECU 10 to execute the newly updated software. In some examples, the newly updated software is the application software 28. In other examples, the newly updated software may include, among other things, calibration data, an update to the HSM 18, and any other practical software update for the host module 20, the microcontroller 12, and the ECU 10.By resetting the microcontroller 12, including the HSM 18 and the host module 20, the updated application software 28 is executed and the programming session request 200 is completed by entering the application software 28.

[0040] Still referring to Fig. 1-4, in some examples, the microcontroller 12 may specify that the application software 28 be executed. The bootloader 26 is used to configure new updates, such as code and / or software updates for the storage hardware 16 and / or the host memory 22. In other words, the bootloader 26 remains idle until the programming session request 200 is received. Therefore, the boot manager 24 may often determine that the application software 28, rather than the bootloader 26, should be executed. In this example, the boot manager 24 requests verification of the application software 28 by the HSM 18, similar to the verification of the bootloader 26 described above. The boot manager 24 is authorized to execute the application software 28 once it has been verified by the HSM 18.

[0041] As also described above, the MPU 30 is configured such that the stack area 32 and the data area 34 are set to "Do Not Execute," while the hold areas 38 are set to "Do Not Write" and "Do Not Execute." The configuration of the MPU 30 provides failover in the event that potential vulnerabilities exist in the application software 28. In addition to the MPU 30 being configured to control write and execute permissions, the HSM 18 remains enabled during the runtime of the application software 28. Thus, unlike the bootloader 26, the host memory 22 and / or the storage hardware 16 cannot be modified during the runtime of the application software 28.Because the code area 36 is configured to allow read, write, and execute access to run the application software 28, the HSM 18 protects the code area 22, 36 from being modified by malicious attacks that may occur during the runtime of the application software 28. The MPU 30 further assists the HSM 18 in protecting the code area 36 by limiting the write and execute permissions in the various areas of memory 16, 22.

[0042] When the ECU 10 receives a programming session request 200, a flag is set to perform a reset. For example, the programming session request 200 is flagged on the host module 20 to request execution of the bootloader 26. In response to the flag, the application software 28 resets the microcontroller 12 and / or the ECU 10 and initiates the protocol associated with the bootloader 26, as described above. For example, the programming session request 200 is executed to modify the memory 16, 22 and update the application software 28 using the verified bootloader 26. Once the bootloader 26 has completed the update, the microcontroller is reset to execute the updated application software 28.

[0043] The application software 28 may run continuously until an update request is received. For example, the programming session request 200 is an update request that would trigger a reset to execute the bootloader 26 and stop the application software 28. The operations described herein may be reset in a power-on state, an extreme deep sleep of the ECU 10 and / or the microcontroller 12, and upon a detected vulnerability exploit, such as a breach of the MPU 30. An interrupt of the microcontroller 12 triggers a reset to restart the system as a whole. The HSM 18 is configured to continuously protect the code area 22 of the memory hardware 16, except that the HSM 18 disables write protection during operation of the bootloader 26. Thus, when the application software 28 is executing, the memory protection of the HSM 18 remains enabled.

[0044] With reference now to Fig.5-7 illustrates an exemplary system flowchart for the ECU 10 described herein. At 400, the HSM 18 receives the code 202 and, at 402, loads the code 202 into the memory hardware 16. The HSM 18 prevents the host module 20 from modifying the host memory 22 at 404. If the application software 28 is invalid or not yet programmed, or in response to a programming session request 200, the HSM 18 then verifies the bootloader 26 at 406. The boot manager 24 determines at 408 whether the bootloader 26 has been verified by the HSM 18. If the bootloader 26 is not verified, the boot manager 24 resets the microcontroller 12 at 410. If the bootloader 26 is verified, the bootloader 26 is permitted at 412 to modify the host memory 22 except in a location of the bootloader 26.At 414, the MPU 30 is configured, and at 416 and 418, the stack area 32 and the data area 34 are set to "Do Not Execute" in response to the configured MPU 30. At 420, the hold area is set to "Do Not Write" and "Do Not Execute" in response to the configured MPU 30. Finally, the verified code 202 can be input into the host memory 22 by the bootloader 26 and executed.

[0045] Another example flowchart describes the process of executing application software 28. At 500, HSM 18 checks application software 28. Boot manager 24 determines at 502 whether application software 28 is verified. If application software 28 is not verified, microcontroller 12 verifies bootloader 26 as described above in steps 408 and 412. If application software 28 is verified, MPU 30 is configured at 506. It is also contemplated that MPU 30 may be configured by application software 28 when application software 28 is executed for the first time. At 508 and 510, stack area 32 and data area 34 are each set to "Do Not Execute," and at 512, hold areas 38 are set to "Do Not Write" and "Do Not Execute." The application software 28 is released for execution at 514.The application software 28 can then determine at 516 whether a valid programming session request 200 is present. If no valid programming session request 200 is present, the application software 28 continues running. If a valid programming session request 200 is present, the application software 28 sets a flag 206 at 518 so that the boot manager 24 checks and resets the microcontroller 12.

[0046] While several embodiments have been described, it should be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other embodiments are also within the scope of the following claims.

[0047] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or limiting of the disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but may be interchangeable and used in a selected configuration, even if not specifically shown or described. These may also be varied in many respects. Such variations are not to be considered a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.

Claims

[1] System comprising: data processing hardware; and Storage hardware in communication with the computing hardware, the storage hardware storing instructions that, when executed on the computing hardware, cause the computing hardware to perform operations including: Requesting a hardware security module (HSM) via a host module boot manager to verify host module application software; Configuring a memory protection unit (MPU) via the verified application software to “do not execute” and / or “do not write” for at least one area of ​​a memory of the host module; and Running the application software with the HSM enabled. [2] The system of claim 1, wherein configuring the MPU comprises setting a stack area and a data area to "do not execute" and setting a hold area to "do not write" and "do not execute". [3] The system of claim 2, wherein setting the hold area of ​​the memory comprises setting a first hold area to "do not write" and "do not execute" and a second hold area to "do not write" and "do not execute", the first hold area being defined between the stack area and the data area and the second hold area being defined between the data area and a code area. [4] The system of claim 1, further comprising receiving a programming session request at the HSM and marking the programming session request at the host module to request execution of the host module by a bootloader. [5] The system of claim 4, further comprising initiating the host module and preventing the host module from modifying the memory of the host module via the HSM. [6] The system of claim 5, wherein initiating the host module comprises determining the boot manager to be executed by the boot loader and the application software. [7] The system of claim 4, further comprising resetting a microcontroller and verifying the bootloader by the HSM in response to the programming session request. [8] The system of claim 7, further comprising: (i) disabling a protection function of the HSM, the protection function being configured to protect the memory of the host module, (ii) executing the programming session request to modify the memory of the host module and update the application software using the verified bootloader, and (iii) resetting the microcontroller including the HSM and the host module to execute the updated application software of the host module. [9] The system of claim 7, wherein verifying the bootloader by the HSM comprises allowing modification of the host module's memory except in a bootloader location and preventing modification of the host module's memory prior to executing the programming session request. [10] The system of claim 7, wherein verifying the bootloader by the HSM comprises receiving a position and length of the bootloader from the boot manager and generating a key for the bootloader.

Images