Abstract: Protection for a secure boot procedure can be provided in addition to cryptographic verification of boot firmware associated with the boot procedure. While the boot firmware is being verified and executed at a secure sub-system, an open sub-system can be put into a halt state, during which the open sub-system is prevented from performing the boot procedure. The open sub-system is still prevented from performing the boot procedure even if the boot firmware is verified and/or executed unless the open sub-system is put into the resume state again.

Abstract: Protection for a secure boot procedure can be provided in addition to cryptographic verification of boot firmware associated with the boot procedure. While the boot firmware is being verified, an open sub-system can be placed into a halt state, during which the open sub-system is prevented from performing the boot procedure. The open sub-system can be subsequently placed into a resume state to further perform the boot procedure when the boot firmware is verified. The open sub-system is still prevented from performing the boot procedure even if the boot firmware is verified unless the open sub-system is placed into the resume state again.

Abstract: A processing device of a memory sub-system can monitor a plurality of received commands to identify a forced unit access command. The processing device can identify a metadata area of the memory device based on the forced unit access command. The processing device can also perform an action responsive to identifying a subsequent forced unit access command to the metadata area.

Abstract: Implementations described herein relate to a device identifier composition engine (DICE) 3-layer architecture. In some implementations, a device may include a secure computing environment including a hardware root of trust (HRoT) DICE component. The secure computing environment may include a DICE layer 0 component configured to derive a DICE identity key. The secure computing environment may include a DICE layer 1 component configured to derive a DICE alias key based on the DICE identity key. The secure computing environment may include a controller configured to receive an update to firmware of a component. The controller may be configured to update the firmware of the component based on receiving the update. The controller may be configured to update one or more keys of the component or one or more keys of one or more components above the component in a layer stack.

Abstract: In some implementations, a system includes a set of servers configured to establish a set of virtual machines to provide a computing environment; a set of compute express link (CXL) interface components configured to communicate with the set of servers via a set of CXL interconnects; and a controller configured to at least one of: encrypt protocol data against a CXL interposer security threat associated with the set of CXL interconnects or a malicious extension security threat, provide a secure handshake verification of an identity of the set of CXL interface components, enforce a chain of trust rooted in hardware of the set of CXL interface components; restrict access to an area of memory of the set of CXL interface components that stores security data for verified or secured processes; or perform a security check and set up a set of security features of the set of CXL interface components.

Abstract: Methods, systems, and devices related to field firmware update (FFU). A first memory of a memory module may receive an encrypted segment of a FW package associated with FFU. A decrypted segment of the FW package may be stored by the first memory. A re-encrypted segment of the FW package may be stored by the first memory. The re-encrypted segment of the FW package may be communicated to a second memory of the memory module.

Abstract: Methods, systems, and devices for techniques for managing offline identity upgrades are described. A memory system may receive a command to update a device identifier for a device identifier composition engine (DICE) associated with the memory system. The memory system may generate an updated device identifier, at a first software layer of a set of software layers of the DICE, based on receiving the command. The memory system may decrypt a device specific key (DSK) stored at a read-only memory device of the memory system based on the received command, and sign the updated device identifier using the DSK based on decrypting the DSK. The memory system may execute one or more operations associated with the first software layer of the set of software layers of the DICE based on the signed updated device identifier.

Abstract: Methods, systems, and devices for detecting page fault traffic are described. A memory device may execute a self-learning algorithm to determine a priority size for read requests, such as a maximum readahead window size or other size related to page faults in a memory system. The memory device may determine the priority size based at least in part on by tracking how many read requests are received for different sizes of sets of data. Once the priority size is determined, the memory device may detect subsequent read requests for sets of data having the priority size, and the memory device may prioritize or other optimize the execution of such read requests.

Abstract: A controller can be configured to enable a host to control media testing on a memory device. The interface between the host and the memory can be abstract, such that the host does not have direct control over the memory. Instead, the controller can provide translation between a host protocol, such as compute express link (CXL), and a memory protocol, such as a protocol to control a dual data rate (DDR) interface. The controller can enable media test capability discovery, configuration, and/or control for the host. The controller can enable media test result reporting from the memory to the host.

Abstract: An electronic device can be configured to enable a host to indirectly control testing associated with the electronic device. The interface between the host and the electronic device can be abstract, such that the host does not have direct control over the electronic device. Examples of the electronic device include a memory device and a power management integrated circuit. The electronic device can allow the host to discover a quantity of tests supported by the electronic device and corresponding test descriptors. The electronic device can interact with the host to configure tests and/or reporting of test results.

Abstract: Disclosed in some examples are methods, systems, and devices for authenticating a firmware object on a device and in some examples to safeguard the attestation process from the execution of malicious firmware. In some examples, a firmware update process may, in addition to updating the firmware on the device, write a hash of the authentic firmware code in a secure storage device (e.g., a register). This may be done in some examples in a protected environment (e.g., a trusted execution environment or a protected firmware update process). Upon first boot after the update, a firmware update checker compares the firmware object that is booted with the value of the secure storage device. If the values match, the alias certificate may be regenerated, and the boot continues. If the values do not match, then the alias certificate may not be regenerated, and the system may have an authenticity failure because the key and the certificate do not match.

Abstract: A processing device of a memory sub-system can monitor a plurality of received commands to identify a forced unit access command. The processing device can identify a metadata area of the memory device based on the forced unit access command. The processing device can also perform an action responsive to identifying a subsequent forced unit access command to the metadata area.

Abstract: Methods, systems, and devices for detecting page fault traffic are described. A memory device may execute a self-learning algorithm to determine a priority size for read requests, such as a maximum readahead window size or other size related to page faults in a memory system. The memory device may determine the priority size based at least in part on by tracking how many read requests are received for different sizes of sets of data. Once the priority size is determined, the memory device may detect subsequent read requests for sets of data having the priority size, and the memory device may prioritize or other optimize the execution of such read requests.

Abstract: Systems, apparatuses, and methods related to memory tracing in an emulated computing system are described. Static tracepoints can be inserted into a particular function as part of operating the emulated computing system. By executing the function including the static tracepoints as part of a memory access request, the emulated computing system can receive information corresponding to both a virtual address and a physical address in a real computing system in which data corresponding to the memory access request is stored.

Abstract: Methods, systems, and devices for detecting page fault traffic are described. A memory device may execute a self-learning algorithm to determine a priority size for read requests, such as a maximum readahead window size or other size related to page faults in a memory system. The memory device may determine the priority size based at least in part on by tracking how many read requests are received for different sizes of sets of data. Once the priority size is determined, the memory device may detect subsequent read requests for sets of data having the priority size, and the memory device may prioritize or other optimize the execution of such read requests.

Abstract: A processing device of a memory sub-system can monitor a plurality of received commands to identify a forced unit access command. The processing device can identify a metadata area of the memory device based on the forced unit access command. The processing device can also perform an action responsive to identifying a subsequent forced unit access command to the metadata area.

Abstract: Systems, apparatuses, and methods related to memory tracing in an emulated computing system are described. Static tracepoints can be inserted into a particular function as part of operating the emulated computing system. By executing the function including the static tracepoints as part of a memory access request, the emulated computing system can receive information corresponding to both a virtual address and a physical address in a real computing system in which data corresponding to the memory access request is stored.

Abstract: A processing device of a memory sub-system can monitor a plurality of received commands to identify a forced unit access command. The processing device can identify a metadata area of the memory device based on the forced unit access command. The processing device can also perform an action responsive to identifying a subsequent forced unit access command to the metadata area.

Abstract: Methods, systems, and devices related to auto-referenced memory cell read techniques are described. The auto-referenced read may encode user data to include a predetermined number of bits having a first logic state prior to storing the user data in memory cells. The auto-referenced read may store a total number of bits of the user data having a first logic state in a separate set of memory cells. Subsequently, reading the user data may be carried out by applying a read voltage to the memory cells storing the user data while monitoring a series of switching events by activating a subset of the memory cells having the first logic state. During the read operation, the auto-referenced read may compare the number of activated memory cells to either the predetermined number or the total number to determine whether all the bits having the first logic state has been detected.

Abstract: Systems, apparatuses, and methods related to security management for a ferroelectric memory device are described. An example method can include receiving, at a memory controller and from a host, a command and firmware data. The memory controller can manage a non-volatile memory device, such as a ferroelectric memory device, and the host and the memory controller can communicate using a compute express link (CXL) protocol. The command can be executed to update firmware stored on the non-volatile memory device. The method can further include accessing a first public key from the non-volatile memory device. The method can further include validating the first public key with a second public key within the firmware data. The method can further include validating the firmware data. The method can further include verifying a security version of the firmware data. The method can further include updating the non-volatile memory device with the firmware data.