214 may encrypt data that is written to the FeRAM memory device 228 but may not encrypt the data that is written to the volatile memory device (e.g., DRAM memory device 226). In the alternative, in some embodiments, the security component 214 may encrypt data that is written to the volatile memory device (e.g., DRAM memory device 226) and may not encrypt data that is written to the FeRAM memory device 228. The data written to the FeRAM memory device 228 may be encrypted because the FeRAM memory device 228 can have security deficiencies that the DRAM memory device 226 does not have. The security component 214 can be bypassed when it is not used. In some embodiments, the security component 214 can be enabled or disabled. For example, the security component 214 can be enabled when writing memory to a persistent memory device, such as an FeRAM memory device 228.

As shown in FIG. 2, the central controller portion 210 can include error correction code (ECC) circuitry to ECC encode the data and ECC decode the data. In some embodiments, the memory controller 210 can implement low power chip kill (LPCK) error correction. As used herein, the term “chip kill” generally refers to a form of error correction that protects memory systems (e.g., the memory system 101 shown in FIG. 1) from any single memory chip failure as well as multi-bit error from any portion of a single memory chip. One approach for chip kill protection is on-the-fly correction implementation. On-the-fly correction can form a plurality of codewords out of four (4)-bit symbols of each of a plurality of die (e.g., memory chip). For example, if there are eleven (11) die each containing 4 separate bit symbols, with each bit symbol containing 4 bits, the 11 die can form 4codewords each with 11 separate bit symbols comprising a total of forty four (44) bits per codeword.

In some embodiments, a first codeword can comprise the first bit symbol of each die, a second codeword can comprise the second bit symbol of each die, a third codeword can comprise the third bit symbol of each die, and a fourth codeword can comprise the fourth bit symbol of each die. In other words, the eight data bit symbols and 3 parity bit symbols of a codeword can be stored in eleven (11) die. Eight (8) of the 11 die can contain data bit symbols and the three (3) remaining die of the 11 die can contain parity bit symbols. Adding 3 parity bit symbols can allow the central controller portion 210 to correct up to one symbol error in each codeword and to detect up to two symbol errors. If instead of adding 3 parity bit symbols, only two (2) parity bits are added, the central controller portion 210 can correct up to one symbol error but only detect one symbol error. In some embodiments, the data bit symbols and the parity bit symbols can be written or read concurrently from the 11 die by the ECC encoding circuitry 216 and the ECC decoding circuitry 218. If every bit symbol in a die fails, only the bit symbols from that die in the codeword will fail. This allows memory contents to be reconstructed despite the complete failure of one die.

As shown in FIG. 2, the memory controller 200 can include a back end portion 219, including a media controller portion 220 comprising a plurality of media controllers and a physical (PHY) layer portion 222 comprising a plurality of PHY layers 224-1, 224-2, 224-N, . . . , 224-(N+1) (individually or collectively referred to as PHY layer 224). In some embodiments, the back end portion 219 is configured to couple the PHY layer portion 222 to a plurality of memory ranks 230-1, . . . , 230-N (individually or collectively referred to as memory ranks 230) of a first memory device 226 and a plurality of memory ranks 232-1, . . . , 232-M (individually or collectively referred to as memory ranks 232) of a second memory device 228-1, . . . , 228-N (individually or collectively referred to as second memory device 228). The media controller 220 can operate following both open-page policies and a closed-page policies. As used herein, the term “open-page policy” generally refers to a policy which allows a memory controller (e.g., media controller 220) to leave a page of memory open for a certain amount of time after a read operation or a write operation is performed. As used herein, the term “closed-page policy” generally refers to a policy that ensures that a page of memory is closed immediately after a read operation or a write operation is performed. In some embodiments, as a non-limiting example, the FeRAM memory device 228 can implement a closed-page policy with an additional requirement that the tRAS of the FeRAM memory device 228 is less than five hundred (500) ns.

In embodiments where LPCK error correction is used, the media controller portion 220 can be a single media controller 220. When implementing LPCK error correction, a plurality of channels 225-1, 225-2, 225-N, . . . , 225-(N+1) (individually or collectively referred to as the plurality of channels 225) can be driven concurrently to write data to the DRAM memory device 226 and/or the FeRAM memory device 228. In some embodiments, instead of using a single media controller 220, multiple media controllers can be used to drive the plurality of channels 225 in the LPCK architecture. When multiple media controllers are used to drive the channels 225 concurrently, the media controllers are utilized substantially simultaneously.

As used herein, the term “substantially” intends that the characteristic needs not be absolute, but is close enough so as to achieve the advantages of the characteristic. For example, “substantially simultaneously” is not limited to operations that are performed absolutely simultaneously and can include timings that are intended to be simultaneous but due to manufacturing limitations may not be precisely simultaneously. For example, due to read/write delays that may be exhibited by various interfaces (e.g., LPDDR5 vs. PCIe), media controllers that are utilized “substantially simultaneously” may not start or finish at exactly the same time. For example, the multiple memory controllers can be utilized such that they are writing data to the memory devices at the same time regardless if one of the media controllers commences or terminates prior to the other.

Each of the plurality of media controllers can receive a same command and address and drive the plurality of channels 225 substantially simultaneously. By using the same command and address for the plurality of media controllers, each of the plurality of media controllers can utilize the plurality of channels 225 to perform the same memory operation on the same plurality memory cells.

A back end portion 222 can include multiple PHY layers 224 and the media controller portion 220 that is configured to drive the channels 225 that couple PHY layers 224 to the memory ranks 230, 232. In some embodiments, the memory ranks 230, 232 can be DRAM memory ranks 230 and/or FeRAM memory ranks 232. In some embodiments, as a non-limiting example, the memory controller 200 can be coupled to the memory ranks 230, 232 through channels 225 coupled to the back end portion 219 and each of the channels 225 is coupled to four (4) memory ranks 230, 232.

The memory controller 200 can include a management unit 234 configured to initialize, configure, and/or monitor characteristics of the memory controller 200. Further, the management unit 234 can be used to execute non-memory functions. Such examples can include logging, error reporting, support of discovery by the host, security protocols management, security functions, etc. In some embodiments, the management unit 234 includes an I/O bus 238 to manage out-of-band data and/or commands, a management unit controller 240 to execute instructions associated with initializing, configuring, and/or monitoring the characteristics of the memory controller 200, and a management unit memory 242 to store codes and/or data associated with managing and/or monitoring the characteristics of the memory controller 200. An endpoint of the management unit 234 can be exposed to the host system (e.g., the host 103 shown in FIG. 1) to manage data. In some embodiments, the characteristics monitored by the management unit 234 can include a voltage supplied to the memory controller 200 or a temperature measured by external sensors, or both. Further, the management unit 234 can include an advanced high-performance bus (AHB) interconnect 236 to couple different components of the management unit 234. However, embodiments are not so limited and the management unit 234 can include other interconnects to couple the different components of the management unit 234.

As stated above, the I/O bus 238 can be configured to transfer out-of-band data and/or commands. In some embodiments, the I/O bus 238 can be a System Management Bus (SMBus). As used herein, the term “SMBus” generally refers to a single-ended simple two-wire bus for the purpose of lightweight communication. Further, the management unit 234 can include circuitry to manage in-band data. As used herein, the term “in-band signaling” generally refers to a method for signaling events and conditions using the Link between two components, as opposed to the use of separate physical (sideband) signals. Mechanisms defined herein can be implemented using in-band signaling, although in some form factors sideband signaling may be used, in the alternative.

The management unit 234 can include a management unit controller 240. In some embodiments, the management unit controller 240 can be a microcontroller that meets the Joint Test Action Group (JTAG) standard and capable, among other things, to run according to an Inter-Integrate Circuit (I²C or I³C) protocol, and auxiliary I/O circuitry. As used herein, the term “JTAG” generally refers to an industry standard for verifying designs and testing printed circuity boards after manufacture. As used herein, the term “I2C” generally refers to a serial protocol for a two-wire interface to connect low-speed devices like microcontrollers, I/O interfaces, and other similar peripherals in embedded systems. In some embodiments, the auxiliary I/O circuitry can couple the management unit 234 to the memory controller 200. Further, firmware for operating the management unit can be stored in the management unit memory 242. In some embodiments, the management unit memory 242 can be a flash memory such as flash NOR memory or other persistent flash memory device.

FIG. 3A illustrates a block diagram in the form of another controller 300 for managing multiple types of memory in accordance with a number of embodiments of the present disclosure. A memory controller 300 is configured to manage a dynamic random access memory (DRAM) memory device 326-1, . . . , 326-N (individually or collectively referred to as DRAM memory device 326) having a first row address strobe timing (tRAS) and a ferroelectric random access memory (FeRAM) memory device 328-1, . . . , 328-N (individually or collectively referred to as FeRAM memory device 328) having a second tRAS. Further, in some embodiments, instead of managing both a DRAM memory device 326 and a FeRAM memory device 328, the memory controller 300 can be configured to manage either just DRAM memory devices 326 or just FeRAM memory devices 328. As shown in FIG. 3A, the memory controller 300 can include a front end portion 304, a central controller 310, and a back end portion 319.

As shown in FIG. 3A, the front end portion 304 can include an interface 306 that includes multiple I/O lanes 302-1, 302-2, . . . , 302-N (individually or collectively referred to as I/O lanes 302) and a controller 308 to manage the interface 306. In some embodiments the quantity of I/O lanes 302 can be eight (8) I/O lanes and in other embodiments, the quantity of I/O lanes 302 can be sixteen (16) I/O lanes. Increasing the amount of I/O lanes 302 can increase the amount of data transferred to and from the memory controller 300. In some embodiments, the I/O lanes are configured to transfer access requests to or from circuitry external to the memory controller at a rate of at least thirty-two (32) gigatransfers per second (GT/s). More specifically, each of the I/O lanes can be configured to transfer the requests at a rate of at least 32 GT/s. Therefore, increasing the number of I/O lanes can increase the amount of data written per second. Further, in some embodiments, the I/O lanes can be configured to transfer access requests to or from circuitry external to the memory controller according to a compute express link protocol.

As shown in FIG. 3A, a central controller 310 that can cause performance of a read operation or a write operation, or both can include a cache memory 312 to store data associated with the read operation or write operation, or both, and increase an efficiency of accessing the data. The cache memory 312 can be used to store data received from the host and write the stored data to the DRAM memory device 326 and/or the FeRAM memory device 328. In some embodiments, the cache memory 312 can increase the efficiency of accessing the data by allowing the FeRAM memory device 328 to receive data in 64 byte blocks. A CXL memory system (e.g., memory system 300) can request data at a granularity of 64 bytes but the data may be accessed at a granularity of 128 bytes, 256 bytes, or 512 bytes, among other non-limiting examples. Storing data in the cache memory 312 can allow the FeRAM memory device 328 to access data in 64 byte chunks because the cache memory 312 can send data in 64 byte chunks. Use of the cache memory 312 can also increase the efficiency of the memory system because the cache memory 312 can prefetch the data and store the data in multiple 64 byte blocks in the case of a cache miss. This can increase the efficiency of the CXL memory system because, instead of searching a separate memory device in the event of a cache miss, the data can be read from the cache memory 312 because the data was prefetched by the cache memory 312. Less time and energy may be used accessing the prefetched data than would be used if the memory system has to search for the data before accessing the data.

As shown in FIG. 3A, the central controller 310 can include a security component 314 to encrypt the data before storing the data in the DRAM memory device 326 or the FeRAM memory device 328 and decrypt the data before the data is transferred to the host from the DRAM 326 memory device or the FeRAM memory device 328. In some examples, the data can be encrypted by the security component 314 prior to being stored in the cache 312 or, in the alternative, the data can be encrypted by the security component 314 after being retrieved from the cache memory 312 and prior to being written to the DRAM memory device 326 or FeRAM memory device 328. As stated above, the security component 314 can encrypt the data using AES encryption. In some embodiments, the data can bypass the security component 314 and avoid encryption. For example, when data is written from the host to the DRAM memory device 326, the data can bypass the security component 314 and be written into the DRAM memory device 326 as unencrypted data. The data can bypass the security component when being written to the DRAM memory device 326 because the DRAM memory device 326 may not have the same vulnerabilities as the FeRAM memory device 328. This can increase the efficiency of a CXL memory system because bypassing the security component 314 can decrease the power consumed and/or the time used to transfer data. Therefore, by engaging the security component 314 in circumstances when the security component 314 provides a more significant benefit and bypassing the security component 314 in circumstances where the security component 314 provides a less significant benefit, the efficiency of the memory system will increase.

As shown in FIG. 3A, the central controller 310 can include ECC encoding circuitry 316-1, 316-2, 316-N, . . . , 316-(N+1) (individually or collectively referred to as ECC encoding circuitry 316) to ECC encode the data and ECC decoding circuitry 318-1, 318-2, 318-N, . . . , 318-(N+1) (individually or collectively referred to as ECC decoding circuitry 318) to ECC decode the data. In some embodiments, the central controller 310 can also include a plurality of redundant array of independent disks (RAID) components 344-1, 344-2, 344-N, . . . , 344-(N+1) (individually or collectively referred to as RAID components 344) to store the data. However, embodiments are not so limited and some embodiments may not include the RAID components. As used herein, the term “RAID components” generally refers to data storage virtualization technology that combines multiple physical disk drive components into one or more logical units for the purposes of data redundancy, performance improvement, or both.

Each of the RAID components 344 can be coupled to different ECC encoding circuitry 316 and ECC decoding circuitry 318. In some embodiments, each of the RAID components 344 can correspond to one of the media controllers 321-1, 321-2, 321-N, . . . , 321-(N-+1) (individually or collectively referred to as media controllers 321). This allows a separate RAID component 344 and a separate media controller 321 to be dedicated to each of the channels 325-1, 325-2, . . . , 325-N, 325-(N+1). A RAID state machine can implement the functionality of the RAID components 344. By dedicating a separate RAID component 344 and a separate media controller 321 to each channel 325, each channel 325 can be driven individually and receive a separate command and address than other channels 325. In some embodiments, each media controller 321 executes commands independently of the other media controllers 321. This RAID architecture can provide more flexibility to the memory system in regard to how much data is written to a memory device 326, 328 and when the data is written to a memory device 326, 328 in comparison to the LPCK architecture. In some embodiments, a RAID component 344 can be striped across multiple channels 325. If a RAID component 344 is striped across multiple channels 325, a RAID state machine can be shared across multiple channels 325. This allows a RAID component 344 to drive a plurality of channels 325 substantially simultaneously. As described above, the RAID components 344 may be optional and some embodiments can function without the RAID components 344.

As shown in FIG. 3A, the memory controller portion 300 can include a back end portion 319 including a media controller portion 320 comprising a plurality of media controllers 321 and a physical (PHY) layer portion 322 comprising a plurality of PHY layers 324-1, 324-2, . . . , 324-N+1 (individually or collectively referred to as PHY layers 324), wherein the back end portion 319 is configured to couple the PHY layer portion 322 to a plurality of memory ranks. In some embodiments, the memory ranks can include DRAM memory ranks 330-1, . . . , 330-N (individually or collectively referred to as DRAM memory ranks 330) and

FeRAM memory ranks 332-1, . . . , 332-M (individually or collectively referred to as FeRAM memory ranks 332). Further, in some embodiments, the memory ranks can include just DRAM memory ranks 330 or just FeRAM memory ranks 332. In some embodiments, the back end portion 319 can be connected to the plurality of memory ranks 330, 332 through the plurality of channels 325 and each of the plurality of channels 325 is coupled to memory ranks 330, 332 in a range of one (1) to eight (8) memory ranks 330, 332. In some embodiments, each of the plurality of channels 325 is coupled to five (5) memory ranks.

As stated above, each media controller 321 can correspond to a RAID component 344, as well as ECC encoding circuitry 316 and ECC decoding circuitry 318. As described above, the RAID components, in some embodiments, may be optional. Each media controller 321 can also correspond to one of the plurality of PHY layers 324. Each PHY layer 324 can be coupled to a DRAM memory device 326 or a FeRAM memory device 328 through a channel 325. In some embodiments, each media controller 321 can execute commands independent of the other media controllers 321. Therefore, data can be transferred from a PHY layer 324 through a channel 325 to a memory device 326, 328 independent of other PHY layers 324 and channels 325.

As shown in FIG. 3A, the memory controller 300 can include a management unit 334 configured to initialize, configure, and/or monitor a plurality of characteristics of the memory controller 300. Further, the management unit 334 can be used to execute non-memory functions. Such examples can include logging, error reporting, support of discovery by the host, security protocols management, security functions, etc. The management unit 334 can include an I/O bus 339 to transfer out-of-band data and/or commands, a processor (e.g., “controller”) 340 to execute instructions associated with initializing, configuring, and/or monitoring characteristics of the memory controller 300, and a management unit memory 342 to store codes and data associated with managing and/or monitoring the characteristics of the memory controller 300. The characteristics of the memory controller 300 that the management unit 334 can monitor can include, but are not limited to, the amount of voltage being applied to the memory controller 300 and the temperature of the memory controller 300.

FIG. 3B illustrates a block diagram in the form of a memory controller 300 including a security component 314 for security management of a ferroelectric memory device in accordance with a number of embodiments of the present disclosure. The memory controller 300 can include a front end portion 304 (such as front end portion 104, 204, and 304 in FIGS. 1, 2, and 3A, respectively), a central controller 310 (such as central controller 110, 210, and 310 in FIGS. 1, 2, and 3A, respectively), and a back end portion 319 (such as back end portion 119, 219, and 319 in FIGS. 1, 2, and 3A, respectively). The front end portion 304 can be connected to the central controller 312 through an interconnect 336-1. The central controller 310 can be connected to the back end portion 319 through an interconnect 336-2. Further, an interconnect 336-3 can connect a cache controller 332 of the cache 312 to the encryption core 337 of the security component 314 and an interconnect 336-4 can connect the cache controller 332 to the decryption core 338 of the security component 314.

The cache 312 can include a write buffer 331, a cache controller 332, and an array 334. The cache controller 332 can include a core 333 and an interface 335. The interface 335 can be a cache interface and a cache telemetry component. Data can be received from a host to the front end 304 and be transferred to the cache 312 through the interconnect 336-1. The data can be transferred through the core 333 to the write buffer 331 and back to the core 333. Data can also be transferred to the array 334 of the cache 312. The cache controller 332 can send data to the encryption core 337 of the security component 314 through the interconnect 336-3 or receive data from the decryption core 338 of the security component 314 through the interconnect 336-4.

The persistent data sent through the core 333 can be protected based on an AES, such as AES-XTS 256 protocol. In the example where the data is encrypted after being received from the cache, the protection can be applied on a single cache line basis, however embodiments are not so limited. The AES-XTS encryption can be enabled and/or disabled based on security preferences as Low Power Double Data Rate 5 (LPDDR5) protocol may not require data at-rest protection. Further, an operating system hypervisor of the host can partition memory with unique per-virtual machine (VM) encryption keys in order to ensure data is confidential between VMs. While the descriptions herein include data encryption through AES including CXL module implementations based on non-volatile memories, embodiments are not so limited and may include implementations based on persistent memories.

Examples of security operations can include a MemInv operation that includes encrypting new metadata states, a MemRd operation that includes decrypting addressed data and encrypting new metadata states (if Meta0=S), a MemRdData operation that includes decrypting addressed data, a MemSpecRd operation that includes decrypting addressed data and encrypting new metadata states (if Meta0=S) when executed, and a MemWr operation that includes encrypting addressed data and new metadata states. The cache 312, security component 314, and RAID/ECC component 315 can be used to perform these security operations. Data bandwidth to and from the encryption core 337 and decryption core 338 can be a 32 gigabit (GB) per second bandwidth, including to and from the RAID component 344 from the security component 314. While embodiments are described as including the RAID component 344, embodiments are not so limited and some embodiments may not include the RAID component 344 as the RAID component may be optional.

In some embodiments, the firmwares and bootloaders of the memory system 300 can be digitally signed and can be verified during a download process before being programmed in the non-volatile memory device where the firmware and bootloader are stored. This can prevent the introduction of malware onto memory system which could be used to circumvent the security features of the memory device. Firmware downloads can be in-band, or use a standard interface as opposed to a sideband or out-of-band channel, and based on CXL device commands (c.g., Get FW Info, Transfer FW, and Activate FW). An in-band channel can refer to a channel connecting the device and the main host. An out-of-band (OOB) channel can refer to a channel connecting the device and support host system (e.g., BMC). A side-band channel is an interface on the device to implement the OOB channel. The boot loader and main firmware can be signed using a Rivest-Shamir-Adleman (RSA) operation. Firmware can support security version checking-used for anti-rollback protection. The security version of the boot loader and main firmware can be stored on the memory device and can be considered a public security parameter, as it specifies the highest security version of firmware installed on the memory device. The security measures of a bootloader (FIG. 4) and a firmware image (FIG. 5) will be further described below.

In some embodiments, a sideband interface, such as a JTAG, can be used. In some examples, a JTAG debug interface can be used when communicating with a CPU. This can allow inspection of any IP mapped in the CPU address space. However, there is a risk that through this setup it may be possible to reach memory areas that contain critical data. Therefore, this JTAG interface may need to be disabled by means of a specific mechanism. The specific mechanism can be able to switch between two states (e.g., JTAG enabled and JTAG disabled) in a finite number of times. This can mitigate errors that may occur in the production process of the memory device. The transition between one of the two states may take place under controlled conditions (e.g., specific laboratory or production lines) and done so exclusively by those authorized to do so. In some examples, the JTAG interface may be permanently disabled once the memory device is ready to leave the production process.

In some examples, the JTAG interface switch could be based on a set of One Time Programmable (OTP) bits whose overall logic state, through a combinatorial logic network, outputs a single status bit which encodes the status of enabled or disabled for the JTAG interface. As an example, as illustrated in Table 1, an OTP bit status can indicate a corresponding JTAG status:

TABLE 1

OTP bits status
JTAG status

000
Enabled

001
Disabled

011
Enabled

111
Disabled

Since OTPs can only switch states once, other state combinations are not significant. For example, starting from state 011, having following sequence 000 to 001 to 011, it may not be possible to reach state 101.

In some embodiments, a serial port based interface (e.g., a sideband interface such as a Universal Asynchronous Receiver/Transmitter (UART)) is used for ROM monitoring, such as issuing commands to the memory system for various purposes. Further, the sideband interface can be used for a secondary boot source (through as its possible to load a binary firmware image and run it through this type of interface). Further, in some examples, the sideband interface can be permanently disabled in order to reduce access to the system and preserve data integrity. Such a sideband interface could be limited to read-only reduced form to eliminate in the firmware the possibility of entering commands by a user. For security purposes, two different firmware images can be created, one in which all code is dedicated to management of the sideband interface when the sideband interface is present and one in which the sideband interface is present in the previously mentioned reduced form. This can be achieved by starting with a single source code and using some features offered by programming languages to selectively exclude certain parts of the code. Here is an example of such a pseudo C code:

#ifdef FULL_UART_CODE

/*

* place here the code that fully implements the UART interface

*/

#else

/*

* place here the code that does not implement the UART

interface

*/

#fi

To prevent the use of a debug interface as a secondary boot device, an OTP bit can be used such as the following:

- OTP bit: 0=>boot from UART enabled
- OTP bit 1=>boot from UART disabled

In some embodiments, a system management bus (SMBus) interface can be a sideband bus whose signals are placed side by side with those sent across a main bus. This SMBus interface can be used to implement remote management without having to rely on the resources of the host system in which they are installed (e.g., MCTP protocol uses SMBus as an implementation of the physical layer of its stack). This sideband interface can be used for the transmission of service messages of the out-of-band (OOB) type addressed to the management unit (e.g., management 134 in FIG. 1). These side-band service messages can be addressed to the device and may be intercepted and processed by the management unit (such as management unit 134 in FIG. 1). In the example where the sideband interface is an out-of-band (OOB) bus, the sideband interface can be used at the system level for enterprise applications. In some examples where the sideband interface is a JTAG or UART interface, the sideband interface can be used for production of the memory device and, once produced and ready for customer use, can be removed.

In some embodiments, a side channel attack can exploit a correlation between a physical variable (e.g., power consumption, EM emission, etc.) and a secret (e.g., a key) which can be manipulated by the memory system. This type of side channel attack can be used against encryption 337 and decryption 338 cores, as the cores 337/338 compute a constant small secret (e.g., key) several times. The correlated variable can “leak” the secret, and such a “leak” is called a trace. Side Channel Attacks can be divided into three different categories such as a Simple Power Analysis (SPA) where the correlation can be extracted using a single trace, a Differential Power Analysis (DPA) where thousands or hundreds of thousands of traces can be correlated to a leakage model to extract the secret or key, and Template Attacks where a leakage template is built on a different memory device and correlated on the victim device using one trace.

Cryptographic cores described herein can be divided into two groups of cores referred to as high-rate ciphers and low-rate ciphers. A high-rate cipher uses the same key within high bandwidth data traffic and is used for CXL link encryption and data at-rest encryption, described herein. A low-rate cipher, which may be rate-limited, can be used for secure boot image verification, described further below in association with FIGS. 4-5, and/or CSP encryption/decryption to maintain data integrity and security. High-rate ciphers can allow collection of multiple traces, and thus may be vulnerable to SPA, DPA, and/or template attacks. Low-rate ciphers use limited execution and thus may be vulnerable to SPA attacks only.

In some embodiments, a cache attack can be used that allows an attacker to infer the access pattern of other processes of a memory device or virtual machines that share the same cache, such as cache 312. The memory access pattern could reveal an encryption key during execution of security software (e.g., during software AES), or could be used to infer searched keywords or keystrokes. Cache attacks can be based on interference between processes, which may use knowledge of a cache mapping function to cause cache collisions and measure the cache access latency. An effective countermeasure against cache attacks can be to randomize the cache mapping function, thereby making the attacker infer the new mapping function before attempting the attack. Changing the cache mapping function clears the cache and, to limit the performance drawback, a probabilistic permutation of the cache mapping function can be implemented.

In some embodiments, a glitch attack can be used against a memory device. A glitch attack refers to an attack directed at a side-channel (e.g., an EMF, voltage supply/ground, clock, laser, body-bias, probe needle, etc.) used to inject a fault into the system, which can be sufficient to disrupt a normal cycle of firmware execution, without doing permanent damage to the memory system circuitry. Examples of such disruptions can include authentication bypass, which is used to prevent unauthorized access to restricted vendor specific (VS) commands, and code execution deviations, which can result in unintended or incorrect memory security decisions. In order to mitigate such glitch attacks, a combination of detection and resilience can be used so that the memory system is able to detect when an attack is being attempted and can respond with procedures to recover securely from the attack.

Resilience can be achieved by building redundancy into the hardware and software architecture of the memory system. This can ensure that, on detection of a glitch attack, the memory system can automatically resume safe memory operation. Fault injection (FI) detection and mitigation can be implemented using at least one of the following: hardware based FI monitoring and detection and firmware based mitigation coding techniques. When possible, if an FI event is detected, then firmware can log the event. However, in some examples, logging can be limited in order to avoid log overflows.

Further, in some embodiments, where data is made persistent by the use of non-volatile memory device, such as ferroelectric memory devices, and may survive power cycles, specific countermeasures can be used to avoid data tampering or extraction if the memory device or portions of the memory device are removed. Security requirements related to a memory system can apply whether the memory device is using non-volatile or volatile memory devices. Security requirements can include encryption of data stored on a memory device and/or secure erasure of the data stored on the memory device.

In some embodiments, where a portion of the memory system may be removable and data may persist after removal (e.g., using non-volatile memory), erasure of data may be used to ensure data security. In such situations, two types of data removal can be considered with different impacts on the operation execution time. A first type of data removal can be a cryptographic erase which can zero out encryption keys so data is not recoverable, even by an authenticated user. A second type of data removal can be a physical removal of the content of the entire memory media, overwriting user data and meta-data on all types of media (e.g., volatile and non-volatile memory devices) in the memory system.

In relation to these two types of data removal, there can be two types of operations that are driven by specific CXL memory device commands. A first type of CXL memory device command can be a secure erase command that implies erasure of the encryption keys and their replacement with freshly generated encryption keys. A second type of CXL memory device command can be a sanitize command that, when received, causes a controller (such as central controller 310) to physically remove data from a portion or all portions of a memory device in the memory system. This can be achieved by either issuing a wipe command if supported by the protocol (e.g., a non-volatile memory (NVM) protocol, a non-volatile random access memory protocol, etc.) or programming known patterns N times to overwrite the data content stored on the memory device. In one embodiment, a power level can be monitored and a threshold power level can be maintained during execution of the sanitize command. This is to track and, if needed, store the progress of the sanitize operation in order to resume the sanitize operation in case of interruption, e.g., read/write interruption or power interruption.

FIG. 4 illustrates a flow diagram of an example method 440 for security management of a boot operation in accordance with a number of embodiments of the present disclosure. The method 440 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof.

The method 4 can be used to perform a secure boot operation. The secure boot operation can verify firmware binary image integrity and ensure its correct loading and execution. The method can be performed by a management microcontroller that includes a main processor and a security subsystem that includes a dedicated central processing unit (CPU), a dedicated crypto hardware component, a random number generator, and a crypto key storage. In some examples, the main processor and the security subsystem can be two distinct objects or two logical partitions of a single object. The secure boot operation can perform capabilities including protection against external firmware boot and protection against boot of unauthenticated firmware (e.g., modified, rolled back, etc.). The secure boot operation can perform capabilities including setup of a secure execution environment (SEE) to validate all firmware images. The secure boot operation can include ROM code features that include boot loader integrity, identification, and authentication. Further, the secure boot operation can verify authenticity and integrity of the boot loader, using manifest signature, via a digital signature (e.g., RSA signature).

At block 441, the method 440 can include performing a power ON and resetting of an event. At block 442, the method 440 can include waiting for security resources. The security resources can include completion of initialization and/or a self-test before proceeding.

At block 443, in response to completion of the security resources, the method 440 can include verifying public key(s). As an example, a public key can be read and validated by loading a block of data including the public key used by a bootROM and the public key can be associated with a boot loader image. A bootROM can refer to a portion of data stored in a read-only memory (ROM) that is the first code executed by a boot process when the memory device is powered on. This can be performed by comparing a digest of the public key with a digest of the key which was previously computed and stored in the device's immutable non-volatile memory (NVM). At block 444, the method 440 can include fetching a boot loader from non-volatile memory (“NVM”). As an example, the boot loader can be located in the NVM and read from the NVM. In addition, the fetching operation can be in charge of or manage the BootROM.

At block 445, the method 440 can include performing a boot loader attestation operation. The boot loader attestation operation can include validating a boot loader image via a digital signature algorithm (Rivest-Shamir-Adleman or RSA) with the public key that was previously validated as input into the digital signature algorithm. At block 446, in response to successful boot loader attestation, the boot loader can be loaded and executed. In response to any of the operations associated with blocks 441 through 446 not being performed or completed, the secure boot operation can be indicated as failing and the boot sequence can be terminated and the error handler invoked, as illustrated at block 447.

FIG. 5 illustrates a flow diagram of an example method 550 for security management of a boot operation in accordance with a number of embodiments of the present disclosure. The method 550 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified.

The method 550 can be used to perform a secure boot operation. The secure boot operation can be performed to check integrity main firmware and load the main firmware. The firmware image and the bootloader can be validated under the control of its own ROM code. When the ROM code transfers the bootloader and control of the verified image, the security mode can be maintained.

At block