Vehicle computer system and method

Abstract

A system may include data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include requesting, via a boot manager of the host module, a hardware security module (HSM) to verify application software of the host module, and configuring, via the verified application software, a memory protection unit (MPU) to at least one of not execute and not write to at least one region of memory of the host module. The operations also include executing the application software with the HSM enabled.

Description

Technical Field

[0001] The present invention generally relates to vehicle computing systems and methods that prevent software tampering during runtime. Background Art

[0002] The information provided in this section is for the purpose of generally presenting the background of the present disclosure. To the extent described in this section, the work of the presently named inventors, as well as aspects of the description that may not qualify as prior art at the time of filing, are neither explicitly nor implicitly admitted to be prior art with respect to the present disclosure.

[0003] Secure boot is a security control commonly used for embedded devices. Secure boot is configured to ensure that the corresponding embedded device only executes genuine software. The authenticity of the software is usually verified by the secure boot at each boot. However, when the software is only authenticated at boot time, the software may be modified during the software runtime without being detected. For example, devices are often configured to power off independently, so that if previously authenticated software is modified, the device may not be powered off to reset and stop the potential execution of malware. Summary of the invention

[0004] In some aspects, a computer-implemented method when executed by data processing hardware causes the data processing hardware to perform operations including: receiving code from a flash memory at a hardware security module (HSM), verifying the authenticity of the code via the HSM, and booting a host module in response to the verified code, the host module including a boot manager, a boot loader, and application software. The operations also include receiving a programming session request at the boot manager to execute the boot loader, and configuring a memory protection unit (MPU) through the boot loader to at least one of not writing and not executing at least one area of ​​a memory of the host module. The programming session is performed to modify the memory of the host module, and the application software of the host module is updated using the verified boot loader, and a microcontroller including the HSM and the host module is reset to execute the updated application software of the host module.

[0005] In some examples, starting the host module may include determining which of the boot loader and the application software to execute via the boot manager, and verifying the boot loader by the HSM includes allowing the host module's memory to be modified except at the location of the boot loader, and preventing the host module's memory from being modified before the programming session request is executed. Optionally, configuring the MPU may include setting the stack area and data area of ​​the host module's memory to no execution by the MPU, and setting the holding area of ​​the host module's memory to no write and no execution by the MPU. The microcontroller may be reset by completing the programming session and entering the application software.

[0006] In some embodiments, executing a programming session request may include disabling a protection feature of the HSM, which may be configured to protect the memory of the host module, and performing an update to the code area of ​​the memory. The retention area of ​​the memory may be set by setting the first retention area to not write and not execute and setting the second retention area to not write and not execute. The first retention area may be defined between the stack area and the data area, and the second retention area may be defined between the data area and the code area. In some cases, executing a programming session may include triggering a reset in one of the first retention area and the second retention area in response to a write overflow of data. Optionally, the HSM may verify the boot loader by receiving the location and length of the boot loader from the boot manager and generating a key for the boot loader.

[0007] In other aspects, a system may include data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include requesting a hardware security module (HSM) to verify application software of the host module via a boot manager of the host module, and configuring a memory protection unit (MPU) to at least one of not executing and not writing to at least one area of ​​the memory of the host module via the verified application software. The operations also include executing the application software with the HSM enabled.

[0008] In some examples, configuring the MPU may include setting the stack area and the data area to not execute, and setting the retention area to not write and not execute. Setting the retention area of ​​the memory may include setting the first retention area to not write and not execute, and setting the second retention area to not write and not execute. The first retention area may be defined between the stack area and the data area, and the second retention area may be defined between the data area and the code area. In some embodiments, the operation may include receiving a programming session request at the HSM, marking the programming session request at the host module to request execution of the boot loader of the host module, and in response to the programming session request, resetting the microcontroller through the HSM and verifying the boot loader. The operation may also include (i) disabling a protection feature of the HSM, which 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 boot loader, and (iii) resetting the microcontroller including the HSM and the host module to execute the updated application software of the host module. Optionally, the operation may include starting the host module and preventing the host module from modifying the memory of the host module through the HSM.

[0009] In other aspects, a vehicle may include an electronic control unit (ECU) configured to receive a programming session request including executable code, and a microcontroller communicatively coupled to the ECU. The microcontroller includes data processing hardware and memory hardware. The memory hardware stores a hardware security module (HSM), a host module, and a memory protection unit (MPU), and the HSM is configured to cause the data processing hardware to perform an operation. The operation includes starting the host module. The host module includes a boot manager, a boot loader, and application software. The operation also includes determining which of the boot loader and the application software to execute via the boot manager, and verifying at least one of the boot loader and the application software via the HSM. The operation also includes configuring the memory protection unit (MPU) to at least one of not writing and not executing at least one area of ​​the memory of the host module via one of the boot loader and the application software, and executing one of the boot loader and the application software via the host module.

[0010] In some examples, the operation may include receiving at the HSM and verifying via the HSM a programming session request including executable code, and verifying at least one of the boot loader and the application software includes verifying the boot loader via the HSM in response to the programming session request. Optionally, starting the host module may include limiting the modification permission of the host module's memory through the HSM. In some embodiments, configuring the MPU may include setting the stack area and data area of ​​the host module's memory to no write and no execute, and setting the retention area to no write and no execute. The retention area may be defined between the stack area and the code area of ​​the host module's memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings described herein are for illustrative purposes only of selected configurations and are not intended to limit the scope of the present disclosure.

[0012] Figure 1 is a perspective view of a vehicle having a hardware security module and a host module according to the present disclosure;

[0013] Figure 2 is an example block diagram of a secure start system for a vehicle electronic control unit according to the present disclosure;

[0014] Figure 3 is a schematic diagram of an example of an implementation of an electronic control unit (ECU) system according to the present invention;

[0015] Figure 4 is another exemplary schematic diagram of the execution of the ECU system according to the present invention;

[0016] Figure 5 is an example flow chart of an ECU according to the present invention;

[0017] Figure 6 yes Figure 5 Another example flow chart of an ECU of; and

[0018] Figure 7 is an example flow chart of the ECU according to the present invention.

[0019] Corresponding reference characters indicate corresponding parts throughout the several views. DETAILED DESCRIPTION

[0020] Example configurations will now be described more fully with reference to the accompanying drawings. Example configurations are provided so that the present disclosure will be thorough and will fully convey the scope of the present disclosure to those of ordinary skill in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configurations of the present disclosure. It will be apparent to those of ordinary skill in the art that specific details need not be employed, that example configurations may be implemented in many different forms, and that the specific details and exemplary configurations should not be construed as limiting the scope of the present disclosure.

[0021] The terms used herein are only for describing specific exemplary configurations, not for limiting. As used herein, the singular articles "a", "an" and "the" may also be intended to include plural forms, unless the context clearly indicates otherwise. The terms "comprise", "include", "contain" and "have" are inclusive, thus specifying the presence of features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts and / or groups thereof. The method steps, processes and operations described herein should not be interpreted as necessarily requiring them to be performed in the specific order discussed or shown, unless specifically identified as an execution order. Additional or alternative steps may be adopted.

[0022] When an element or layer is referred to as being "on another element or layer," "engaged to," "connected to," "attached to," or "coupled to" another element or layer, it may be directly on, engaged, connected, attached to, or coupled to another element or layer, or there may be intermediate elements or layers. Conversely, when an element is referred to as being "directly on another element or layer," "directly engaged to," "directly connected to," "directly attached to," or "directly coupled to" another element or layer, there may be no intermediate elements or layers. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.). As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0023] The terms first, second, third, etc. can be used here to describe various elements, components, regions, layers and / or parts. These elements, components, regions, layers and / or parts should not be limited by these terms. These terms are only used to distinguish each element, component, region, layer or part. Terms such as "first", "second" and other numerical terms do not imply order or sequence unless the context clearly indicates. Therefore, the first element, component, region, layer or part discussed below can be referred to as the second element, component, region, layer or part, without departing from the teaching of the example configuration.

[0024] In this application, including the definitions below, the term module may be replaced by the term circuit. The term "module" may refer to or be part of an application specific integrated circuit (ASIC), 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 group) that executes code; a memory (shared, dedicated, or group) that stores code executed by the processor; other suitable hardware components that provide the functionality; or a combination of some or all of the above, such as in a system on a chip.

[0025] The term code used above may include software, firmware and / or microcode, and may refer to a program, a routine, a function, a class and / or an object. The term shared processor includes a single processor that executes some or all of the code from multiple modules. The term group processor includes a processor that executes some or all of the code from one or more modules in combination with an additional processor. The term shared memory includes a single memory that stores some or all of the code from multiple modules. The term group memory includes a memory that stores some or all of the code from one or more modules in combination with an additional memory. The term memory may be a subset of the term computer-readable medium. The term computer-readable medium does not include transient electrical signals and electromagnetic signals propagated through the medium and can therefore be considered to be tangible non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic memory, and optical memory.

[0026] The apparatus and methods described in this application may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer program includes processor executable instructions stored on at least one non-transitory tangible computer readable medium. The computer program may also include and / or rely on stored data.

[0027] Software applications (i.e., software resources) may refer to computer software that enables a computing device to perform tasks. In some examples, software applications may be referred to as "applications," "apps," or "programs." 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.

[0028] Non-transitory memory can be a physical device 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 can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0029] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing 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 for providing machine instructions and / or data to a programmable processor.

[0030] Various implementations of the systems and techniques described herein can be realized in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs executable and / or interpretable on a programmable system comprising at least one programmable processor, which may be special purpose or general purpose, coupled to receive data and instructions from a storage system, and to send data and instructions to the storage system.

[0031] The processes and logic flows described in this specification can be performed by one or more programmable processors, also known as data processing hardware, executing one or more computer programs to perform functions by operating on input data and generating outputs. These processes and logic flows can also be performed by dedicated logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application-specific integrated circuits). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include or be operably connected to one or more large-capacity storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive data from the large-capacity storage device or to transmit data to it, or both. However, a computer does not need to have such a device. 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 may be supplemented by or incorporated in special purpose logic circuitry.

[0032] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen, and an optional keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0033] refer to Figure 1-4, the 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 contemplated that the functional software modules of the ECU 10 may help execute the functions of the vehicle 100. For example, in one 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.

[0034] Although the ECU 10 is described herein with respect to a vehicle 100, it is also contemplated that the ECU 10 may be used in non-vehicle settings. For example, the ECU 10 may be incorporated into a variety of electronic-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 the runtime of the ECU 10. For example, the systems and methods described herein are configured to prevent unauthorized changes to the ECU 10. Therefore, any feasible device, including a vehicle 100 equipped with the ECU 10, may utilize the systems and methods described herein.

[0035] Further references Figure 1 and 2 , the ECU 10 includes one or more microcontrollers 12. The microcontroller 12 is configured to execute code and run software to perform the functions of the ECU 10. The microcontroller 12 is equipped with data processing hardware 14 and memory hardware 16. The data processing hardware 14 is configured to execute operations stored on the memory hardware 16 in response to the programming session request 200. For example, the microcontroller 12 can receive an executable code 202 as part of the programming session request 200, which triggers a series of operations to be performed by the data processing hardware 14. The memory hardware 16 stores a hardware security module (HSM) 18 and a host module 20, and the HSM 18 includes a protection feature 18a. The protection feature 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. In addition or alternatively, the data processing hardware 14 can be used to operate the software of the microcontroller 12 in conjunction with the operations supporting the HSM 18 and the host module 20.

[0036] Although the HSM18 is part of the microcontroller 12, the HSM18 is configured with a processor and memory dedicated to the HSM18. The processor of the HSM18 runs a small amount of code that is isolated from external sources, so that the HSM18 is protected from potential external manipulation. The HSM18 can also store one or more keys to communicate with other ECUs in the vehicle 100, and can contain encryption algorithms to protect communications with other ECUs. The HSM18 is configured to provide an initial security wall to the memory hardware 16, so that the HSM18 is configured to verify the executable code 202 received as part of the programming session request 200. The programming session request 200 is received from an external source relative to the ECU10 and is subsequently verified by the HSM18.

[0037] Reference now Figure 1-4 , the HSM18 receives the executable code 202 from the flash memory 204 and verifies the authenticity of the code 202 before starting the host module 20. The flash memory 204 can be an external flash memory and / or an internal flash memory. For example, the HSM18 can read the code 202 from the internal flash memory 204. As described below, the internal flash memory 204 can correspond to the host memory 22 of the host module 20. If the HSM18 determines that the code 202 is damaged or has been manipulated, the HSM18 will reset the microcontroller 12 and reset the ECU10 in some cases to eliminate the damaged code 202. If the HSM18 verifies the code 202, the HSM18 starts the host module 20. Although described in a sequential manner, it is conceivable that the HSM18 can verify the code 202 and start the host module 20 at the same time. When starting the host module 20, the HSM18 limits the modification permission 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.

[0038] If the HSM 18 and the host module 20 are executed simultaneously, the host module 20 will first execute the boot manager 24 through the one-time programmable (OTP) memory. The OTP memory includes secure code for the boot manager 24, which is protected from external sources. Once the HSM 18 has verified the code 202, the boot manager 24 determines which of the boot loader 26 and the application software 28 to run. Both the boot loader 26 and the application software 28 interface with external sources, thereby facilitating mitigation of risks associated with potential weaknesses in each of the boot loader 26 and the application software 28. The microcontroller 12 utilizes the HSM 18 and the memory protection unit (MPU) 30 to execute various protection protocols to minimize any potential vulnerabilities of the boot loader 26 and the application software 28, as described in more detail below.

[0039] Still refer to Figure 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 retention areas 38 defined therebetween. The stack area 32 is an area of ​​the memory hardware 16 that stores temporary variables, and the data area 34 stores global variables of the ECU 10. For example, once the HSM 18 has verified the code 202, the application software 28 sets a flag 206 in the data area 34 of the memory hardware 16, as described in more detail below. The retention area 38 may include a first retention area 38a defined between the stack area 32 and the data area and a second retention area 38b defined between the data area 34 and the code area 36. Additionally or alternatively, depending on the configuration of the memory hardware 16, the memory hardware 16 may have a single retention area 38 defined between the data area 34 and the code area 36.

[0040] The holding area 38 is configured to provide a trigger for the microcontroller 12 in the event of an overflow 40. During a write operation of the stack area 32 or the data area 34, an overflow 40 may occur. Therefore, the overflow 40 may be referred to as a write overflow 40. The overflow 40 is an abnormal response to the write operation, so that the data 202a (e.g., malicious code) being written to the corresponding area 32, 34, 36 is corrupted. The holding area 38 is configured to be read-only, so that writing or executing functions at the holding area 38 is not allowed. Therefore, any attempt to continue writing data 202a in the holding area 38 will trigger a reset of the microcontroller 12 and the ECU 10. The reset will erase the data 202a from the memory hardware 16 including the host memory 22.

[0041] refer to Figure 1-4 In response to the flag 206 in the data area 34 of the memory hardware 16, the boot manager 24 of the host module 20 determines whether to execute the boot loader 26 or the application software 28. For example, the boot manager 24 may receive the programming session request 200 to execute the boot loader 26. It is expected that the boot loader 26 and the application software 28 are run separately from each other, so that when one of the boot loader 26 and the application software 28 is executed, the other is in a standby state. The boot loader 26 is configured to load the new code 202 from the programming session request 200, and the application software 28 is configured to run software for the microcontroller 12 and the ECU 10.

[0042] In one example, the boot manager 24 determines that the boot loader 26 should be run. For example, if the application software 28 is invalid or has not been programmed, the boot manager 24 determines that the boot loader 26 should be run. In another example, the boot manager 24 can determine that the boot loader 26 should be run in response to the programming session request 200. After the boot manager 24 determines to run the boot loader 26, before executing the boot loader 26, the HSM 18 verifies the boot loader 26. The HSM 18 generates code to check and verify that the boot loader 26 has not been modified. For example, the HSM 18 receives the location and length of the boot loader 26 from the boot manager 24, and can generate a key that otherwise may not be detected by a third party who obtains access to the memory hardware 16.

[0043] The verification by the HSM 18 ensures that the bootloader 26 is protected from 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 verifies the bootloader 26, the HSM 18 allows the boot manager 24 to run the bootloader 26. The verification of the bootloader 26 allows the bootloader 26 to modify the host memory 22 except at the location of the bootloader 26. In addition to the verification of the bootloader 26 by the HSM 18, the MPU 30 is configured to prohibit writing and executing at least one area of ​​the host memory 22. For example, the stack area 32 and the data area 34 are set to no execution, and the holding area 38 is set to no write and no execution, as described above.

[0044] Further references Figure 1-4 , the bootloader 26 can write the code 202 to the code area 36. In order 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 the access and modification rights to the memory hardware 16 including the host memory 22. Therefore, the protection feature 18a of the HSM 18 is temporarily disabled to allow the bootloader 26 to modify the host memory 22 and / or the code 202 in the memory hardware 16. As generally described above, the protection feature 18a of the HSM 18 is configured to protect the host memory 22 of the host module 20. Therefore, before executing the programming session request 200, the protection feature 18a is disabled. The authenticated bootloader 26 can execute the programming session request 200 to modify the host memory 22, and in one example, update the application software 28.

[0045] As generally described above, if the bootloader 26 is writing data 202a in one of the stack area 32 and the data area 34, and an overflow 40 occurs, the retention area 38 will automatically trigger a reset of the microcontroller 12 and the ECU 10 to erase the data 202a from the memory hardware 16. Therefore, the retention area 38 prevents malicious code from accessing the code area 36. Once the bootloader 26 completes the update of the host memory 22, the bootloader 26 will perform a reset of 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, but is not limited to, calibration data, updates to the HSM 18, and any other feasible software updates for the host module 20, the microcontroller 12, and the ECU 10. The microcontroller 12 including the HSM 18 and the host module 20 is reset, the updated application software 28 is executed, and the programming session request 200 is completed by entering the application software 28.

[0046] Still refer to Figure 1-4 , in some examples, the microcontroller 12 may determine to run the application software 28. The bootloader 26 is used to configure new updates, such as code and / or software updates for the memory hardware 16 and / or the host memory 22. In other words, unless a programming session request 200 is received, the bootloader 26 remains idle. Therefore, the boot manager 24 may often determine that the application software 28 should be run instead of the bootloader 26. In this example, the boot manager 24 requests the HSM 18 to verify the application software 28, similar to the bootloader 26 verification described above. Once verified by the HSM 18, the boot manager 24 is authorized to run the application software 28.

[0047] As similarly described above, the MPU 30 is configured to set the stack area 32 and the data area 34 to non-execution, while setting the holding area 38 to non-write and non-execution. The configuration of the MPU 30 provides fault protection in the event of any potential vulnerability in the application software 28. In addition to the MPU 30 being configured to control write and execute privileges, the HSM 18 remains enabled during the runtime of the application software 28. Therefore, unlike the boot loader 26, the host memory 22 and / or the memory hardware 16 cannot be modified during the operation of the application software 28. Since the code area 36 is set to read, write and execute in order 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 operation of the application software 28. The MPU 30 further supports the HSM 18 to protect the code area 36 by limiting the write and execute privileges within each area of ​​the memory 16, 22.

[0048] If the ECU 10 receives the programming session request 200, a flag is set to perform a reset. For example, the programming session request 200 is marked at the host module 20 to request execution of the boot loader 26. As described above, in response to the flag, the application software 28 will reset the microcontroller 12 and / or ECU 10 and initiate a protocol associated with the boot loader 26. For example, the programming session request 200 is executed to modify the memory 16, 22 and update the application software 28 using the authenticated boot loader 26. Once the boot loader 26 has completed the update, the microcontroller is reset to execute the updated application software 28.

[0049] The application software 28 can continue to run until an update request is received. For example, the programming session request 200 is an update request that will trigger a reset to execute the bootloader 26 and stop the application software 28. The operations described here can be reset at power-on state, extreme deep sleep of the ECU 10 and / or microcontroller 12, and detected vulnerability exploits (such as MPU 30 violations). An interrupt from the microcontroller 12 triggers a reset to restart the entire system. 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. Therefore, when the application software 28 is executed, the HSM 18 memory protection remains enabled.

[0050] Reference now Figure 5-7 , shows an example flow chart of the system described herein for the ECU 10. At 400, the HSM 18 receives the code 202, and at 402, the code 202 is loaded onto the memory hardware 16. At 404, the HSM 18 prevents the host module 20 from modifying the host memory 22. If the application software 28 is invalid or has not been programmed, or in response to the programming session request 200, the HSM 18 then verifies the boot loader 26 at 406. At 408, the boot manager 24 determines whether the HSM 18 has verified the boot loader 26. If the boot loader 26 is not verified, then at 410, the boot manager 24 resets the microcontroller 12. If the boot loader 26 is verified, then at 412, the boot loader 26 is allowed to modify the host memory 22, except at the location of the boot loader 26. At 414, the MPU 30 is configured, and at 416 and 418, in response to the configured MPU 30, the stack area 32 and the data area 34 are set to non-execution. At 420 , in response to the configured MPU 30 , the retention area is set to no-write and no-execute. Finally, the verified code 202 may be entered and executed into the host memory 22 by the bootloader 26 .

[0051] In another example flow chart, a process of executing application software 28 is described. At 500, HSM 18 verifies application software 28. At 502, boot manager 24 determines whether application software 28 is verified. If application software 28 is not verified, microcontroller 12 verifies boot loader 26, as described above with respect to steps 408 and 412. If application software 28 is verified, then at 506, MPU 30 is configured. It is also contemplated that MPU 30 may be configured by application software 28 when application software 28 is first executed. At 508 and 510, each of stack area 32 and data area 34 is set to no-execute, and at 512, retention area 38 is set to no-write and no-execute. At 514, application software 28 is authorized to run. Application software 28 may then determine at 516 whether there is a valid programming session request 200. If there is no valid programming session request 200, application software 28 continues to run. If there is a valid programming session request 200 , then at 518 , the application software 28 sets a flag 206 for the boot manager 24 to check and reset the microcontroller 12 .

[0052] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Therefore, other embodiments are also within the scope of the following claims.

[0053] The foregoing description has been provided for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but where applicable, they are interchangeable and can be used in a selected configuration even if not specifically shown or described. This can also be varied in a variety of ways. Such variations should not be considered a departure from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A system comprising: Data processing hardware; and Memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations including: Requesting a hardware security module (HSM) to authenticate the application software of the host module via a boot manager of the host module; configuring a memory protection unit (MPU) by verified application software to at least one of not execute and not write to at least one area of ​​a memory of the host module; and Execute the application software with the HSM enabled.

2. The system according to claim 1, wherein: Configuring the MPU includes setting a stack area and a data area to no-execution, and setting a hold area to no-write and no-execution.

3. The system according to claim 2, wherein: Setting the retention area of ​​the memory includes setting the first retention area to be non-write and non-execute, and setting the second retention area to be non-write and non-execute, the first retention area is defined between the stack area and the data area, and the second retention area is defined between the data area and the 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 a boot loader of the host module.

5. The system according to claim 4, further comprising starting the host module and preventing the host module from modifying the memory of the host module through the HSM.

6. The system according to claim 5, wherein: Starting the host module includes determining, by the boot manager, which one of the boot loader and the application software to execute.

7. The system of claim 4, further comprising resetting a microcontroller and verifying the boot loader via the HSM in response to the programming session request.

8. The system according to claim 7, further comprising: (i) disabling a protection feature of the HSM, the protection feature 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 authenticated boot loader, and (iii) resetting a microcontroller including the HSM and the host module to execute the updated application software of the host module.

9. The system according to claim 7, wherein: Authenticating the bootloader through the HSM includes allowing modification of the host module's memory except at the location of the bootloader and preventing modification of the host module's memory prior to executing the programming session request.

10. The system according to claim 7, wherein: Authenticating the boot loader by the HSM includes receiving a location and length of the boot loader from the boot manager and generating a key for the boot loader.

Images