Flexible counter system for memory protection

Abstract

The present disclosure relates to flexible counter systems for memory protection. Generally, using a flexible counter structure can make a counter system for supporting memory protection operations in a device more efficient. A device can include a processing module and a memory module. A flexible counter system in the memory module can include at least one data line that includes a plurality of counters. A bit size of the counters can be reduced and / or changed from existing implementations by an overflow counter that can account for a smaller counter going into an overflow state. A bit indicator can be used to identify a counter that uses the overflow counter. In at least one embodiment, a selector corresponding to each of the plurality of counters is capable of mapping a particular memory cell to a particular counter.

Description

[0001] This application is a divisional application of the same patent application, filed on February 26, 2016, with application number 201680012304.7. Technical Field

[0002] This disclosure relates to data security, and more particularly to a flexible counter system with reduced memory consumption for supporting memory protection operations. Background Technology

[0003] As more and more everyday tasks become computerized, electronic data security has become an area of ​​significant development concern. Computing devices are frequently used to exchange financial data, personally identifiable information, and so on. Therefore, hackers may attempt to compromise computing devices to gain access to this valuable information. For example, malicious software (e.g., malware) may be loaded to passively or actively attack the computing device. Passive attacks may involve malware observing data transferred between the processor and memory to obtain passwords or other sensitive or confidential data. Active attacks may involve modifying data stored in memory to trigger atypical results, such as granting unauthorized users access to the computing device. In either case, plaintext (unencrypted) data exchanged with the processor in the computing device and residing in the device's memory is a major vulnerability.

[0004] Equipment manufacturers, component manufacturers, software developers, and others continue to develop protective measures to combat vulnerabilities. Software-based malware detection and removal solutions typically operate at the privilege level of the operating system (OS) in computing devices. These solutions may be effective against lower-privileged attacks, but they may not be effective against higher-privileged malware like hacking programs. Now, some hardware-based protective solutions are emerging, built very early during the startup of computing devices, and thus can establish protective measures before malware even becomes active. Known good protective firmware can be loaded early during startup, performing various functions such as checking if subsequently loaded software is consistent with known good versions, and establishing protected areas of memory within which data can be protected from malware access. While the benefits of these protective measures may be obvious, at least one problem is that hardware protection systems require supporting systems that consume valuable resources in the device, such as processing power and non-volatile memory space. In larger systems like servers, the consumption of these resources is even more significant. Attached Figure Description

[0005] As the detailed description continues, and with reference to the accompanying drawings, the features and advantages of various embodiments of the claimed subject matter will become apparent, wherein like reference numerals denote like parts, and wherein:

[0006] Figure 1 An exemplary device comprising a flexible counter system for memory protection according to at least one embodiment of the present disclosure is described;

[0007] Figure 2 Exemplary configurations of devices that can be used according to at least one embodiment of the present disclosure are depicted;

[0008] Figure 3 An exemplary structure of a counter system according to at least one embodiment of the present disclosure is described;

[0009] Figure 4 At least one embodiment of the present disclosure is described for targeting Figure 3 The counter system architecture described herein is also an exemplary operation for calculating embedded memory authentication codes for a flexible calculator architecture;

[0010] Figure 5 An exemplary configuration of a memory encryption engine according to at least one embodiment of the present disclosure and an exemplary structure of a flexible counter including an overflow indication system are described.

[0011] Figure 6 An exemplary flexible counter structure including a selection function according to at least one embodiment of the present disclosure is described;

[0012] Figure 7 An exemplary configuration for supporting selection functionality in a flexible counter system according to at least one embodiment of the present disclosure is depicted; and

[0013] Figure 8 Exemplary operations for memory protection according to at least one embodiment of the present disclosure are described.

[0014] Although the following detailed implementation will continue with reference to exemplary embodiments, many substitutions, modifications and variations will be apparent to those skilled in the art. Detailed Implementation

[0015] This disclosure relates to a flexible counter system for memory protection. Generally, using a flexible counter architecture makes counter systems supporting memory protection operations in a device more efficient, at least in terms of memory consumption. For example, a device may include a processing module and a memory module. The processing module may include a memory encryption engine (MEE) that, utilizing security metadata containing at least some counter data generated by the flexible counter system residing at least partially in the memory module, decrypts encrypted data loaded from the memory module or encrypts plaintext data before storing it in the memory module. The flexible counter system may include at least one data row comprising a plurality of counters. By considering overflow counters where smaller counters enter an overflow state, the bit size of the counters can be reduced and / or changed from existing implementations. Bit indicators can be used to identify counters using overflow counters. In at least one embodiment, a selector corresponding to each of the plurality of counters may flexibly map a particular lower-level data row or memory cell to a particular counter (e.g., mapping very active lower-level data rows or memory cells to larger counters, mapping less active lower-level data rows or memory cells to smaller counters, etc.).

[0016] In at least one embodiment, the device including memory protection may include, for example, a memory module and a processing module. The memory module may include at least a flexible counter system. The processing module may include at least a memory encryption engine (MEE) for at least one of the following: decrypting encrypted data loaded from the memory module using security metadata at least partially generated by the flexible counter system, or encrypting plaintext data using the security metadata before storing plaintext data into the memory module.

[0017] In at least one embodiment, the flexible counter system may include at least one data line stored in a memory module, the at least one data line including a plurality of counters. Security metadata may include at least the counter values ​​generated by the flexible counter system. In an exemplary implementation, the size of each counter may be determined based on the number of bits, and at least some of the counters may have different sizes. The plurality of counters may include counter groups, wherein the size of the counters in each subsequent group of counters gradually decreases.

[0018] In at least one embodiment, the plurality of counters may include at least one overflow counter. The MEE can then be used to determine whether one of the plurality of counters is in an overflow state, and when it is determined that the counter is in an overflow state, to determine a counter value by combining the current value of the overflow counter with the current value of the counter. At least one data line may further include bits corresponding to each of the plurality of counters, and a state for each bit indicating whether the corresponding counter is in an overflow state.

[0019] In the same or different embodiments, at least one data row may include a selector corresponding to each of a plurality of counters. Each selector may, for example, be used to map a corresponding counter among the plurality of counters to a lower-level data row or to a unit for storing encrypted data into a memory module. The MEE may then be used to determine that the current value of any one of the plurality of counters is at or above a threshold and cause the selector to remap the lower-level data row or the unit for storing encrypted data into the memory module from the counters determined to have a current value at or above the threshold to a larger-sized counter among the plurality of counters. Consistent with this disclosure, an exemplary method for memory protection may include receiving a request to encrypt plaintext data before storing it into a memory module, loading a data row corresponding to the request from a flexible counter system in the memory module, each data row including a plurality of counters, determining for each loaded data row whether it needs to be reconfigured to generate an incrementing value for the counters in the loaded data row, and if determined to be necessary, reconfiguring the loaded data row, encrypting the plaintext data using data based on the incrementing counter value, and storing the encrypted data in memory.

[0020] Figure 1 An exemplary device comprising a flexible counter system for memory protection according to at least one embodiment of this disclosure is described. First, in describing various embodiments consistent with this disclosure, reference may be made to technologies such as Software Protection Extensions (SGX) developed by Intel Corporation, components that can constitute an SGX, and ways in which an SGX can operate. SGX has been used throughout this application to provide an easily understood perspective for comprehending the various disclosed embodiments and is not intended to limit implementations to using only SGX. Furthermore, "memory protection" as mentioned herein generally includes protecting the confidentiality of data via encryption, integrity protection, and / or replay protection. Integrity protection can defend against attacks, where, for example, an attacker might modify encrypted data in a memory module before decryption. Replay protection can prevent attacks, where, for example, an attacker causes repeated decryption operations to gain unauthorized access to protected data. [The following is a separate section:] ... Figure 3 and Figure 4 Let's discuss the concepts above in more detail.

[0021] exist Figure 1 An exemplary configuration of device 100 is disclosed herein. Examples of device 100 may include, but are not limited to, those based on those from Google. OS, from Apple Or Mac From Microsoft OS, from Linux OS, from the Mozilla project OS, from BlackBerry OS, from HP OS, from Symbian Mobile communication devices such as cellular handhelds or smartphones with operating systems like Apple's, etc. From Microsoft Galaxy from Samsung Mobile computing devices such as Amazon's Kindle tablets, including low-power chipsets from Intel. Netbooks, laptops, notebook computers, handheld computers, etc., as well as desktop computers, servers, smart TVs, and small form factor computing solutions similar to Intel's Next Compute Unit (NUC) platform (e.g., for space-constrained applications, TV set-top boxes, etc.).

[0022] Exemplary device 100 may include at least a processing module 102 and a memory module 104. Generally, processing module 102 can receive data for processing from memory module 104 and can return processed data to memory module 104. In at least one embodiment, data in memory module 104 may be protected. In one exemplary implementation, device 100 may use an SGX to protect at least a portion of memory module 104. SGX can provide a secure, hardware-encrypted computation and storage area within system memory whose contents cannot be decrypted by privileged code or even by applying a hardware probe to the memory bus. When memory module 104 is protected by SGX, an intruder cannot read the contents of the secure area. Protected data cannot be observed outside of SGX, and therefore, protected data is inaccessible outside of SGX. Specifically, the identifier of a program (e.g., a cryptographic hash measurement based on the content of each program) may be signed and stored within each program. Then, when a program is loaded, processing module 102 may verify that the current measurement of the program is the same as a measurement previously embedded within the program. Because a public key for verifying the signature at program loading can be provided to processing module 102, the signature used to sign embedded measurements is also verifiable. Malware cannot tamper with the protected program because its measurements would also be modified. Malware also cannot impersonate the signature because the signing key is secure and associated with the program's author. The elements described below for processing module 102 and memory module 104 can be used to implement security technologies such as SGX in device 100. However, consistent with this disclosure, other existing or future-developed security technologies may also be used.

[0023] As in Figure 1As depicted, processing module 102 may include, for example, at least one processing core 106 (e.g., core 106A, core 106B...core 106n, collectively referred to as "core 106A...n"), core cache 108, memory controller 110, and MEE 112. Cores 106A...n can perform various data processing operations that can use data stored in core cache 108. As mentioned in this application, "cache" may include local volatile memory for storing data that can be used during data processing operations. In at least one embodiment, core cache 108 may include a plurality of separate memory regions organized hierarchically, wherein the outermost level (e.g., where data can be sent and received, MEE logic 114) is the last level cache (LLC). Core cache 108 may help accelerate data processing by avoiding having to repeatedly fetch data from memory module 104 that may be used more than once during data processing. The memory controller 110 can control how the processing module 102 can access the memory module 104, including reading data from the memory module 104 and writing data to the memory module 104.

[0024] For example, MEE 112 may include MEE logic 114 for performing memory protection operations, MEE Ln counter memory 116 for storing top-level counter data, and MEE cache 118 for storing security metadata 126 at least during memory protection operations. Generally, security metadata 126 may include data used in supporting memory protection operations. For example, consistent with this disclosure, core 106A may perform data processing operations that require data to be secured by a protection system such as SGX. Protected data in memory module 104, such as encrypted data lines 120A, 120B, 120C, and 120D (collectively, “encrypted data lines 120A…D”), can be retrieved by MEE logic 114 and decrypted before being provided to core 106A. Figure 1Only four encrypted data lines 120A…D corresponding to the VER and MAC data in a single data line 128 are shown; however, the actual number of encrypted data lines 120A…D in memory module 104 can depend on various factors, such as the size of the MEE-protected area in memory module 104. In at least one exemplary implementation, each data line may include 64 bytes of data that can be stored in a protected area of ​​128 MB in memory module 104. Similarly, data generated by core 106A, which may be sensitive, confidential, etc., may be provided to MEE logic 114 for encryption before being stored in memory module 104. In this way, an attacker monitoring the data exchanged between module 102 and memory module 104 can be prevented from determining the content of specific data, which may be sensitive, confidential, etc.

[0025] In at least one embodiment, using security metadata 122 at least partially stored in memory module 114, MEE logic 114 can use counter-mode encryption to decrypt encrypted data (e.g., encrypted data lines 120A…D) requested by cores 106A…n or to encrypt plaintext data generated by cores 106A…n. Counter-mode encryption operates by performing an XOR operation between the data to be encrypted or decrypted and a seed-based "encryption pad". For example:

[0026] Encryption pad = AES k (Seed) (1)

[0027] Encryption = Plaintext XOR Encryption Pad (2)

[0028] In this context, AES is an encryption operation based on the Advanced Encryption Standard (AES), and k indicates the key size specifying the number of repetitions of the transformation rounds that convert the seed into the encryption pad. The protection provided by counter-mode encryption relies primarily on the uniqueness of the seed. This allows data-related operations to proceed independently of seed-related encryption operations, as these operations can occur in parallel, thus improving overall memory protection performance. Counter-mode encryption requires the seed to be spatially and temporally unique. Spatial uniqueness can be derived from the address in memory module 104 where data (e.g., encrypted data row 120A) can be stored as a component of the seed. Consistent with this disclosure, temporal uniqueness can be achieved using counter values ​​generated by the flexible counter system 126. For example, the counter in each data row of the flexible counter system 126 can be associated with a lower-level data row in a hierarchical counter tree structure and ultimately with a memory cell in memory module 104. The counter in each data row of the tree structure can be incremented before data is stored in the corresponding memory cell. The lowest-level counter value corresponding to a data line written to memory module 104 (e.g., encrypted data line 120A) can be considered the "Version" (VER) of the data. When the encrypted data line 120A is later loaded from memory module 104 into processing module 102, the values ​​of the counters at higher levels of the tree structure can be used to verify the integrity of the VER data line. The Memory Authentication Code (MAC) / VER data 124 and the flexible counter system 126 are generally referred to in this application as security metadata 122. During encryption and / or decryption operations, MEE logic 114 can cause at least some of the security metadata 122 to be loaded into MEE cache 118 for use in the encryption operation (e.g., along with data stored in MEE Ln counter memory 114). Figure 3-5 The composition and structure of the flexible counter system 126 are described in more detail.

[0029] Figure 2 Exemplary configurations of devices that can be used according to at least one embodiment of this disclosure are depicted. In this disclosure, including an apostrophe (e.g., 100') after the item number may indicate that an exemplary embodiment of a particular item is being depicted. For example, device 100' is capable of performing... Figure 1 The device 100' is presented in this application only as an example of a device that can be used in embodiments consistent with this disclosure, and is not intended to limit any of the various embodiments to any particular implementation.

[0030] Device 100' may include, for example, a system module 200 for managing the operation of the device. System module 200 may include, for example, a processing module 102', a memory module 104', a power module 202, a user interface module 204, and a communication interface module 206. Device 100' may further include a communication module 208. Although the communication module 208 is depicted as separate from system module 200, it is provided for illustrative purposes only. Figure 2 The exemplary configuration is shown in the figure. Some or all of the functions associated with the communication module 208 may also be incorporated into the system module 200.

[0031] In device 100', processing module 102' may include one or more processors located in separate components, or alternatively, one or more cores 106A…n located in a single component (e.g., in a system-on-a-chip (SoC) configuration), along with processor-related support circuitry (e.g., bridge interfaces, etc.). Exemplary processors may include, but are not limited to, various x86-based microprocessors available from Intel Corporation, including microprocessors in the Pentium, Xeon, Itanium, Celeron, Atom, Auark, Core-i series, Core M series product families, advanced RISC (e.g., Reduced Instruction Set Computing) machines, or "ARM" processors, etc. Examples of support circuitry may include chipsets configured to provide interfaces (e.g., northbridges, southbridges, etc. available from Intel Corporation) through which processing module 102' can interact with other system components operating at different speeds on different buses, for example, in device 100'. Furthermore, some or all of the functions generally associated with the support circuitry may also be contained in the same physical package as the processor (e.g., in the Sandy Bridge series processors available from Intel Corporation). Figure 2 As shown, the processing module 102' may include at least a core 106A…n, a core cache 108, a memory controller 110, and a MEE 112.

[0032] Processing module 102' can be configured to execute various instructions within device 100'. Instructions may include those configured to cause processing module 102' to perform activities related to reading data, writing data, processing data, forming data, transforming data, converting data, etc. Information (e.g., instructions, data, etc.) may be stored in memory module 104'. Memory module 104' may include random access memory (RAM) and / or read-only memory (ROM) in fixed or removable formats. RAM may include information configured to store information during operation of device 100', such as static RAM (SRAM) or dynamic RAM (DRAM). ROM may include non-volatile (NV) memory modules configured to provide instructions based on BIOS, UEFI, etc., when device 100' is activated, programmable memory such as electronically programmable ROM (EPROM), flash memory, etc. Other fixed / removable storage devices can include, but are not limited to, magnetic storage devices such as floppy disks and hard drives; electronic storage devices such as solid-state flash memory (e.g., embedded multimedia cards (eMMC)); removable memory cards or sticks (e.g., micro storage devices (uSD), USB, etc.); and optical storage devices such as CD-ROMs, digital video discs (DVDs), Blu-ray discs, etc. Figure 2 As shown, the memory module 104' may include at least encrypted data lines 120A…D and secure metadata 122 (e.g., MAC and VER data 124 and flexible counter system 126).

[0033] The power module 202 may include an internal power source (e.g., a battery, fuel cell, etc.) and / or an external power source (e.g., an electromechanical or solar generator, a power grid, an external fuel cell, etc.), as well as associated circuitry configured to provide the power required for operation of the device 100'. The user interface module 204 may include hardware and / or software for allowing users to interact with the device 100', such as various input mechanisms (e.g., microphones, switches, buttons, handles, keyboards, speakers, touch-sensitive surfaces, one or more sensors configured to capture images and / or sense proximity, distance, motion, posture, orientation, biometric data, etc.) and various output mechanisms (e.g., speakers, displays, luminous / flashing indicators, electromechanical components for vibration, motion, etc.). The hardware in the user interface module 204 may be incorporated into the device 100' and / or coupled to the device 100' via a wired or wireless communication medium. In specific environments, such as where device 100' is a server (e.g., rack server, blade server, etc.) that does not include user interface module 204 but relies on another device (e.g., management terminal) for user interface functions, user interface module 204 may be optional.

[0034] The communication interface module 206 can be configured to manage packet routing and other control functions for the communication module 208, and may include resources configured to support wired and / or wireless communications. In some instances, device 100' may include more than one communication module 208 managed by the central communication interface module 206 (e.g., including separate physical interface modules for wired protocols and / or radio waves). Wired communications may include serial and parallel wired media, such as Ethernet, USB, Firewire, Thunderbolt, Digital Video Interface (DVI), High Definition Multimedia Interface (HDMI), etc. Wireless communications may include, for example, very close proximity wireless media (e.g., radio frequency (RF) such as RFID or Near Field Communication (NFC) standards, infrared (IR), etc.), short-range wireless media (e.g., Bluetooth, WLAN, Wi-Fi, etc.), long-range wireless media (e.g., cellular wide-area wireless communication technologies, satellite-based communications, etc.), electronic communications via sound waves, etc. In one embodiment, the communication interface module 206 may be configured to prevent wireless communications operating in the communication module 208 from interfering with each other. When performing this function, the communication interface module 206 can schedule activities for the communication module 208 based on, for example, the relevant priority of message waiting for transmission. Although Figure 2 The disclosed embodiments depict communication interface module 206 and communication module 208 as separate, but it is also feasible to incorporate the functions of communication interface module 206 and communication module 208 into the same module.

[0035] Figure 3 An exemplary structure of a counter system according to at least one embodiment of this disclosure is depicted. As previously discussed, temporal uniqueness can be based on a counter chain, where each counter is associated with a hierarchical data line. In at least one embodiment, the lowest-level counter can then be associated with a cell (e.g., address) in memory module 104 where an encrypted cache line is to be written, wherein the counter increments with each write to the memory cell. The counters can be used to form a VER for the data line to provide replay protection. Security is maintained while the value of the counter can continue to increase. Thus, it is important that the counter is large enough to avoid overflow, where the counter reaches its maximum value within its foreseeable lifetime. Once the counter overflows, temporal uniqueness no longer exists and an attacker can “replay” the encrypted data lines 120A…D at the same address. For example, since the seed no longer changes due to the temporal uniqueness provided by the counter, security metadata 122 from previous encryption operations can be used to replay (e.g., decrypt) the encrypted data lines 120A…D.

[0036] exist Figure 3An exemplary counter structure is depicted at 300. The exemplary counter structure 300 may include hierarchical data rows, including, for example, L3 302, L2 306, L1 314, L0 322, and VER 330. The L3 data row 302 may include a top-level counter (TLC) stored in the MEE Ln counter memory 116 within the processing module 102, and thus can be guaranteed to be secure. The L3 data row 302 may include multiple counters, each corresponding to a lower-level data row (e.g., at the L2 level). Because the L2 eMAC 310 cannot be recalculated without knowing the value of the L3 counter 304, each L3 counter can "protect" the L2 data row from modification within the memory module 104. Similarly, as in the example of L3 data line 302, data line L2 306 may include multiple counters, each counter protecting a lower-level data line (e.g., at the L1 level), L1 data line 314 may include multiple counters, each counter protecting an L0 data line, and L0 data line 322 may include multiple counters, each counter corresponding to a VER line. Each counter in the VER counters may correspond to a cell in memory module 104 where encrypted data 120A…D is stored. The size of each counter may be determined in bits, for example, 56 bits. Data line L2 306 may also include an embedded MAC (eMAC) 310. In at least one embodiment, the eMAC 310 may be embedded by distributing portions of the eMAC 310 among the multiple counters as shown at 312. Similarly, L1 data line 314 may also include an eMAC 318 distributed among multiple counters as shown at 320, L0 data line 322 may also include an eMAC 326 distributed among multiple counters as shown at 328, and VER data line 330 may include an eMAC 334 distributed among multiple counters as shown at 336. Although eMACs 310, 318, 326, and 334 are depicted at 312, 320, 328, and 336 as distributed among multiple counters in data lines 306, 314, 322, and 330, this is merely an example of how eMACs can be embedded. Other configurations (e.g., contiguous at the beginning, middle, and end of a data line) may be consistent with this disclosure.

[0037] In one operational example, counters 304, 308, 316, and 324 can each correspond to lower-level data lines L2 306, L1 314, L0 322, and VER 330, respectively. These counters can be used to form eMACs 310, 318, 326, and 334 to protect these data lines. VER data line 330 includes VER 332, which can be used when encrypting plaintext data 342 and decoding encrypted data line 120. For example, an L2 eMAC 310 can be calculated using encryption operations based on the current value of the counters in L2 data line 306 and the value of counter 304 in the immediately preceding L3 data line 302. The eMAC can then be assigned to L2 data line 306, as shown at 312. Figure 4 The encryption operations are further explained below. These operations can then be repeated for each subsequent data line. For example, L1 eMAC 318 can be calculated by combining the current value of the counter in L1 data line 314 with the current value of counter 308, L0 eMAC 326 can be calculated by combining the current value of the counter in L0 data line 322 with the current value of counter 316, and VER eMAC 334 can be calculated by combining the current value of the counter in VER data line 330 with the current value of counter 332. Then, in the encryption / decryption operation 338, VER 332 and address 340, corresponding to the cell (e.g., address) in memory module 104 where the encrypted data line 120A is stored, can be used to encrypt plaintext data 342 into encrypted data line 120A and decrypt encrypted data line 120A into plaintext data 342.

[0038] Figure 4 At least one embodiment of the present disclosure is described for targeting Figure 3The counter system depicted in the example also illustrates the operation of calculating embedded memory authentication codes using a flexible counter structure. While the benefits of a large counter are obvious (e.g., overflow can be avoided over the foreseeable lifetime of device 100), making the counter too large can lead to various problems. Since a counter structure such as that depicted in example 300 results in a 25% space overhead, the efficiency of counter organization is critical in MEE implementations. This works well when the protected memory size is 128MB, which is typical in existing implementations. However, future implementations can be extended to servers that may include large-footprint applications. For example, assuming an implementation with 192 gigabytes (GB) of protected memory in memory module 104, 48GB of storage module 104 would have to be reserved solely for security metadata 122. Sacrificing 48GB for security metadata 122 is impractical and could prevent the implementation of protective systems such as SGX on large platforms. Furthermore, some operating systems (e.g., Microsoft Windows) already have requirements on how much memory can be requisitioned from the OS. If more memory is reserved than allowed by the OS manufacturer, it will be impossible to obtain hardware certification from, for example, the Windows Hardware Quality Lab (WHQL).

[0039] Consistent with this disclosure, the memory space required for security metadata 122 can be substantially reduced (e.g., by 50%). Better performance can be achieved, for example, due to the ability to combine more counters with the same number of memory accesses. In addition to efficient counter organization, minimizing the impact of overflow prevention on data processing performance is also important. Adaptive mechanisms can minimize memory overhead and, at the same time, ensure that the reduced memory consumption does not come at the cost of increased data processing burden on device 100.

[0040] exist Figure 4Examples 400 and 402 are depicted. Example 400 discloses how to compute MAC 310 based on the counter structure of Example 300. Moving from right to left in the exemplary encryption operation 404, AES 128b encryption can generate a 128B key value (e.g., IP key 1 and IP key 0, each containing 64b) based on a 128b AES key and the current value of counter 306 containing 56b, a 34b address (e.g., corresponding to a memory cell in memory module 104 where data will be stored), and another 128b input of 38b with zero padding ('0'). The 128b key generated by AES encryption and the current value of the counter in L1 data line 314 (e.g., a total of 512b) can then be hashed (e.g., they can be combined, and the value can be computed based on the content of the combined data) to generate a 64b MAC. In Example 400, the calculated MAC could be L1 eMAC 218, which can then be assigned to L1 data line 314, as shown at 320. The same process can also be used for verification when encrypted data (e.g., encrypted data line 120A) is loaded from memory module 104. A “tree path” can be performed starting from the VEL level and moving up to the L3 level, where a new MAC can be calculated for each data line and compared to the eMAC to see if the data line has been changed since it was saved. A mismatch between the newly calculated MAC and the eMAC indicates that the data line has been altered in memory module 104, possibly due to an attack. Discontinuities identified during the tree path can trigger security exceptions in device 100 to protect the device from compromise.

[0041] Example 402 illustrates a modified counter structure consistent with this disclosure. Specifically, the counter in L1 data line 314' has been reduced in size from that in L1 data line 314, and an overflow counter 405 has been added. In Example 402, counter 316' is reduced to 24b. This means that L1 data line 314' can include more than twice the size of the counter in L1 data line 314, and thus twice the number of cells in memory module 104 can be considered for storing encrypted data lines 120A…D. However, since the counter in L1 data line 314' is half the size of the counter in L1 data line 314, it will overflow twice as fast (depending on the activity for the memory cell associated with it). This situation can be considered by combining it with any counter that is in an overflow state. For example, if counter 306' in example 402 is in an overflow state, then when encryption operation 404' is performed, the input to AES 128 may include a 64-bit current value from overflow counter 406, a 24-bit current value from counter 308' (from the previous level's counter), a 34-bit address, and 6-bit zero padding. In at least one embodiment, the overflowing counter (e.g., counter 308') can be reset and start counting again after it has used overflow counter 406. This means that for each time the counter overflows in L1 data line 314', overflow counter 406 can increment only once.

[0042] Furthermore, by packing more counters into each counter line (e.g., L1 data line 314'), MEE 112 can operate with a significantly reduced replay protection tree for the same size on-chip TLC. For example, existing implementations of protection systems similar to SGS can use a 5-level replay protection tree including versions (version, L0, L1, L2, and L3). Using 24-bit counters and the various mechanisms disclosed in this application, MEE 112 is able to reduce the replay tree to four levels (version, L0, L1, and L2 stored in processing module 112). This reduction in levels allows MEE 112 to traverse fewer levels for encryption or decryption during the encryption tree path. Simulations have shown that eliminating the replay tree levels can substantially reduce the performance impact caused by the encryption mechanism of MEE 112 (e.g., a reduction of 11.8%). In addition to improved performance, the space required in the memory module 104 for the counter can be reduced by 50%, which can address the metadata space overhead associated with future use of the protection system (e.g., SGX).

[0043] Figure 5 Exemplary configurations of memory encryption engines according to at least one embodiment of this disclosure and exemplary structures of flexible counters including overflow indication systems are depicted. Figure 5 Two examples are depicted to illustrate that architectural changes to the counter structure, including overflow features such as those disclosed in Example 402, can be implemented. A problem that may arise, at least from the introduction of overflow counter 406, is that each time overflow counter 406 is updated (e.g., when counter 308' enters an overflow state, overflow counter 406 in L2 data row 306' can be incremented), all lower-level eMACs that depend on the value of the counter in the data row must also be updated. For example, when counter 406 increments, L1 eMAC 318', along with any other L1-level data row that depends on one of the 16 counters in L2 data row 306' (not shown), is updated to calculate its respective eMAC. This type of update is referred to as a batch update, as mentioned in this application. To allow efficient batch updates, MEE 112 can be modified, for example, as illustrated in Example 500. For example, MEE 112 can be modified to include cache request filter 504 and encryption request filter 506. For cache access, access to the metadata cache line that is being regenerated for eMAC should be blocked, as these values ​​are changing. Access should only be allowed once the bulk update is complete. This can be done by maintaining the address of the currently updated data line in an update cache line buffer 508, which can be, for example, a register, local memory, etc. In the operational example, the update cache line buffer 508 can be compared with an incoming data line access request to block that access until the data line update is complete. For encryption-related access, a simple cache line update queue 510 can be added, which can be a register or local memory, to hold AES operations generated by the bulk eMAC update or data re-encryption caused by the update overflow counter 406. Now, encryption requests can check if there are any pending requests in the cache line update queue 510 before accessing the AES logic. To avoid potential deadlocks, requests from the cache line update queue 510 can have a higher priority than incoming encryption requests.

[0044] Example 502 depicts a bit-based tagging system that can help reduce the amount of cryptographic data reprocessing required for batch updates due to overflow counter usage. With the overflow counter 406 introduced into the basic counter structure, whenever the overflow counter 406 increments in a data row, it must be assumed that all counters in the same data row change due to their possible dependence on the overflow counter 406, and thus, all eMACs based on these potentially updated counters in the data row must be recalculated. This forced assumption can lead to a wasteful expenditure of valuable data processing capacity, as only one or a few counters in the data row may actually be depending on the overflow counter 406 when it increments. This effect is exacerbated by the fact that, in the counter structure of the proposed Example 402, the L2 data row 314' includes counters that can correspond to sixteen (16) different data rows, which would be central to the cascading effects of wasteful batch eMAC reprocessing. To counteract this effect, in Example 502, a tag “F” 512 corresponding to each counter is introduced to indicate the counter currently dependent on the overflow counter 406. Flag 512 can provide a selective overflow counter mechanism that checks the overflow indicator 512 first, instead of unconditionally concatenating overflow counter 406 with every counter in the data row. As shown in example 502, flag 512 = 0 can indicate that the corresponding counter 318' has not yet entered an overflow state, and thus there is no need to use the overflow counter in the encryption operation, since counter 308' itself is sufficient to provide time uniqueness. In the case of a 128-bit AES operation, 70 bits of zero padding is used instead of the 64-bit overflow counter 406. If flag 512 = 1, then as shown at 404', overflow counter 406 can be used in the encryption operation to provide time uniqueness for overflowing counter 308'.

[0045] The benefits of selectively using overflow counters in the encryption seed can include reduced data processing overhead. For example, when an overflow occurs and a batch eMAC update or a data row re-encryption and MAC recalculation occurs, a cache line counter with F=0 does not need to update its eMAC or re-encrypt the data because overflow counter 406 is not used in the subsequent eMAC calculation based on the counter. For example, if only one counter in a data row uses overflow counter 406 when it increments (e.g., counter 308 in data row L2 306), then during a batch update, only one flag (e.g., F512) will be set to "1", and only the eMAC for the L1 data row (e.g., L1 data line 314) that depends on the time-uniqueness of counter 308' will need to be reformatted to account for the increment of overflow counter 406. This can significantly reduce the performance impact for batch updates associated with overflow counters.

[0046] Figure 6 An exemplary flexible counter structure including selection functionality is depicted according to at least one embodiment of this disclosure. While the probability of a counter overflow may be low, even for a counter of reduced size such as that depicted in Example 402, each overflow degrades performance because it causes the overflow counter 406 to increment, and as a result, may trigger batch eMAC updates (e.g., and / or multiple data re-encryption along with the MAC update if an overflow occurs at the VER level). In SoC products without large LLCs, this overflow becomes more problematic because off-chip access tends to have location. Utilizing location in data flow patterns, some data blocks (e.g., “hot” data blocks) are accessed more frequently than others, causing the corresponding counters to overflow faster than expected (even if the average counter value across data rows remains low). To avoid unwanted counter overflows and performance degradation caused by hot blocks, an adaptive counter mapping system can be introduced to manage the counter mapping between associated data blocks in a way that reduces overflow. With adaptive mapping, counter sizes are no longer equal. Instead, some counters are larger than others. Example 600 illustrates one possible arrangement of counter sizes. Here, each metadata cache line holds four (4) 36-bit counters, four (4) 20-bit counters, four (4) 16-bit counters, and four (4) 10-bit counters, instead of the sixteen (16) 24-bit counters depicted in Example 402. Figure 6 The counter arrangements depicted are examples of how counters can be arranged for illustrative purposes and are not intended to limit the various embodiments disclosed in this application to any particular manner of implementation.

[0047] In addition to the various sizes of counters shown in Example 600, each of the counters can be incremented using a selector 602 (e.g., 4 bits), which can point to any data cache line in a lower level. The links between counters and their associated data cache lines can be dynamically set based on the frequency of counter updates. This is shown in Example 600, where a previous level L2 counter can include an overflow counter linked to any of the four sizes of counters. Example 600 shows an example where two counters of different sizes point to two different encrypted data lines (e.g., stored in specific cells within memory module 104). Here, encrypted data line 120D is accessed more frequently and is therefore assigned a larger counter (36-bit counter 316'), while encrypted data line 120A is assigned a smaller (20-bit) counter because it is updated less frequently. Assigning a 20-bit counter to encrypted data line 120A helps prevent the 20-bit counter from overflowing too quickly (or not overflowing at all).

[0048] In the operational example, selector 602 can be initialized from 0 to n-1, where n is the number of counters in the cache line. In example 600, selector 602 can be initialized from 0 to 15. From initialization, counters 0, 1, 2... can point to cache lines 0, 1, 2... This mapping can be the same as a mapping without adaptive counter mapping. As the system operates, data blocks can be written, and thus, the counters are incremented. At each counter update, the counter value can be checked to see if it is close to overflow. One possible way to verify the counter state is to set a threshold indicating when the counter is approaching an overflow state. For example, if the counter value plus the threshold exceeds the maximum value of the counter, remapping the counter may be necessary. If it is determined that the counter is close to overflow (e.g., based on the threshold), adaptive mapping can promote data lines to larger counters. Promotion can include, for example, searching for the next larger counter to find the next larger counter with the minimum value. For example, if the value of a 10-bit counter is at or above the threshold, a search can be performed to find a 16-bit counter with the minimum value. If it is determined that the minimum value of the next larger counter is less than the counter value to overflow, the two counters can be swapped. This swap can include, for example, both the counter value and the selector pointer. Based on the above operation, the more frequently updated encrypted data lines 120A…D can be promoted to larger counters, while the less frequently updated encrypted data lines 120A…D can be gradually moved to smaller counters. This allows the system to allocate resources based on counter size and minimize the occurrence of counter overflows and data associated with processing overhead.

[0049] Figure 7An exemplary configuration for supporting selection functionality in a flexible counter system according to at least one embodiment of this disclosure is depicted. Utilizing adaptive counter mapping, the mapping between the counter and corresponding lower-level data rows or memory cells in memory module 104 is no longer static. Thus, logic can be used to configure selector 602 to point to the correct lower-level data row or memory cell. Example 700 illustrates one possible implementation of such logic. In such logic, when a request arrives, counter index 702 is first calculated. Counter index 702 is the index used to locate the counter in the absence of an adaptive scheme and can be easily calculated (e.g., using the address in memory module 104 of a specific encrypted data row 120A…D). Then, as depicted at 704, counter index 702 can be compared with selector 602 to find a matching selector 602. Because the position of selector 602 can be fixed, this comparison can be parallelized with multiple comparators. Since there is one and possibly only one selector pointing to a specific lower-level data row or memory cell, the result from a hot vector 706 can be used to read the corresponding cache line counter and provide input to multiplexer 708. For example, in example 700, if no adaptive scheme is used, the incoming request is used to be mapped to the first counter 316'. However, with the new mapping logic, the index can be compared with sixteen (16) selectors, and instead of the 20-bit counter (e.g., the second counter shown in example 700), it is mapped by multiplexer 708 to a specific lower-level data row or memory cell.

[0050] Figure 8Exemplary operations for memory protection according to at least one embodiment of this disclosure are described. In operation 800, a request to encrypt plaintext data into encrypted data may be received. This request may be generated by a processing core in a processing module that also includes a MEE. In operation 802, the next data line (e.g., starting with a VER data line including a VER counter corresponding to a memory cell where the encrypted data will be written) and the next level up data line (e.g., starting with an L0 line containing a counter corresponding to the VER data line) may be loaded. Operations 804 to 808 may correspond to the exemplary embodiments shown in Examples 600 and 700. In operation 804, it may be determined whether overflow remapping is enabled in the counter system (e.g., whether the counter can be remapped to help avoid counter overflow). If it is determined in operation 804 that remapping is enabled, then in operation 806, it may be further determined whether the value of the counter in any of the loaded data lines (e.g., the VER counter in the VER data line or the counter corresponding to the VER data line in the L0 data line) is at or above a threshold. If it is determined in operation 806 that any counter is at or above the threshold, a remapping can occur in operation 808 (e.g., a memory cell can be remapped to a larger counter in the VER data row and / or the VER data row can be remapped to a larger counter in the L0 data row). Then, after it is determined in operation 804 that the counter system is not enabled for remapping, after it is determined in operation 806 that no counter value is above the threshold, or after counter remapping in operation 808, the counter can be incremented in operation 810.

[0051] Then, in operation 812, it can be determined whether a counter overflow has occurred. If it is determined in operation 812 that no counter among the relevant counters has overflowed, then in operation 814, the embedded MAC for the loaded data row (e.g., the VER data row) can be reconstructed. Then, in operation 816, it can be determined whether additional data rows (e.g., L1 / L2 and L2 / L3) need to be loaded. After determining that additional data rows need to be loaded, the process returns to operation 802.

[0052] Returning to operation 812, if it is determined that at least one counter has overflowed, then in operation 818, the overflow counter in the data row where the counter has overflowed can be incremented. Operations 820 to 822 can correspond to the embodiment shown in Example 502. Then, in operation 820, it can be determined whether the system has overflow bits enabled. If it is determined in 820 that the system has overflow bits enabled, then in operation 822, only the eMAC for lower-level data rows that depend on counters marked as using overflow counters needs to be updated. If it is determined in 820 that the flexible counter is not marked, then in operation 824, the eMAC for data rows that depend on counters that may be using incrementing overflow counters (e.g., all counters in the same data row as incrementing overflow counters) can be reformatted. After operations 822 and 824, operation 814 can be returned. If it is determined in operation 816 that no further data rows need to be loaded, then in operation 826, the plaintext data can be encrypted by an encryption operation that uses at least the VER corresponding to the cell in the memory module where the encrypted data will be stored as input.

[0053] Although Figure 8 Operation according to an embodiment has been described; however, it will be understood that this is not necessary for other embodiments. Figure 8 All operations described herein. In fact, it is entirely contemplated in other embodiments of this disclosure that... Figure 8 The operations depicted in the figures and / or other operations described in this application may be combined in a manner not specifically shown in any of the figures, but still remain fully consistent with this disclosure. Therefore, the claims relating to features and / or operations not precisely shown in any of the figures are considered to be within the scope and content of this disclosure.

[0054] As used in this application and the claims, a list of items connected by the term "and / or" can refer to any combination of the listed items. For example, the phrase "A, B and / or C" can refer to A; B; C; A and B; A and C; B and C; or A, B and C. As used in this application and the claims, a list of items connected by the term "at least one" can refer to any combination of the listed items. For example, the phrase "at least one of A, B or C" can refer to A; B; C; A and B; A and C; B and C; or A, B and C.

[0055] As used in any embodiment of this application, the terms "system" or "module" may refer to, for example, software, firmware, and / or circuitry configured to perform any of the foregoing operations. Software may be implemented as a software package, code, instructions, instruction sets, and / or data recorded on a non-transitory computer-readable storage medium. Firmware may be implemented as hard-coded (e.g., non-volatile) code, instructions, or instruction sets and / or data in a memory device. As used in any embodiment of this application, "circuitry" may, for example, individually or in any combination, include hard-wired circuitry, programmable circuitry such as a computer processor including one or more individual instruction processing cores, state machine circuitry, and / or firmware storing instructions executed by the programmable circuitry. A module may be implemented uniformly or individually as circuitry forming part of a larger system, such as an integrated circuit (IC), a system-on-a-chip (SoC), a desktop computer, a laptop computer, a tablet computer, a server, a smartphone, etc.

[0056] Any of the operations described in this application can be implemented in a system comprising one or more storage media (e.g., non-transitory storage media) having instructions stored thereon, individually or in combination, which, when executed by one or more processors, perform the methods. Here, for example, the processor may include, for example, a server CPU, a mobile device CPU, and / or other programmable circuitry. Furthermore, it is intended that the operations described in this application can be distributed across multiple physical devices, such as processing structures located at more than one different physical location. Storage media can include any type of tangible media, such as any type of disk, including hard disks, floppy disks, optical disks, compact disc read-only memory (CD-ROM), compact writable optical disk (CD-RW), and magneto-optical disks; semiconductor devices, such as read-only memory (ROM), RAM such as dynamic and static random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state disks (SSD), embedded multimedia cards (eMMC), secure digital input / output (SDIO) cards, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions. Other embodiments may be implemented as software modules executed by a programmable control device.

[0057] Therefore, this disclosure relates to a flexible counter system for memory protection. Generally, using a flexible counter structure can make a counter system for supporting memory protection operations in a device more efficient. A device may include a processing module and a memory module. The flexible counter system in the memory module may include at least one data row containing a plurality of counters. The bit size of the counters can be reduced and / or changed from existing implementations by using an overflow counter, which can accommodate a smaller counter entering an overflow state. A bit indicator can be used to identify the counter using the overflow counter. In at least one embodiment, a selector corresponding to each of the plurality of counters can be able to map a specific memory cell to a specific counter.

[0058] The following examples relate to other embodiments. The following examples of this disclosure may include subject matter such as devices and methods for memory protection, at least one machine-readable medium for storing instructions that, when executed, cause a machine to perform actions based on the method, modules for performing actions based on the method, and / or flexible counter systems.

[0059] According to Example 1, a device including memory protection is provided. The device may include a memory module comprising at least a flexible counter system and a processing module comprising at least a memory encryption engine for performing at least one of the following: decrypting encrypted data loaded from the memory module using security metadata at least partially generated by the flexible counter system, or encrypting the plaintext data using the security metadata before storing plaintext data into the memory module.

[0060] Example 2 may include elements of Example 1, wherein the flexible counter system includes at least one data row stored in the memory module, the at least one data row including a plurality of counters.

[0061] Example 3 may include elements of Example 2, wherein the security metadata includes at least the counter value generated by the flexible counter system.

[0062] Example 4 may include elements of any of Examples 2 to 3, wherein the counter value is loaded into a cache corresponding to the memory encryption engine in the processing module for use during encryption or decryption.

[0063] Example 5 may include elements of Example 4, wherein the memory encryption engine includes at least one of a cache request filter or an encryption request filter.

[0064] Example 6 may include elements of Example 5, wherein the cache request filter is used to avoid access to data rows in the cache based on updating the cache line buffer.

[0065] Example 7 may include elements of any of Examples 5 and 6, wherein the encryption request filter is used to avoid performing encryption operations on data lines in the cache that are queued for updates based on the cache line update queue.

[0066] Example 8 may include elements of any of Examples 2 through 7, wherein the size of each counter is determined based on the number of bits that make up each counter.

[0067] Example 9 may include elements of Example 8, wherein the plurality of counters comprises a group of counters, wherein the size of the counter in each subsequent group of counters gradually decreases.

[0068] Example 10 may include elements of any of Examples 2 to 9, wherein the plurality of counters includes at least one overflow counter.

[0069] Example 11 may include elements of Example 10, wherein the data row includes a 64-bit overflow counter and 16 24-bit counters.

[0070] Example 12 may include elements of any of Examples 10 to 11, wherein the memory encryption engine is used to determine whether a counter among the plurality of counters is in an overflow state and, when it is determined that the counter is in an overflow state, to determine a counter value by combining the current value of the overflow counter and the current value of the counter.

[0071] Example 13 may include elements of Example 12, wherein the at least one data row includes a bit corresponding to each of the plurality of counters, the state of each bit indicating whether the corresponding counter is in an overflow state.

[0072] Example 14 may include elements of any one of Examples 2 to 13, wherein the at least one data row includes a selector corresponding to each of the plurality of counters.

[0073] Example 15 may include elements of Example 14, wherein each selector is used to map a corresponding counter among the plurality of counters to a lower-level data row in the memory module or a unit for storing encrypted data.

[0074] Example 16 may include elements of Example 15, wherein the memory encryption engine is configured to compare the counter index of a request received in the request with the counter index set in each selector in the at least one data row, and to control the multiplexer to associate the counter having an index that matches the index of the request with the corresponding lower-level data row or cell in the memory module.

[0075] Example 17 may include elements of any of Examples 15 to 16, wherein the memory encryption engine is configured to determine whether the current value of any of the plurality of counters is at or above a threshold, and to cause the selector to remap a lower-level data row or cell for storing encrypted data in the memory module from the counters determined to have a current value at or above the threshold to a larger-sized counter among the plurality of counters.

[0076] Example 18 may include a unit of any of Examples 1 to 17, wherein the flexible counter system includes at least one data row stored in the memory module, the at least one data row including a plurality of counters, wherein the size of each counter is determined based on the number of bits that make up each counter.

[0077] According to Example 19, a method for memory protection is provided. The method may include receiving a request to encrypt plaintext data before storing it in a memory module; loading a data row corresponding to the request from a flexible counter system in the memory module, each data row including multiple counters; determining, for each loaded data row, whether it is necessary to reconfigure the loaded data row to generate an incrementing value for the counters in the loaded data row; if it is determined that it is necessary, reconfiguring the loaded data row; encrypting the plaintext data using data based on the incrementing counter values; and storing the encrypted data in the memory.

[0078] Example 20 may include elements of Example 19, wherein determining whether the data row needs to be reconfigured includes determining whether the counter value is at or above a threshold.

[0079] Example 21 may include elements of Example 20, further including causing at least one selector in the data row to remap a lower-level data row or memory cell currently mapped to a threshold or above the threshold to a larger counter in the data row.

[0080] Example 22 may include elements of any of Examples 19 to 21, wherein determining whether the data row needs to be reconfigured includes determining whether a counter is in an overflow state, incrementing an overflow counter in the data row based on the determination that the counter is in an overflow state, and using the overflow counter value and the value of the overflow counter to reconstruct the embedded memory authentication code for the lower-level data row.

[0081] Example 23 may include elements of Example 22 and may further include setting a bit flag in the data row corresponding to the overflow counter, the bit flag indicating that the value of the overflow counter and the value of the overflow counter are used to reconstruct the embedded memory authentication code for the corresponding lower-level data row.

[0082] Example 24 may include elements of Example 23, wherein reformulating the embedded memory authentication code for lower-level data rows includes reformulating the embedded memory authentication code only for lower-level data rows corresponding to counters with set bit tags.

[0083] Example 25 may include elements of Example 24, wherein reforming the embedded memory authentication code includes performing encryption operations on the corresponding lower-level data lines using the current values ​​of the concatenated overflow counters and the current values ​​of the counters determined to be in an overflow state as input.

[0084] Example 26 may include elements of any of Examples 19 to 25, wherein determining whether a data row needs to be reconfigured includes determining whether a counter value is at or above a threshold, and causing at least one selector in the data row to remap a lower-level data row or memory cell currently mapped to a counter determined to be at or above the threshold to a larger counter in the data row.

[0085] Example 27 provides a system comprising at least a device arranged to perform any of the methods in Examples 19 through 26 above.

[0086] According to Example 28, a chip is provided that is arranged to perform any of the methods in Examples 19 to 26 above.

[0087] According to Example 29, at least one machine-readable medium is provided, including a plurality of instructions that, in response to being executed on a computing device, cause the computing device to perform a method according to any one of Examples 19 to 26 above.

[0088] According to Example 30, a device configured for memory protection is provided, which is arranged to perform any of the methods in Examples 19 to 26 above.

[0089] According to Example 31, a system for memory protection is provided. The system may include modules for receiving a request to encrypt plaintext data before storing it in a memory module; modules for loading a data line corresponding to the request from a flexible counter system in the memory module, each data line including multiple counters; modules for determining, for each loaded data line, whether the loaded data line needs to be reconfigured to generate an incrementing value for the counters in the loaded data line; modules for reconfiguring the loaded data line if determined to be necessary; modules for encrypting the plaintext data using data based on the incrementing counter values; and modules for storing the encrypted data in the memory.

[0090] Example 32 may include elements of Example 31, wherein the module for determining whether a data row needs to be reconfigured includes a module for determining whether a counter value is at or above a threshold.

[0091] Example 33 may include elements of Example 32 and may further include a module for causing at least one selector in the data line to remap a lower-level data row or memory cell currently mapped to a threshold or above the threshold to a larger counter in the data row.

[0092] Example 34 may include elements of any of Examples 31 to 33, wherein the module for determining whether a data row needs to be reconfigured includes a module for determining whether the counter is in an overflow state, a module for incrementing the overflow counter in the data row based on the fact that the counter is determined to be in an overflow state, and a module for reconstructing the embedded memory authentication code for the lower-level data row using the overflow counter value and the value of the overflow counter.

[0093] Example 35 may include elements of Example 34 and may further include a module for setting a bit flag in a data row corresponding to a counter in an overflow state, the bit flag indicating that the value of the overflow counter and the value of the counter in an overflow state are used to reconstruct the embedded memory authentication code for the corresponding lower-level data row.

[0094] Example 36 may include elements of Example 35, wherein the module for reforming the embedded memory authentication code for lower-level data rows includes a module for reforming the embedded memory authentication code only for lower-level data rows corresponding to counters with bit tags set.

[0095] Example 37 may include elements of Example 36, wherein the module for reconstructing the embedded memory authentication code includes a module for performing encryption operations on the corresponding lower-level data line using the current value of the overflow counters connected together and the current value of the counters determined to be in an overflow state as input.

[0096] Example 38 may include elements of any of Examples 31 to 37, wherein determining whether a data row needs to be reconfigured includes determining whether a counter value is at or above a threshold, and causing at least one selector in the data row to remap a lower-level data row or memory cell currently mapped to a counter determined to be at or above the threshold to a larger counter in the data row.

[0097] The terms and expressions used in this application are used as descriptive terms and are not intended to be limiting, and there is no intention to exclude any equivalents of the features shown and described (or parts thereof) in the use of such terms and expressions, and it is understood that various modifications may be made within the scope of the claims. Therefore, the claims are intended to cover all such equivalents.

Claims

1. A device including memory protection, comprising: A memory module includes a flexible counter system comprising one or more data rows, an overflow counter associated with each of the one or more data rows, and a plurality of counters associated with each of the one or more data rows, wherein each of the plurality of counters includes a bit flag indicating an overflow state in the corresponding counter; and The processing module includes at least a memory encryption engine, the memory encryption engine being used for: Use the bit flag corresponding to the counter to determine whether the corresponding counter is in an overflow state; The encrypted data loaded from the memory module is decrypted using secure metadata generated at least in part by the flexible counter system; and The plaintext data is encrypted using the security metadata before it is stored in the memory module; The security metadata includes at least a counter value generated by the flexible counter system using the corresponding counter and also using the overflow counter in response to detecting a bit flag indicating that the corresponding counter is in an overflow state, and wherein the plurality of counters associated with at least one of the one or more data rows include a first counter having a first size and a second counter having a different second size.

2. The device of claim 1, further comprising a cache corresponding to the memory encryption engine, wherein: The counter value is loaded into the cache; and The cache is used to decrypt the encrypted data or encrypt the plaintext data.

3. The device as described in claim 2, wherein, The memory encryption engine includes a cache request filter, an encryption request filter, or a combination thereof.

4. The device as described in claim 3, wherein, The memory encryption engine includes a cache request filter configured to avoid access to data lines in the cache based on updating the cache line buffer.

5. The device as described in claim 3, wherein, The memory encryption engine includes an encryption request filter configured to avoid performing encryption operations on cached data lines that are queued for updates, based on a cache line update queue.

6. The device as claimed in claim 1, wherein, The plurality of counters associated with the at least one data row comprises a plurality of counter groups, wherein the size of the counters in each subsequent counter group is smaller than that in the previous counter group.

7. The device as claimed in claim 1, wherein, The memory encryption engine is configured as follows: Determine whether one of the plurality of counters is in an overflow state; and When a counter is determined to be in an overflow state, the counter value is determined by combining the current value of the overflow counter with the current value of the counter that is determined to be in an overflow state.

8. The device as claimed in claim 1, wherein, The at least one data row includes a selector corresponding to each of the plurality of counters, wherein each selector is configured to dynamically map its corresponding counter to a lower-level data row or a unit for storing encrypted data into the memory module.

9. The device as claimed in claim 8, wherein, The memory encryption engine is also configured to compare the counter index of the request received in the request with the counter index set in each selector, and to control the multiplexer to associate the counter with the index that matches the counter index of the request with the corresponding lower-level data row or the unit for storing encrypted data into the memory module.

10. A method for protecting a memory, comprising: Receive a request to encrypt the plaintext data before storing it in the memory module; The data line corresponding to the request is loaded from the flexible counter system in the memory module, wherein the flexible counter system further includes an overflow counter and a plurality of counters associated with each of one or more of the data lines, wherein each of the plurality of counters includes a bit flag indicating an overflow state in the corresponding counter, and the plurality of counters associated with at least one of the one or more data lines includes a first counter having a first size and a second counter having a different second size. For each loaded data row: Whether a counter is in an overflow state is determined at least in part based on the state of the bit flag of one of the plurality of counters; Generate security metadata for at least one counter that is determined to be in an overflow state; Determine whether the loaded data row needs to be reconfigured to generate an incrementing value for the counter in the loaded data row; and When it is determined that the loaded data row needs to be reconfigured, the plaintext data is encrypted using data based on an incrementing counter value, and the encrypted data is stored in memory.

11. The method of claim 10, wherein, Determining whether the data row needs to be reconfigured includes determining whether the counter value of the counter associated with the data row is at or above a threshold.

12. The method of claim 11, further comprising causing at least one selector in the data row to remap a lower-level data row or memory cell currently mapped to a counter determined to be at or above the threshold to a larger counter in the data row.

13. The method of claim 10, wherein, Determining whether the data row needs to be reconfigured includes determining whether a counter associated with the data row is in the overflow state, and when the counter associated with the data row is determined to be in the overflow state, incrementing the overflow counter in the data row and using the overflow counter value and the value of the counter in the overflow state to reconstruct the embedded memory authentication code for the lower-level data row.

14. The method of claim 10, further comprising selectively reforming the embedded memory authentication code only for lower-level data rows corresponding to counters with set bit tags.

15. The method of claim 14, wherein, Reconstructing the embedded memory authentication code involves using the current values ​​of the concatenated overflow counter and the associated data row counter as input to perform encryption on the corresponding lower-level data row.

16. A non-transitory computer-readable medium including instructions that, when executed by a processor of a device, cause the device to perform the following operations: Receive a request to encrypt the plaintext data before storing it in the memory module; The data line corresponding to the request is loaded from the flexible counter system in the memory module, wherein the flexible counter system further includes an overflow counter and a plurality of counters associated with at least one of the data lines, wherein each of the plurality of counters includes a bit flag indicating an overflow state in the corresponding counter, wherein the plurality of counters includes a first counter having a first size and a second counter having a different second size; For each loaded data row: Whether a counter is in an overflow state is determined at least in part based on the state of the bit flag of one of the plurality of counters; Generate security metadata for at least one counter that is determined to be in an overflow state; Determine whether the loaded data row needs to be reconfigured to generate an incrementing value for the counter in the loaded data row; and When it is determined that the loaded data row needs to be reconfigured, the plaintext data is encrypted using data based on an incrementing counter value, and the encrypted data is stored in memory.

17. The non-transitory computer-readable medium of claim 16, wherein, Determining whether the data row needs to be reconfigured includes determining whether the counter value of the counter associated with the data row is at or above a threshold.

18. The non-transitory computer-readable medium of claim 17, wherein, When executed by the processor, the instruction causes the device to cause at least one selector in the data row to remap a lower-level data row or memory cell currently mapped to a counter determined to be at or above the threshold to a larger counter in the data row.

19. The non-transitory computer-readable medium of claim 16, wherein, Determining whether the data row needs to be reconfigured includes determining whether a counter associated with the data row is in the overflow state, and when the counter associated with the data row is determined to be in the overflow state, the instruction, when executed, also causes the device to increment the overflow counter in the data row and use the overflow counter value and the value of the counter in the overflow state to reconstruct the embedded memory authentication code for the lower-level data row.

20. The non-transitory computer-readable medium of claim 16, wherein, When executed by the processor, the instructions also cause the device to selectively regenerate the embedded memory authentication code only for lower-level data rows corresponding to counters with set bit flags.

21. The non-transitory computer-readable medium of claim 20, wherein, Reconstructing the embedded memory authentication code involves using the current values ​​of the concatenated overflow counter and the associated data row counter as input to perform encryption on the corresponding lower-level data row.

Images