Access protection control for non-volatile memory

Abstract

Access protection control for non-volatile memory is disclosed. An electronic device includes a memory interface and a non-volatile memory (NVM) controller. The memory interface is to communicate with the NVM. The NVM controller is to manage reading and writing data in the NVM, save one or more access protection (AP) policies defined for one or more respective AP requestors, and allow or deny access to given data in the NVM according to the AP policy defined for an AP requestor requesting access to the given data.

Description

Technical Field

[0001] This disclosure relates generally to computer system security, and specifically to the protection of non-volatile memory in computer systems against malicious or accidental access. Background Technology

[0002] Non-volatile memory (NVM), such as flash memory and electrically erasable programmable read-only memory (EEPROM), is commonly used in computer systems to store sensitive firmware (FW), such as boot code. For some background on how computer systems are protected against malicious or accidental writes to sensitive non-volatile memory today, see the section titled "Understanding Security" in NVIDIA Driver OS 5.1 Linux Software Development Kit (SDK) version 5.1.6.1 (Publication No.: PR-08890-5.1, Release Date: November 6, 2019). Summary of the Invention

[0003] One embodiment described herein provides an electronic device including a memory interface and a non-volatile memory (NVM) controller. The memory interface is used to communicate with the NVM. The NVM controller is used to: manage reading and writing data in the NVM, store one or more WP policies defined by one or more corresponding write protection (WP) requesters, receive WP instructions, and allow or deny writing given data to the NVM according to the WP policy defined by the WP requester requesting the writing of given data, the WP policy depending at least on the WP instruction.

[0004] In some embodiments, the electronic device further includes one or more processors for requesting access to the NVM. In some embodiments, the WP policy specifies a protected set of addresses to be written to the NVM. In the disclosed embodiments, this set of addresses is non-contiguous.

[0005] In one embodiment, the one or more WP policies include: (i) a first WP policy defined for a first WP requester, the first WP policy specifying that a protected first set of addresses be written to it in the NVM, and (ii) a second WP policy defined for a second WP requester, the second WP policy specifying that a protected second set of addresses be written to it in the NVM, the second set of addresses being different from the first set of addresses.

[0006] In some embodiments, the NVM controller is used to authenticate the identity of the WP requester according to the WP policy. In some embodiments, the NVM controller is used to authenticate write data constrained by the WP policy according to the WP policy.

[0007] Furthermore, according to one embodiment described herein, an electronic device is also provided, comprising a memory interface and a non-volatile memory (NVM) controller. The memory interface is used to communicate with the NVM. The NVM controller is used to: manage reading and writing data in the NVM, store one or more AP policies defined by one or more corresponding access protection (AP) requesters, and allow or deny access to given data in the NVM according to the AP policies defined for AP requesters requesting access to given data.

[0008] Furthermore, according to one embodiment described herein, a method for write protection (WP) for non-volatile memory (NVM) is also provided. The method includes: saving one or more WP policies defined for one or more corresponding WP requesters, and receiving a WP indication. The WP policy defined for the WP requester requesting to write given data allows or denies writing the given data to the NVM, the WP policy depending at least on the WP indication.

[0009] Furthermore, according to one embodiment described herein, a method for access protection (AP) of non-volatile memory (NVM) is also provided. The method includes: storing one or more AP policies defined for one or more corresponding AP requesters. Access to the given data in the NVM is permitted or denied according to the AP policies defined for the AP requesters requesting access to given data.

[0010] This specification will be more fully understood from the following detailed description of embodiments thereof, taken in conjunction with the accompanying drawings, wherein: Attached Figure Description

[0011] Figure 1 This is a block diagram illustrating an electronic device that allows for secure and flexible NVM write operations, according to one embodiment disclosed herein.

[0012] Figure 2 This is a flowchart illustrating a method for write protection of NVM in an electronic device, according to an embodiment disclosed herein.

[0013] Figure 3 This is a schematic diagram illustrating a flexible multi-request NVM protection mapping according to one embodiment disclosed herein;

[0014] Figure 4 This is a schematic illustration of a flowchart of a method for allowing NVM write operations according to one embodiment disclosed herein;

[0015] Figure 5A block diagram illustrating an NVM write protection circuit in an NVM control circuit is shown schematically according to an embodiment disclosed herein; and

[0016] Figure 6 A block diagram of a computing system is schematically illustrated according to one embodiment disclosed herein. Detailed Implementation

[0017] Overview

[0018] Electronic devices, such as computing systems, sometimes include non-volatile memory (NVM), such as flash memory or electrically erasable programmable read-only memory (EEPROM), fuses, etc. NVM is typically used to store firmware, BIOS, or similar critical components, and must be protected from unauthorized write operations for several important reasons:

[0019] 1. Security and Integrity: Unauthorized access to NVM (especially modification) can compromise the security and integrity of the entire system. Malicious changes can introduce vulnerabilities, backdoors, or malware, which could be used to exploit the system, steal data, or disrupt operations.

[0020] 2. System Stability: NVM typically contains firmware or configuration data critical to the stable operation of hardware components. Unauthorized changes can lead to instability, crashes, or malfunctions, potentially rendering the system unusable or unreliable.

[0021] 3. Maintaining Authenticity: Ensuring that the NVM can only be modified by authorized personnel or processes helps maintain the authenticity of the firmware and software running on the system. This is crucial for verifying that the software loaded onto the processor is legitimate and has not been tampered with.

[0022] 4. Compliance and Standards: Many industries and regulatory bodies have requirements for protecting firmware and NVM. Compliance with standards such as the Payment Card Industry Data Security Standard (PCIDSS) or various government regulations typically requires strict control over who can modify critical system components.

[0023] 5. Data Protection: Some NVMs may store encryption keys or other sensitive data. Unauthorized modification could replace such keys, thereby compromising the security of the computer system.

[0024] To address these issues, processors typically employ hardware-based security mechanisms, such as an External Root of Trust (EROT) (or sometimes security circuitry within a Baseboard Management Controller (BMC) or Host Management Controller (HMC)). In such applications, one or more write request sources issue NVM access requests, and for an NVM write, the external circuitry releases the WP# signal (negative logic write protection, equivalent to positive logic no-write protection).

[0025] In such typical applications, trusted hardware circuitry (e.g., EROT, BMC, or HMC) authenticates NVM access requests and allows NVM write operations if a given set of security requirements are met. For example, EROT might allow writes to a predefined address range and prohibit writes to any other range; or, for another example, EROT might allow NVM write operations after verifying the signature of the written data. For brevity, the source of the NVM access request will sometimes be referred to as the requester below.

[0026] However, such conventional approaches may have limited functionality. For example, they do not support non-contiguous protected regions in NVM and do not allow multiple NVM write sources with different protection maps.

[0027] If additional circuitry is used to extend the functionality of the WP# signal, such as by adding support for non-contiguous address spaces, the system will be vulnerable to hacking; furthermore, in-line checking of addresses and / or data may slow down NVM write operations.

[0028] The embodiments described herein provide methods and systems for protecting an electronic device's NVM from unauthorized access (read or write). In these embodiments, non-contiguous write and read protected regions can be defined separately for each NVM access requester. Therefore, in these embodiments, the risk of external hacking attacks is reduced, with minimal or no impact on speed.

[0029] In one embodiment, the electronic device includes a processor and an NVM controller controlled by an internal root of trust circuit (IROT). The processor receives one or more NVM access requests from NVM access request sources (“requesters”) and, in response to an external NVM access request or an NVM read or write request initiated by the processor, sends an NVM read or write request to the NVM controller. The IROT is pre-configured (e.g., during system startup) with protection policies (also referred to as NVM protection policies) for one or more requesters. When the NVM controller receives an NVM access request from the processor, the NVM controller selects a read or write protection policy based on the requester and verifies whether the NVM access request complies with the selected protection policy; for write requests, the policy may include verifying whether the WP# signal is valid.

[0030] In this embodiment, external circuitry activates the WP# input to allow the relevant strategy to perform an NVM write. The write data, address, and possibly other parameters are provided by the processor.

[0031] In some embodiments, the protection policy may include one or more of the following: checking the requester's credentials, checking whether the read or write address is within the allowed range (for the current requester), verifying the data signature, checking whether the timer has expired, etc. In one embodiment, a separate set of NVM address ranges may be defined for each requester.

[0032] Therefore, in the embodiments described below, a flexible NVM write protection scheme can be defined and used for multiple requesters.

[0033] System Description

[0034] Electronic devices typically include non-volatile memory (NVM), such as flash memory, electrically erasable programmable read-only memory (EEPROM), fuse-only read-only memory (F-ROM), etc. For example, a network interface controller (NIC) may include flash memory for firmware (FW) storage and EEPROM for storing serial numbers and security keys. Embodiments disclosed below include circuitry that facilitates secure, hacker-resistant write operations to the NVM while allowing multiple requesters with different protection schemes, supporting non-contiguous protected NVM address spaces and hierarchical protection schemes. In some embodiments, the electronic device includes a network interface controller (NIC); in other embodiments, the electronic device may include a host channel adapter (HCA); and in still other embodiments, the electronic device may include various types of computer systems.

[0035] Figure 1 This is a schematic block diagram illustrating an electronic device 100 that allows for secure and flexible NVM write operations according to one embodiment disclosed herein. The electronic device includes non-volatile memory (NVM) 102.

[0036] according to Figure 1 In the exemplary embodiment shown, the NVM 102 is accessed only through the NVM controller 106, which authorizes NVM write operations according to a set of policies; thus, the risk of the NVM being maliciously or accidentally written to can be mitigated (in some embodiments, the NVM controller 106 handles NVM communication protocols, addressing and data transmission, error correction, loss equalization, voltage level conversion and other functions).

[0037] Multiple NVM write requesters 108 are connected to the processor 110 through multiple ports; for example, some requesters may send NVM write requests through one or more general purpose input / output (GPIO) ports of the processor; other requesters may use peripheral component interconnect fast (PCIe) ports, universal serial bus (USB) ports, inter-integrated circuit (I2C) ports, simplified media independent interface (RMII) ports, serial peripheral interface (SPI) ports, etc.

[0038] In some embodiments, processor 110 may include a central processing unit (CPU), a graphics processing unit (GPU), a data processing unit (DPU), or a group of processors that may be of the same or different types and have a reduced instruction set architecture (RISC), a complex instruction set architecture (CISC), or any other suitable architecture.

[0039] Multiple NVM write requesters send NVM write requests to the processor; in some embodiments, some or all requesters may issue a write address and write data; in other embodiments, the address and / or data may be directly provided to other circuitry of the electronic device 100, as will be described below. The processor 110 may read data from the NVM (e.g., to perform a filesystem function (FW) stored in the NVM) by sending an NVM read request to the NVM controller. In one embodiment, the read request includes a start address and a size indication; in response, the NVM controller issues one or more corresponding NVM read cycles to the NVM 102 via the NVM interface 104 and sends the read information back to the processor.

[0040] Electronic device 100 also includes an internal root of trust (IROT) circuitry 112, which is pre-configured to typically set protection configurations for individual NVM write and read requesters upon system reset. This configuration may include policy definitions (e.g., address range tables, valid WP# inputs, etc.) for each requester ID. In some embodiments, IROT 112 is part of NVM controller 106.

[0041] Whether the processor needs to write to the NVM or in response to an NVM write request received from a requester, the processor may also issue an NVM write request to the NVM controller. In an embodiment, the NVM write request sent by the processor to the NVM controller includes one or more of the following indications:

[0042] 1. Requester ID (NVM write requester ID from any of the 108 NVM write requesters, or the ID of the request initiated by the processor)

[0043] 2. Target NVM address (or address range).

[0044] 3. The data to be written.

[0045] 4. Timeout indicator, which specifies the time window during which NVM will open write operations.

[0046] The NVM controller receives NVM write requests from the processor, as well as WP# signals provided by the user (typically external to the electronic device). Depending on some selected protection policy, if the WP# signal is invalid, the NVM controller 106 will reject any NVM write request. If the WP# signal is valid, the NVM controller will select a protection policy from a predefined set of protection policies based on the requester ID, and accordingly allow or disable the NVM write request. For example, in one embodiment, the policy for NVM write requests initiated by the processor allows all access within a predefined address range; while the policy for requests received via the USB port first authenticates the data, then allows writing within a preset address range and a preset time window (hereinafter referred to as...). Figure 4 Other embodiments are provided.

[0047] Therefore, according to Figure 1 As shown in the exemplary configuration described above, all write operations to NVM are controlled by NVM controller 106, which is capable of providing individual protection policies based on the requester.

[0048] Figure 1 The configuration of the electronic device 100 shown and described above is referenced by way of example. Other configurations may be used in alternative embodiments. For example, in some embodiments, all NVM write requests are initiated by processor 110. In some embodiments, the address and / or data of the NVM write request are directly wired to the NVM interface (for some or all requesters). In one embodiment, there is no processor 110; instead, an external NVM access requester sends the request, address, and data lines to NVM controller 106.

[0049] Figure 2 This document schematically illustrates a flowchart 200 of a method for access protection of an NVM in an electronic device, according to one embodiment disclosed herein. The flowchart is constructed by an NVM controller 106 (…). Figure 1 )implement.

[0050] The flowchart begins with receiving an NVM access request operation 202, where the NVM controller receives an NVM access request, such as a write request or a read request, from a processor, for example. The NVM controller then proceeds to a policy selection operation 210 and selects an NVM protection policy based on the requester ID; in this embodiment, the NVM controller includes a policy table, which is configured by IROT 112 ( Figure 1 Pre-programmed. For example, in some cases, the table can specify that when the requester ID is an operating system, unrestricted NVM write operations are allowed to the lower half of the NVM; while when the request originates from a USB port, unrestricted NVM write operations are allowed to a limited area within the NVM within a preset time window (other policy examples will be referenced below). Figure 4 The above).

[0051] Next, at operation 212, the NVM controller checks whether the access request complies with the policy set for the requester ID. In some cases, to check policy compliance, the NVM controller requests an authentication service from the IROT; for example, when the policy includes a signature check. In the case of a write access request, the policy may include checking whether the WP# input is valid.

[0052] If, during operation 212, the access request does not comply with the selected policy, the NVM controller will enter NVM access denial operation 214 and reject the NVM access request (e.g., the NVM controller may send a signal to the processor that the request has been denied). In some embodiments, the NVM controller will also alarm the operating system (OS) operation 216, for example, using an interrupt input from the processor, alarming the OS that an unauthorized NVM access operation has been attempted. In one embodiment, the NVM controller may abort or reset the processor (and / or other circuitry of the electronic device).

[0053] If the access request complies with the selected policy in operation 212, the NVM controller enters the NVM access operation 218 and performs the requested NVM access.

[0054] The flowchart ends after operation 216 or operation 218 (or, if operation 216 does not exist, after operation 214).

[0055] Figure 2 The configuration of flowchart 200 shown and described above is referenced by way of example. Other flowcharts may be used in alternative embodiments. For example, in some embodiments, instead of sending a requester ID, the processor signals each request separately using dedicated request signals.

[0056] In this context, write protection and / or read protection are referred to herein as “access protection” (AP). In some embodiments, the NVM controller holds one or more AP policies (i.e., write protection policies and / or read protection policies) that are defined for one or more respective AP requesters. The NVM controller allows or denies access (reading and / or writing) to given data in the NVM based on the AP policies defined for the AP requesters requesting access to given data.

[0057] Figure 3 A block diagram of a flexible multi-request NVM protection map 300 is schematically illustrated according to one embodiment disclosed herein. Figure 3In the exemplary embodiment shown, the NVM includes 0x10000 addresses (65536 addresses), ranging from 0x0000 to 0xFFFF (other sizes may be used in alternative embodiments). In a given configuration of the electronic device, IROT112 ( Figure 1 The NVM controller 106 is pre-configured to support four NVM write requesters—requester A 304, requester B 306, requester C 308, and requester D 310 (any other suitable number of NVM write request sources may be used in alternative embodiments).

[0058] according to Figure 3 In the exemplary embodiment shown, the allowed NVM write address range for requester A 304 is 0x2000-0x2FFF and 0xB8000-0xF3FF; the address range for requester B 306 is 0x0400-0x23FF, 0x8000-0xAFFF and 0xB700-0xF2FF; the address range for requester C 308 is 0x3000-0xEFFF; and the address range for requester D 310 is 0x7000-0x9FFF and 0xB700-0xF2FF.

[0059] Therefore, according to Figure 3 As shown in the exemplary embodiments described above, separate sets of independent address ranges can be defined for multiple NVM write request sources.

[0060] Exemplary use cases

[0061] In this embodiment, multiple protection policies can be configured for multiple WP requesters. The following example describes an exemplary policy for firmware (FW) updates that relies on time constraints.

[0062] In an exemplary network interface controller (NIC), firmware (e.g., a bootloader) is stored in flash memory. The NIC vendor can provide firmware updates to some or all of the installed NICs. The vendor sends the new firmware, which will be written to the flash memory by the processor, over the internet.

[0063] Protection strategies in this scenario may include sender authentication (not part of this disclosure), verification of the new flash memory signature, and time limits. To load the new flash memory, the user needs to activate the WP# input (if the selected policy requires a valid WP#), and in response, the NVM controller checks the signature of the written data and then (if the signature is valid) opens the flash memory for the write operation for a limited duration defined by the protection policy timeout parameter. The actual data and address written will be provided by the processor.

[0064] Figure 4The flowchart 400 illustrates a method for allowing NVM write operations according to one embodiment disclosed herein. This flowchart is composed of NVM control circuitry 106 (… Figure 1 ) is executed, and was originally executed by IROT 112.

[0065] The flowchart begins with receiving configuration operation 402, where IROT 112 ( Figure 1 Configure the NVM control circuitry. In an embodiment, the IROT may define NVM write protection policies for one or more requesters.

[0066] After operation 402, the NVM control circuitry enters the NVM write request waiting operation 404 and waits for an NVM access request (e.g., from...). Figure 1 The processor 110).

[0067] In response to receiving an NVM write request (e.g., from processor 110), the NVM control circuitry (or, in an embodiment, IROT) enters the Authentication Requester operation 406 to authenticate the requester, for example, by checking the requester's signature (in this case, each requester sends an authentication code along with the request). If so, the NVM control circuitry enters the Selection Policy operation 408 (in some embodiments, it is assumed that the requester is trustworthy, and operation 406 is skipped).

[0068] At operation 408, the NVM control circuitry selects an NVM write protection policy based on the NVM write requester and the IROT's configured settings (as described in operation 402). The selected policy defines a set of tests that the request must pass to allow NVM writes. Flowchart 400 illustrates several such tests and operations, some of which can be skipped if not required by the selected policy. Skipped operations are referred to as optional operations, meaning the NVM control circuitry can proceed to that operation or the next operation.

[0069] After operation 408, the NVM control circuitry enters optional startup time window operation 410 to start a time window in which writes to the NVM from the current requester are permitted (this time window is only valid if the policy used for the current requester specifies an NVM write time limit).

[0070] Next, in the address and data receiving operation 412, the NVM control circuit receives the target address within the NVM and the NVM write data (e.g., from...). Figure 1 (Processor 110). In some embodiments, the NVM control circuitry may receive a starting address, followed by a continuous stream of data words to be written to consecutive NVM addresses; in other embodiments, the NVM control circuitry receives address / data pairs (or a single address and a single corresponding data word).

[0071] Together with the IROT, the NVM control circuitry now initiates a series of optional check operations based on the selected policy. At the optional WP# validity check operation 413, the NVM control circuitry checks whether the WP# input is valid; at the subsequent (optional) requester credential check operation 414, the NVM control circuitry requests the IROT to check whether the requester's credentials conform to the credentials defined in the selected policy; at the optional subsequent address check operation 416, the NVM control circuitry checks whether the NVM write address (provided in operation 412) is within the list of NVM write approval address ranges defined for the selected policy; and at the time window check operation 418, the NVM control circuitry checks whether the time window (initiated in operation 410) has expired.

[0072] If all operations 406, 413, 414, 416, and 418 are successful or have been skipped, the NVM control circuitry enters NVM access operation 422 and accesses the NVM at the specified address to perform a read or write operation. If any of operations 406, 413, 414, 416, or 418 fails, the NVM control circuitry enters abort NVM write operation 424 and aborts the NVM write request; the flowchart then ends (in some embodiments, operation 424 may reset the electronic device; in other embodiments, it will alert the operating system).

[0073] After operation 422, the NVM control circuitry returns to operation 404 to wait for the next NVM write request.

[0074] In short, according to Figure 4 In the exemplary embodiment shown, in response to an NVM write request sent by the processor, the NVM control circuit authenticates the requester (if necessary) together with the IROT, selects a protection policy based on the requester, and then continues to perform a series of checks and tests according to that policy. The NVM control circuit will only perform the requested NVM write operation if all tests are successful or unnecessary (i.e., skipped).

[0075] Figure 4 The operations of flowchart 400 shown and described above are referenced by way of example. Other flowcharts may be used in alternative embodiments. For example, in an embodiment, the order of operations 413, 414, 416, and 418 may be changed. In some embodiments, some or all of the test operations 413 to 418 may be performed simultaneously. In one embodiment, the NVM control circuitry performs operations 412 and 413 while still receiving NVM write data.

[0076] Figure 5This is a schematic block diagram illustrating an NVM write protection circuit 500 in an NVM control circuit according to embodiments disclosed herein. The NVM write protection circuit receives multiple write NVM requests from multiple NVM write requesters, and a single WP# signal for allowing NVM write operations. In an embodiment, some or all of the write NVM requests are received from processor 110 (… Figure 1 The write NVM request is input to the policy selection circuit 504, which is configured to store multiple write protection policies for each requester. In one embodiment, the policy selection circuit is controlled by IROT 112 ( Figure 1 Preloading; in embodiments where IROT is part of the NVM controller, the policy is stored in the policy storage circuitry within the NVM controller.

[0077] The strategy selection circuit selects the protection strategy configured by the IROT for the active requester. According to... Figure 5 The exemplary embodiment shown may include checking the NVM write address, NVM source authentication, public key data authentication, and checking the expiration time.

[0078] If the selected protection policy includes address-based protection, the policy selection circuit sends an enable signal and a table selection signal to the address protection circuit 506. In one embodiment, the address protection circuit may include protection tables for one or more requesters; these tables are preloaded (e.g., by...). Figure 1 (IROT 112). The table selection signal selects a table based on the requester's selection, and the address protection circuit 506 enables NVM writing only if the NVM write address points to an allowed region within the NVM (or, if the address comparison circuit is not enabled). For example, for a first given requester, the table may specify a protected address range from 0x0000 to 0x7FFF, while for a second given requester, the table may specify any address greater than or equal to 0xA000 and less than 0xAFFFF as protected.

[0079] If the selected protection strategy includes checking the WP# input, the strategy selection circuit sends an enable signal to the WP# checking circuit 507, which is configured to enable write NVM operation if the enable signal and the WP# input are valid.

[0080] If the selected protection policy includes signature authentication, IROT authenticates the signature and sends a signature authentication success (OK) signal if authentication is successful (or if the selected policy does not require signature authentication). Similarly, if the selected protection policy includes public key authentication, IROT authenticates the requester using a preset public key and sends a public key authentication success (OK) signal if public key authentication is successful (or if the selected policy does not require public key authentication).

[0081] Finally, if the selected protection strategy includes a time limit, the strategy selection circuit sends an enable signal and a time limit value (according to the requester) to the timer circuit 512, which will count clock pulses and enable NVM writing only if the elapsed time (e.g., from the start of enable signal activation) has not exceeded the specified time limit (or if the timer circuit is not enabled).

[0082] Then, if (i) the output of the address protection circuit 506 is logic high, (ii) the WP# check circuit 507 enables the write NVM operation, (iii) the signature authentication success signal is logic high, (iv) the PK authentication success signal is logic high, and (v) the output signal of the timer circuit 512 is logic high, then the AND gate 514 activates the write NVM enable signal.

[0083] according to Figure 5 In the exemplary embodiment shown, the IROT always authenticates the signature and / or PK; the NVM controller uses the authentication result only when needed (depending on the selected policy). In some alternative embodiments, the NVM controller requests the IROT to authenticate the signature and / or PK if the policy requires such authentication.

[0084] Figure 5 The configuration of the NVM write protection circuit 500 shown and described above is referenced by way of example. Other configurations may be used in alternative embodiments. For example, in some embodiments, other circuitry that authorizes NVM write operations may be used as an alternative to or supplement to circuits 506, 508, 510, and 512.

[0085] It should be noted that the NVM write protection circuit 500 only includes circuitry for protecting NVM write operations. In some embodiments, the NVM controller also includes NVM read protection, and the NVM write protection circuit 500 is extended accordingly.

[0086] Figures 1 to 4 The configurations of the electronic device 100, the NVM write protection circuitry 500 (including any subsystems thereof), the structure of the NVM protection map 300, the operation of flowchart 400, and the methods of flowchart 200 shown and described herein are exemplary configurations, flowcharts, and NVM protection maps depicted merely for conceptual clarity. Any other suitable configurations, flowcharts, and NVM protection maps may be used in alternative embodiments. The electronic device and its components may be implemented using suitable hardware (e.g., in one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs), software, or a combination of hardware and software elements.

[0087] In some embodiments, processor 110 includes a general-purpose programmable processor that is software-programmed to perform the functions described herein. This software may be downloaded to the processor electronically, for example, via a network, or alternatively or additionally, may be provided and / or stored on a non-transitory tangible medium, such as magnetic, optical, or electronic memory.

[0088] In embodiments, electronic device 100 (including any of its components) may be implemented using one or more general-purpose programmable processors, which are software-programmed to perform the functions described herein. This software may be downloaded to the processor electronically, for example, via a network, or alternatively or additionally, may be provided and / or stored on a non-transitory tangible medium, such as magnetic, optical, or electronic memory.

[0089] Exemplary computing system applications

[0090] Figure 6 This is a schematic diagram illustrating a block diagram of a computing system 1000 (e.g., a data center or high-performance computing (HPC) cluster) according to one embodiment described herein. According to at least one embodiment, system 1000 includes multiple subsystems, such as multiple processing devices, multiple network devices, and multiple networks coupled to each other. The computing system 1000 is designed to have multiple integrated circuits (referred to as processing devices), wherein each integrated circuit may include one or more CPUs and GPUs, forming a powerful and flexible architecture.

[0091] Various processing devices are interconnected via NVLink or other high-speed interconnects to enable high-speed communication between subsystems; at the same time, these processing devices are also connected via NIC or DPU to ensure efficient data transmission on the computing system 1000 and with one or more external networks 1030, 1036.

[0092] NVLink coupling of the processing device enables seamless data exchange and parallel processing, thereby improving overall computing performance. The processing device connects to multiple networks via one or more NICs or DPUs, enabling the system to handle complex multi-network tasks with high bandwidth and low latency. This configuration is ideal for demanding applications requiring powerful processing capabilities, such as artificial intelligence (AI), machine learning (ML), and data-intensive computing, while ensuring robust connectivity and scalability across diverse network environments. The integrated circuits of the Computing System 1000 may include one or more CPUs and one or more GPUs.

[0093] Figure 6An exemplary architecture of a multi-GPU architecture is also illustrated. As shown in the figure, computing system 1000 includes a processing device 1002 with a multi-GPU architecture. Specifically, processing device 1002 may be a system-on-a-chip and includes multiple subsystems such as CPU 1006, GPU 1008, and GPU 1010. CPU 1006 may be coupled to GPU 1008 via die-to-die (D2D) or chip-to-chip (C2C) interconnects 1012, such as ground reference signal interconnects (GRS interconnects). CPU 1006 may be coupled to GPU 1010 via D2D or C2C interconnects 1014. CPU 1006 may also be coupled to GPU 1008 and GPU 1010 via PCIe interconnects.

[0094] The CPU 1006 can be coupled to one or more NICs or DPUs, which in turn are coupled to one or more networks. For example, as Figure 6 As shown, CPU 1006 is coupled to a first NIC / DPU 1026, which is coupled to network 1030. CPU 1006 is also coupled to a second NIC / DPU 1028, which is coupled to network 1030. For example, NIC / DPU 1026 and NIC / DPU 1028 can be coupled to network 1030 via Ethernet (ETH), NVLINK, or Infinite Bandwidth (IB) connections.

[0095] The computing system 1000 also includes a processing device 1004 with a multi-GPU architecture. Specifically, the processing device 1004 includes multiple subsystems, including a CPU 1016, a GPU 1018, and a GPU 1020. The CPU 1016 can be coupled to the GPU 1018 via a D2D or C2C interconnect 1022. The CPU 1016 can be coupled to the GPU 1020 via a D2D or C2C interconnect 1024. The CPU 1016 can also be coupled to the GPU 1018 and GPU 1020 via a PCIe interconnect. The CPU 1016 can be coupled to one or more NICs or DPUs, which are coupled to one or more networks. For example, as... Figure 6 As shown, CPU 1016 is coupled to a first NIC / DPU 1032, which is coupled to network 1036. CPU 1016 is also coupled to a second NIC / DPU 1034, which is coupled to network 1036. NIC / DPU 1032 and NIC / DPU 1034 can be coupled to network 1036 via Ethernet (ETH), NVLINK, or Infinite Bandwidth (IB) connections.

[0096] In at least one embodiment, processing device 1002 and processing device 1004 can communicate with each other via NIC / DPU 1038, such as via PCIe interconnect. Processing device 1002 and processing device 1004 can also communicate with each other via high-bandwidth communication interconnect 1040, such as NVLink interconnect or other high-speed interconnect.

[0097] In various embodiments, the system 1000 and / or any of its components (e.g., superchip, NIC / DPU and / or individual CPUs or GPUs) and network devices such as packet switches (not shown in the figures) may employ the disclosed technologies.

[0098] It should be understood that the above embodiments are cited by way of example, and the invention is not limited to the specific content shown and described above. Rather, the scope of the invention includes combinations and sub-combinations of the various features described herein, as well as variations and modifications thereof that would occur to those skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.

Claims

1. An electronic device, comprising: A memory interface for communicating with non-volatile memory (NVM); as well as An NVM controller, the NVM controller being used for: Manage the reading and writing of data in the NVM; Save one or more write-protected WP policies, which are defined for one or more corresponding WP requesters; Receive WP instruction; as well as The WP policy defined by the WP requester for writing the given data allows or denies writing the given data to the NVM, and the WP policy depends at least on the WP indication.

2. The electronic device of claim 1, further comprising one or more processors, said one or more processors for requesting access to the NVM.

3. The electronic device of claim 1, wherein the WP policy specifies that a protected set of addresses is written to it in the NVM.

4. The electronic device of claim 3, wherein the address set is non-contiguous.

5. The electronic device of claim 1, wherein the one or more WP strategies include: The first WP policy, which is defined for the first WP requester, specifies that a protected first set of addresses is written to it in the NVM; as well as The second WP strategy is defined for the second WP requester, which specifies that the NVM writes a protected second set of addresses to it, which is different from the first set of addresses.

6. The electronic device according to claim 1, wherein, The NVM controller is used to authenticate the identity of the WP requester according to the WP policy.

7. The electronic device according to claim 1, wherein, The NVM controller is used to authenticate write data constrained by the WP policy according to the WP policy.

8. An electronic device, comprising: A memory interface for communicating with non-volatile memory (NVM); as well as An NVM controller, the NVM controller being used for: Manage the reading and writing of data in the NVM; Store one or more access protection AP policies, which are defined for one or more corresponding AP requesters; as well as Based on the AP policy defined for the AP requester requesting access to the given data, allow or deny access to the given data in the NVM.

9. A method for write protection (WP) for non-volatile memory (NVM), the method comprising: Save as one or more WP policies defined by one or more corresponding WP requesters; Receive WP instruction; as well as The WP policy defined by the WP requester for writing the given data allows or denies writing the given data to the NVM, and the WP policy depends at least on the WP indication.

10. The method of claim 9, further comprising: Receive requests to access the NVM from one or more processors.

11. The method of claim 9, wherein the WP policy specifies that a protected set of addresses is written to the NVM.

12. The method of claim 11, wherein the address set is non-contiguous.

13. The method of claim 9, wherein the one or more WP strategies comprise: The first WP policy, which is defined for the first WP requester, specifies that a protected first set of addresses is written to it in the NVM; as well as The second WP strategy is defined for the second WP requester, which specifies that the NVM writes a protected second set of addresses to it, which is different from the first set of addresses.

14. The method of claim 9, further comprising: The identity of the WP requester is authenticated according to the WP policy.

15. The method of claim 9, further comprising: According to the WP policy, authenticate the write data that is constrained by the WP policy.

16. A method for an access protection AP for non-volatile memory (NVM), the method comprising: Save as one or more AP policies defined by one or more corresponding AP requesters; as well as Based on the AP policy defined for the AP requester requesting access to the given data, allow or deny access to the given data in the NVM.

Images