EP3702924B1 - Technologie de gestion d'étiquettes de mémoire - Google Patents

Technologie de gestion d'étiquettes de mémoire Download PDF

Info

Publication number
EP3702924B1
EP3702924B1 EP20153932.7A EP20153932A EP3702924B1 EP 3702924 B1 EP3702924 B1 EP 3702924B1 EP 20153932 A EP20153932 A EP 20153932A EP 3702924 B1 EP3702924 B1 EP 3702924B1
Authority
EP
European Patent Office
Prior art keywords
page
memory
tag
data
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP20153932.7A
Other languages
German (de)
English (en)
Other versions
EP3702924A1 (fr
Inventor
David M. Durham
Karanvir Grewal
Sergej Deutsch
Kai CONG
Siddhartha CHHABRA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of EP3702924A1 publication Critical patent/EP3702924A1/fr
Application granted granted Critical
Publication of EP3702924B1 publication Critical patent/EP3702924B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466—Key-lock mechanism
    • G06F12/1475—Key-lock mechanism in a virtual system, e.g. with translation means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/40—Specific encoding of data in memory or cache
    • G06F2212/402—Encrypted data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/653—Page colouring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management

Definitions

  • the present disclosure pertains in general to data processing systems and in particular to technology for managing computer memory.
  • a typical data processing system includes random access memory (RAM) of a certain size.
  • RAM random access memory
  • OS operating system
  • a typical data processing system includes random access memory (RAM) of a certain size.
  • RAM random access memory
  • OS operating system
  • a conventional OS organizes virtual memory on the basis of fixed-size blocks known as "pages," and the OS uses page tables to map the virtual memory addresses to physical memory addresses. Accordingly, virtual memory allows different applications to use the same virtual address to access different physical addresses.
  • the OS may also swap data from RAM out to a disk (or other mass storage device) when that data has not been accessed lately and the memory space is needed for other data. When the OS swaps data from RAM out to disk, it swaps out a complete page of data at a time.
  • MKTME Multi-Key Total Memory Encryption
  • MKTME a data processing system may use different keys to encrypt different pages of memory.
  • MKTME provides for memory protection on a more granular or finely detailed basis, in that different memory pages may be protected with different keys, rather than having all pages protected with a single key.
  • the present disclosure involves technology for providing memory protection on a more granular basis than MKTME.
  • US 2019/042 402 A1 discloses an apparatus including a page miss handler to receive a full address including a linear address and a key identifier for a key. Different keys may be used for multiple data structures within the same memory page.
  • 1024 consecutive bytes may be referred to collectively as a "kilobyte;" 1024 kilobytes (KB) (i.e., 1,048,576 bytes) may be referred to as a "megabyte” (MB); 1024 MB may be referred to as a “gigabyte” (GB); and so on, with terabytes (TB), petabytes (PB), exabytes (EB), etc.
  • Various conventional processors support page sizes of 4 KB, 8 KB, 64 KB, 256 KB, 1 MB, 4 MB, 16MB, 256 MB, 2 GB, and even higher. In addition, some conventional processors support 64-bit memory addresses.
  • a data processing system may use one or more of those unused address bits to specify data attributes other than location. For instance, a data processing system may use such bits to store a key identifier (KeyID) for a key to be used to encrypt and decrypt the data that is stored at the memory location specified by the other bits of the address.
  • KeyID key identifier
  • the unused bits may be used to store other types of information for protecting the data that is stored at the memory location specified by the other bits of the address.
  • a data processing system may use memory tags to provide for multiple different types of protection for different subdivisions within a page.
  • a sequence of one or more bits in a memory address that is used to specify a data attribute other than location may be referred to as a "memory tag,” a “tag section,” or simply a "tag.”
  • the bits in a memory address which do specify the memory location may be referred to as “address bits” or an "address section.”
  • the value residing in a memory tag may be referred to as the "tag value” or the “tag color, and the value residing in the address section may be referred to as the "address value.”
  • a two-bit memory tag may support four different tag values or colors (i.e., the tag values 0 through 3).
  • a memory controller may protect or manage the data residing at the location specified in the address section of a memory address, based on the tag value specified in the tag section of that memory address. For instance, as described in greater detail below, the memory controller may use the tag value to retrieve metadata associated with the location specified in the address section of the memory address, and the memory controller may protect the data residing at the location, based on that metadata.
  • a conventional OS organizes virtual memory into pages, using page tables to map virtual memory to physical memory, and swapping data from RAM out to disk a page at a time.
  • processors and memory controllers may operate on sections of memory that are smaller than pages.
  • a memory controller may use a block size that is smaller than a page when copying data to or from processor cache. That block size may be referred to as a "cache line.”
  • a memory controller may copy one cache line at a time when it reads from and writes to cache, and each cache line may be a fraction of the size of a page.
  • each subdivision may be referred to in general as a "subpage.”
  • a subpage when a page is subdivided into (or contains) two or more subdivisions, each subdivision may be referred to in general as a "subpage.”
  • a subpage when a subpage is the same size as a cache line for cache memory in the data processing system, that subpage may be referred to as a "line.”
  • this disclosure frequently refers to lines.
  • the present teachings may also be used with other types of subpages.
  • a data processing system may use memory tags to provide protection for different lines within a physical page.
  • the data processing system may thus provide for subpage granular access control, in that the data processing system controls access on the basis of blocks that are smaller than a page.
  • the data processing system may provide software applications with the ability to assign different memory tags or colors to different blocks of memory.
  • MTM memory tag map
  • the software saves the correct tag values to the MTM in connection with memory allocation operations, and the software may remove tag values from the MTM in connection with operations to deallocate memory, such as the operations performed by a "free" function.
  • An MTM may associate each memory tag with a corresponding virtual address, with a corresponding physical address, or with both.
  • the OS may use software-based line processing for reading and writing a page with fine-grained protection for COW and SI/SO.
  • the OS kernel performs COW or SI/SO procedures for a page of physical memory
  • the OS may read or write each line individually, specifying the address for a line, along with a tag value for that line.
  • This approach may be referred to as "software-based line processing.”
  • the OS may use a loop to read or write each line with the right tag value from the MTM, until the whole physical page has been processed.
  • the OS may read and write each line of a page correctly, even though different lines are protected by different tags.
  • software-based line processing may entail significant performance overhead. For instance, if the MTM does not associate tags with physical addresses, the OS may need to translate the physical address for each line into the corresponding virtual address, to obtain the tag associated with that virtual address.
  • the hardware provides for instructions which enable the OS kernel to read and write a page efficiently, while the hardware provides the proper tag values for each line within the page.
  • This approach may be referred to as "hardware-based line processing.”
  • the processor supports a "write_tagged_page” instruction which writes content to a page with specified tag values, and a "read_tagged_page” instruction which reads a protected page with the proper tag values.
  • Hardware-based line processing enables the data processing system to directly compute the tag for each line to be read from RAM or written to RAM, without translating the physical address into the virtual address for each line.
  • the OS may specify (a) the physical address for the page and (b) the location of the tags in the MTM for that page, and in response the hardware may automatically compute (a) the physical address for each line in the page and (b) the corresponding tag for each line.
  • the hardware provides a fine-grained instruction for reading or writing a single line, instead of a whole page.
  • these instructions simply provide a method for the software to read a tag for each cache line using the physical address (e.g., a facility that cause the memory controller to return the tag associated with a given physical address). Once the tags are read, the software can read the associated lines using those tags. Consequently, hardware-based line processing provides the same or similar functionality as software-based line processing, but with better performance.
  • these instructions may provide different granularities, from a page granularity to cache line granularity or even a sub-cache line granularity.
  • the instructions may be part of a native instruction set architecture (ISA) or a wrapper for software to use. If the instructions are part of a wrapper, the underlying implementation may simply be provided by a combination of software libraries with some hardware support.
  • ISA native instruction set architecture
  • wrapper the underlying implementation may simply be provided by a combination of software libraries with some hardware support.
  • the term "facilities" may be used in general to refer to such instructions, wrappers, etc.
  • FIG. 1 is a block diagram of an example of a data processing system 10 that includes technology for managing memory tags.
  • data processing system 10 includes a processor 12, RAM 14, and non-volatile storage (NVS) 18.
  • NVS 18 may be implemented as a hard disk drive (HDD) or as any other suitable type of mass storage device.
  • processor 12 includes multiple cores 20A and 20B, a memory controller 30, and a cache memory 40.
  • Cache memory 40 may also be referred to simply as cache 40.
  • components such as core 20A, core 20B, cache 40, and memory controller 30 may all reside in a single chip or substrate, which may be referred to as a "system on a chip" (SoC). In other examples, two or more of those components may reside in different chips, which may be connected within a single package of chips or connected across separate packages.
  • SoC system on a chip
  • data processing system 10 is depicted with a relatively simple configuration.
  • the present teachings are not limited to the illustrated configuration, but may be used to advantage in data processing systems with a wide variety of configurations.
  • core 20B may have the same kinds of features as core 20A or a different set of features.
  • core 20B may be a field-programmable gate array (FPGA), an integrated general-purpose computing on graphics processing unit (GPGPU), an ultra-low power microprocessor (e.g., an Intel Atom ® processor) coupled with a big core in a heterogeneous processing environment, etc.
  • FPGA field-programmable gate array
  • GPU general-purpose computing on graphics processing unit
  • ultra-low power microprocessor e.g., an Intel Atom ® processor
  • NVS includes an OS 70 and multiple applications 50 and 60.
  • Processor 12 may copy OS 70 and applications 50 and 60 from NVS 18 to RAM 14 for execution.
  • memory controller 30 When software running on core 20A or core 20B requests a read from RAM 14 or a write to RAM 14, memory controller 30 mediates those reads and writes. Moreover, memory controller 30 copies data from RAM into cache 40 and updates data in cache 40, since cache 40 can be accessed much more rapidly than RAM 14. In particular, memory controller 30 reads from and writes to cache 40 using a predetermined block size, known as a "cache line,” as indicated above. In the illustrated example, the size of each cache line is 64 bytes. Other examples may use larger or smaller cache lines.
  • Figure 1 depicts a hypothetical scenario in which application 50 is an anti-virus program and application 60 is web browser.
  • data processing system 10 may be configured to automatically launch application 50 at startup.
  • OS 70 has launched application 50 as a process 50A.
  • OS 70 has also launched application 60 as process 60A, for instance in response to user input (e.g., a click on an icon for application 60, a click on a hyperlink, etc.).
  • process 60A has forked to create process 60B.
  • OS 70 maintains a different page table for each process.
  • page tables for processes 50A, 60A, and 60B are shown as page tables 54A, 64A, and 64B, respectively.
  • the page table for each process maps the virtual addresses (VAs) for that process to physical addresses (PAs).
  • VAs virtual addresses
  • PAs physical addresses
  • Any suitable data structure or set of data structures may be used to implement page tables, including without limitation hierarchical page tables.
  • Figure 1 depicts page tables which include virtual addresses, page tables may be configured to use a virtual address as an index to a physical address without actually saving the virtual address in the page table.
  • the information in a page table that enables a core to translate a virtual address into a physical address may be referred to in general as a "page table entry" or a "translation.”
  • each core includes a translation lookaside buffer (TLB) that includes a subset of the page table entries from the page tables.
  • TLB translation lookaside buffer
  • cores use TLBs to cache mappings from page tables, to store the virtual address to physical address translations. Accordingly, a core uses its TLB to translate a virtual address from a process to the corresponding physical address, without resorting to the page table for that process, if the TLB already includes the translation for that virtual address.
  • TLB entry the information in a TLB that enables a core to translate a virtual address into a physical address
  • core 20A includes a TLB 22A
  • TLB 22A maps virtual addresses to physical addresses.
  • the TLB in a core may include a different set of translation for each process running on that core.
  • a TLB entry may include at least part of a virtual address (e.g., the virtual page number), as well as a process identifier (PID) to identify the process associated with that virtual address.
  • PID process identifier
  • a conventional OS organizes virtual memory on the basis of pages, and the OS may also swap data from memory out to a disk (or another mass storage device) when that data has not been accessed lately and the memory space is needed for other data.
  • OS 70 swaps pages out to swap space 74.
  • OS 70 manages physical memory and virtual memory using a page size of 4 KB.
  • Other examples may use larger or smaller page sizes.
  • memory controller 30 manages cache memory 40 using a cache line size of 64 bytes.
  • a 4 KB page of memory may be subdivided into 64 lines, with each line containing 64 bytes.
  • Data processing system 10 uses memory tags to provide for multiple different types of protection for different lines (or other subdivisions) within a page of memory. For instance, in one example or scenario, a process may assign different tags to different lines (or subpages) allocated to that process.
  • the different memory tags cause memory controller 30 to provide different types of protection for the lines associated with the different tags. For instance, different tags may identify different keys for encrypting different lines. Alternatively, as described in greater detail below, tags may be used to provide other types of protection.
  • some or all of the control logic for enforcing protection based on memory tags is implemented as a memory protection module 34 in memory controller 30.
  • each process maintains its own MTM, to keep track of which tags are assigned to which lines of virtual memory.
  • the MTMs for processes 50A, 60A, and 60B are depicted as MTMs 52A, 62A and 62B, respectively.
  • each process may use its MTM to associate different memory tag values with different lines of virtual memory for that process.
  • an MTM that is maintained by a process may be referred to as a "user MTM.”
  • one or more other components of a data processing system may maintain one or more MTMs for the tagged memory lines associated with a process.
  • OS 70 may maintain one or more MTMs, as described in greater detail below.
  • MTMs may be referred to in general as "kernel MTMs.”
  • RAM 14 includes a kernel MTM that is referred to as a "swapped MTM" 76.
  • OS 70 may use swapped MTM 76 to save memory tag values and corresponding virtual and/or physical addresses for pages that have been swapped out of RAM for a process.
  • a core may maintain one or more MTMs. Such MTMs may be referred to in general as “system MTMs.”
  • core 20A stores system MTM 80 in a portion of RAM 14 that has been reserved for error detection and/or correction purposes, such as one or more error-correcting code (ECC) memory chips or modules.
  • ECC error-correcting code
  • FIG. 1 such memory is depicted as error-correction memory (ECM) 16.
  • ECM error-correction memory
  • core 20A When core 20A writes to RAM 14, core 20A specifies the tag as part of the memory address, but memory protection module 34 strips off the tag and stores it in ECM 16.
  • memory protection module 34 uses system MTM 80 to store a tag for each line (in each physical page) that was allocated with memory tag protection.
  • memory controller 30 simply stores the tags inline with the data, in that memory controller 30 writes 64B of data to a physical address and also 1B of tag associated with that physical address in response to a single write request from core 20A.
  • memory controller 30 may be configured to save the data and the tag as part of a single write operation.
  • core 20A may allow OS 70 to obtain a tag value for a specified physical address by using a special request value for addressing the memory controller.
  • MTMs may be stored, for example, (a) in memory that can be read by an application or an OS, or (b) in memory that cannot be read by an application or an OS (e.g., in ECM).
  • an application and/or an OS may not know where an MTM is stored, but a processor may provide an ISA extension, an application programming interface (API), or some other facility through which the application and/or the OS can obtain tags, to provide for paging and COW, for example.
  • API application programming interface
  • each virtual address and each physical address in page table 54A includes a tag section that spans 8 bits and occupies the high order byte. Accordingly, MTM 52A stores each memory tag in one byte, in a data processing system with a page size of 4K and a line size of 64 bytes. Consequently, an MTM that is 1/64 th the size of a page may be used for saving the tags for a page.
  • the tag section may be smaller or larger, and it may occupy different portions of the virtual and physical addresses.
  • a tag section may include two or more subsections. For instance, an 8-bit tag section may include tag-type subsection in the high-order nibble and a tag-value subsection in the low-order nibble
  • an MTM may be optimized to enable a single entry to cover a range of lines, instead of having a separate entry for every line. For example, if a single tag is used for a whole page, the MTM may only contain a single entry for that page, thus reducing the storage needed for the MTM.
  • process 50A utilizes memory to store program data.
  • lower level components e.g., OS 70
  • metadata may be used in general to refer to the data that the lower level components use to manage the memory that programs such as process 50A utilize to store program data.
  • the metadata that relates to the actual program data may also be stored in memory.
  • the data in the MTMs may be referred to as metadata.
  • Metadata examples include tags, keylDs, message authentication codes (MACs), ECCs, and/or other data that is associated with a line (or other subpage) that is managed with granularity that is finer than page granularity.
  • the data in an MTM may include, for instance, a keylD and a MAC that has been computed, based on that keylD.
  • an MTM entry may include a MAC that is based on a tag value from a memory address, but that tag value may not be stored in the MTM entry.
  • Figure 2 is a block diagram illustrating example of various data structures used by data processing system 10 to manage memory tags. For instance, Figure 2 shows more details for MTM 52A and page table 54A from Figure 1 . Figure 2 also illustrates how the data in those data structures relates to different portions of memory that have been allocated to process 50A. Those portions of memory may have been allocated using a process like the one described below with regard to Figure 3A .
  • process 50A has dynamically allocated three different blocks of virtual memory with different types of memory tag protection.
  • One of those blocks happens to be the size of a line (i.e., 64-bytes), and it has been allocated with a null or zero tag value (0x0).
  • Another of those blocks happens to be the size of two lines (i.e., 128-bytes), and it has been allocated with a tag value of 0x1. That block is depicted as "Line B” and "Line C.”
  • Another of those blocks (depicted as "Line D”) has been allocated with the tag value of 0xD.
  • Lines A through D are depicted within the virtual memory 90 of process 50A.
  • Figure 2 shows each different line of allocated memory as a distinct unit within virtual memory 90.
  • each of the blocks or lines shown in virtual memory 90 is the same size as a cache line. Accordingly, those blocks are depicted as Line A, Line B, Line C, Line D, etc.
  • different types of fill are shown in each line, to denote the different tags associated with each line, with no fill used for tag value 0x0, dotted fill used for tag value 0x1, and vertical lines used for tag value 0xD.
  • process 50A may not specifically request a line (or multiple lines), but may instead simply request a particular number of bytes. In addition, process 50A may disregard page boundaries when requesting allocation of memory. Accordingly, Line A may reside in one virtual page, Lines B and C may reside in another virtual page, and Line D may reside in another virtual page, for instance. Since memory tags occupy high-order bits of virtual memory addresses, lines with different tags will not end up in the same page of virtual memory. Nevertheless, lines with different tags may end up residing in the same page of physical memory, as described in greater detail below. When a data processing system allows multiple virtual pages to be mapped to the same physical page, the virtual pages may be considered “aliases,” and the data processing system may be said to support "page aliasing.”
  • process 50A also maintains MTM 52A, so that MTM 52A associates a particular tag with each of Lines A through D.
  • MTM 52A associates the tag value 0x0 with Line A, the tag value 0x1 with Lines B and C, the tag value 0xD with Line D, etc. More details with regard to maintaining MTM 52A are provided below in connection with Figure 3A .
  • OS 70 when OS 70 manages page table 54A, OS 70 includes both a tag section and a location section in each virtual address and each physical address.
  • the tag section includes the tag value to be used for that virtual or physical address.
  • the complete 64-bit virtual address for that line is provided below in hexadecimal and binary representations (with the prefix "0x” denoting hexadecimal representation, the prefix "0b” denoting binary representation, and with a space inserted after each set of 16 bits in the binary representation for readability): 0x10000000FFFFCFC0 0b0001000000000000 000000000000 1111111111111111 1100111111000000
  • a data processing system may use a practice referred to herein as "TLB bypassing" to handle memory access requests from an application.
  • TLB bypassing the OS still includes both a tag section and a location section in each virtual address, and the OS stores the tag value in the tag section. But the OS does not store tag values in the physical addresses in the page tables or the TLB. Instead, the core disregards the tag when doing the address translation to determining the corresponding physical address, and then the core inserts the tag from the virtual address into the physical address that is sent to the memory controller. In other words, the core sends a tagged physical address to the memory controller.
  • the memory controller then strips the tag from the memory address and uses the memory address without the tag (i.e., the "untagged address") to access the data. However, the memory controller still uses the tag for memory protection. For instance, when the tag is a KeylD, the memory controller may use the corresponding key to encrypt or decrypt the data at that location. In addition or alternatively, the memory controller may generate integrity information such as a MAC based on that key. Or, when the tag is a different type of value, the memory controller may determine whether the tag value from the core is proper.
  • the memory controller determines whether the tag value (supplied by the core in connection with a request to access the specified physical location) is proper by comparing that tag value with a tag value that was previously stored in an MTM for the current process or the system MTM.
  • a tag value that is stored in an MTM may be referred to as an "original" tag value or a "proper" tag value. For instance, if Line B has a tag value of 0x1 associated with it, but core 20A tries to access Line B using a tag value of 0x2, memory controller 30 will report an access control violation, due to a tag mismatch.
  • the tag is a KeylD
  • memory controller 30 will use the tag to select a cryptographic key. When core 20A supplies an incorrect tag, memory controller 30 will select an incorrect key, which will result in a cryptographic integrity failure. Consequently, memory controller 30 may report an access control violation.
  • the data processing system may maintain an MTM to identify the proper tag for each physical line of protected memory allocated to that process.
  • tags may be tied to physical addresses in kernel MTMs or system MTMs.
  • the virtual address for Line B is 0x10000000FFFFCFC0.
  • the virtual address for Line C is 0x10000000FFFFD000.
  • Lines B and C are adjacent, with Line B occupying the last 64 bytes of one virtual page, and Line C starting at the beginning of the next virtual page.
  • Lines B and C each have the tag value of 0x1.
  • OS 70 may happen to map Lines B and C to the same page of physical memory. In fact, in the scenario of Figure 2 , OS 70 has mapped Lines A through D to the same physical page.
  • page table 54A depicts a complete physical address for purposes of illustration, but in practice, a page table may include only part of a physical address (e.g., a frame number to identify a page of physical memory), and a core may use the virtual address to compute the rest of the physical address (e.g., an offset).
  • a physical address e.g., a frame number to identify a page of physical memory
  • a core may use the virtual address to compute the rest of the physical address (e.g., an offset).
  • process 50A When process 50A subsequently accesses any line (e.g., Line D), process 50A automatically supplies the proper tag value (e.g., the value of 0xD), since that tag value is embedded in the virtual address used by process 50A to access that line. Consequently, memory protection module 34 uses the proper tag value to manage protection of the data read from and written to RAM 14 by process 50A. For instance, if the tags serve as KeylDs, memory protection module 34 may use the key identified by the value 0xD to encrypt the data from process 50A when memory controller 30 writes Line D from cache 40 to RAM 14, and memory protection module 34 may also use that key to decrypt the data when memory controller 30 reads Line D from RAM 14 into cache 40.
  • the tags serve as KeylDs
  • memory controller 30 may use that key to generate integrity data, as indicated above. And if the integrity data for a read does not match integrity data that was previously generated and stored in an MTM when the program data was written to RAM 14, memory controller 30 may report a tag mismatch. Also, when process 50A uses a virtual address to access memory, core 20A and/or memory controller 30 may use any suitable techniques to carry forward the proper tag to access the physical address associated with the specified virtual address. For instance, as described in U.S. patent application publication 2017/0285976 titled "Convolutional Memory Integrity", the core and/or the memory controller may use page-level aliasing to create different address pools (or ranges) that map to the same memory locations, while having the effect of changing the tags, which may encode key domain information.)
  • OS 70 when OS 70 performs COW and SI/SO for pages allocated to a process, OS 70 uses the MTM for that process to obtain the correct tag value for reading from or writing to each line within a page.
  • Figures 3A through 3D present a flowchart of an example of a process for managing memory tags.
  • Figures 3A through 3D are described herein with regard to a hypothetical scenario involving OS 70 running in data processing system 10.
  • Figure 3A illustrates a hypothetical scenario involving OS 70 launching application 50 as process 50A, and process 50A assigning different tags to different sections of memory allocated to process 50A.
  • the process of Figure 3A may start with OS 70 determining whether an application should be launched, as shown at block 110.
  • application 50 is an anti-virus application
  • data processing system 10 is configured to launch application 50 at startup.
  • OS 70 may determine that application 50 should be launched.
  • OS 70 may allocate an initial block of virtual memory of a predetermined size for process 50A, as shown at block 112.
  • OS 70 may then load the code for application 50 into the initial block of memory, and OS 70 may then launch application 50 as process 50A, as shown at block 114 and 116.
  • process 50A may then request dynamic allocation of additional tagged memory for itself at runtime.
  • process 50A may use a memory allocation function from a statically linked library or a dynamically linked library (DLL) such as glibc to request allocation of a memory block of a specified size to be added to the heap for process 50A.
  • DLL dynamically linked library
  • that memory allocation function is similar to the malloc function, but with enhancements to support memory tags.
  • such an enhanced memory allocation function may be referred to as "malloct.”
  • process 50A may specify a memory tag value to be associated with memory block being allocated.
  • process 50A may use a library with a malloc function that has been enhanced (relative to a conventional malloc function) to automatically use memory tags whenever process 50A dynamically allocates memory.
  • the malloc function may use any suitable technique to select the tag value or values to be used, including without limitation a round-robin technique.
  • the functions or programs for allocating memory e.g., malloc or malloct
  • the memory manager may allocate a virtual memory block of the requested size to process 50A, as shown at block 132, and the memory manager may return the virtual address for the start of that block to process 50A.
  • the virtual address may include a tag section which includes the tag value that was used by the memory manager (e.g., the tag that was specified by process 50A to malloct or the tag that was automatically selected by malloc), along with a location section to identify the location of the allocated memory.
  • the virtual address that the memory manager returns to process 50A is encoded with the specified memory tag value.
  • process 50A may then update MTM 52A to identify the memory tag that is associated each line of virtual memory that was just allocated.
  • core 20A and/or memory controller 30 may automatically update system MTM 80 to associate each line of that physical memory with the proper memory tag value.
  • the process of Figure 3A may then return to block 130 via page connector A.
  • Data processing system 10 may then repeat the operations depicted in blocks 132 and 134 to allocate additional blocks of virtual memory to process 50A in response to further allocation requests from process 50A.
  • process 50A when process 50A subsequently accesses any line, process 50A automatically supplies the proper tag value, since that tag value is embedded in the virtual address used by process 50A to access that line. Consequently, memory protection module 34 uses the proper tag value to manage protection of the data read from and written to RAM 14 by process 50A.
  • OS 70 may determine whether any of the physical pages of memory for process 50A should be swapped out (e.g., to make room for a different page of virtual memory to be swapped in to physical memory), as shown at block 140. If no pages need to be swapped out, OS 70 may then determine whether a page needs to be swapped in, as shown at block 150. For instance, OS 70 may determine that a page needs to be swapped in, in response to process 50A attempting to read or write to a page that was swapped out. If no pages need to be swapped in, OS 70 may determine whether copy-on-write (COW) has been triggered for a page of process 50A, as shown at block 160.
  • COW copy-on-write
  • OS 70 may create page table entries for process 60B which map the virtual addresses of process 60B (which match the virtual addresses of process 60A) to the same physical addresses as the pages used by process 60A. If neither process ever modifies any of those pages, it is not necessary to actually duplicate those physical pages.
  • a physical page that is shared in this manner by two different process may be referred to as a "shared page.”
  • OS 70 may then create a new physical page, so that process 60A can access the modified version of the page, and process 60B can access the unmodified version of the page. Accordingly, OS 70 may determine that COW has been triggered in response to detecting that a process is writing to a shared page.
  • the process may return to block 130, and OS 70 may continue to watch for (a) a request for more memory, (b) the need to swap a page in or out, or (c) the need for COW, as indicated above.
  • Figure 3B depicts an example of a process for swapping a page of tagged memory out of RAM 14 for process 50A.
  • the example depicted in Figure 3B includes many details pertaining to specific data structures and operations. However, as described in greater detail below, other examples may provide enhanced low-level support for one or more operations, thereby simplifying the operations to be performed by the OS.
  • the process of Figure 3B may start with OS 70 invalidating the page table entry which links the physical page to be swapped out (the "exiting page") with a virtual page, as shown at block 210.
  • OS 70 unmaps the exiting page from page table 54A as page not present in RAM.
  • OS 70 also flushes TLB 22A and any pertinent caches.
  • OS 70 also performs various steps relating to the read_tagged_page instruction mentioned above and described in greater details below. For instance, as shown at block 214, OS 70 stores the physical address of the exiting page in a register or variable referred to herein as "Source_Page_Address.” In other words, referring again to Figure 2 , OS 70 loads the location section of the physical address to Source_Page_Address. Also, as shown at block 216 of Figure 3B , OS 70 determines the physical address of the relevant portion of the MTM for the exiting page and stores that physical address in a register or variable referred to herein as "Tag_Map_Address.” For instance, OS 70 may load Tag_Map_Address with the address of the section of system MTM 80 that pertains to the exiting page.
  • OS 70 may allocate a new physical page to serve as temporary storage. For purposes of this disclosure, that new physical page may be referred to as the "destination page.” OS 70 then stores the physical address of the destination page in a register or variable referred to herein as "Destination_Page_Address,” as shown at block 220.
  • OS 70 then invokes a special tag management instruction to copy a page of data from the source page to the temporary destination page.
  • a special tag management instruction for purposes of this disclosure, that instruction is referred to as a "read_tagged_page" instruction.
  • OS 70 supplies the read_tagged_page instruction with the Source_Page_Address, the Tag_Map_Address, and the Destination_Page_Address.
  • the read_tagged_page instruction then uses the proper tag for each line to copy the data from each line in the source page to a corresponding line in the destination page. For instance, if the tag is a KeylD, the read_tagged_page instruction uses the proper key for each line to decrypt the data that is read from the source page before copying that data to the destination page.
  • tagged_line_addr ⁇ - set_tag (source_line_addr, tag) Add the tag to the tag section of the address of current source line.
  • data ⁇ - read_data(tagged_line_addr) Use the full address (with tag) to read the current line of data from the source page.
  • destination_line_addr ⁇ - destination_page_addr + i*64 Compute the address of current destination line within the destination page.
  • write_data (destination_line_addr, data) Write the line of data to the current destination line. Done
  • i*64 denotes the offset to the current line within the source page, since the size of each line in the example is 64 bytes. Accordingly, line 0 within the page starts at offset 0, the next line starts at offset 64 (0x40), the next at 128 (0x80), and so on, with the last line starting at offset 4032 (0xFC0). Accordingly, the read_tagged_page instruction iterates over 64 lines in a page (0 to 63), and in every iteration it adds 64 to the current address, as this is the size of a line in bytes. However, those numbers would change in examples using a different granularity or a different page size.
  • the read_tagged_page instruction enables OS 70 to read a page full of data that is protected with multiple different tags in RAM 14 and save that data to another location in memory (e.g., for COW), or to disk (or other NVS) (e.g., for a memory mapped file).
  • the read_tagged_page instruction includes the proper tag as part of the physical address for each line that is read, so that memory protection module 34 can use the proper tag when reading each line of data from RAM 14 (e.g., when performing the "read_data" function shown in the above pseudocode).
  • the above pseudocode illustrates a read_tagged_page instruction which uses the tag_map_addr to find the relevant tags for each line being read.
  • core 20A and/or memory controller 30 may store the tags for each line in each page of tagged memory in system MTM 80.
  • the tag_map_addr parameter may be omitted from the read_tagged_page instruction, and the instruction may simply determine the proper tags based on the source_page_addr.
  • OS 70 then copies the data from the temporary destination page to swap space 74 in NVS 18.
  • OS 70 may protect that data (e.g., by encrypting it with a different key or inherently protect the data using native encryption (e.g., by using technology that provides full disk encryption, such as the technology provided by Microsoft Corpopration under the name or trademark of "BitLocker") before copying that data to swap space 74.
  • native encryption e.g., by using technology that provides full disk encryption, such as the technology provided by Microsoft Corpopration under the name or trademark of "BitLocker
  • the OS may use a variant of the read_tagged_page instruction to perform a direct memory access (DMA) straight to disk, hence eliminating the temporary destination page.
  • DMA direct memory access
  • the read_tagged_page instruction may enable the OS to specify the location of the part of the swap file that is to receive the data being swapped out, and an operation like the one referred to above as "write_data (destination_line_addr, data)" may copy the data to NVS instead of memory.
  • OS 70 may also save the tags for the data that was saved, so that OS 70 may use those tags when subsequently swapping the page back into RAM 14.
  • OS 70 may use any suitable techniques for saving those tags. For instance, referring again to Figure 1 , OS 70 may save those tags in a swapped MTM 76, which may be stored in RAM 14 and/or in NVS 18. Swapped MTM 76 may identify the tags for each line in each page of tagged memory that has been swapped out for any process.
  • the process of Figure 3B may then return to Figure 3A through page connector A.
  • OS 70 may then continue to monitor conditions and determine whether more memory has been requested, whether another page should be swapped out, whether a page should be swapped in, or whether COW has been triggered, as indicated above. If OS 70 determines that a page should be swapped in, the process may pass from block 150 through page connector C to Figure 3C .
  • Figure 3C depicts an example of a process for swapping a page of tagged memory back in to RAM 14.
  • the example depicted in Figure 3C includes many details pertaining to specific data structures and operations. However, as described in greater detail below, other examples may provide enhanced low-level support for one or more operations, thereby simplifying the operations to be performed by the OS.
  • the process of Figure 3C may start with OS 70 allocating a new physical page to serve as temporary storage. (Or, as described in greater detail below, if DMA is used, temporary storage may not be needed.) For purposes of this disclosure, that new physical page may be referred to as the "source page.”
  • OS 70 then stores the physical address of the source page in a register or variable referred to herein as "Source_Page_Address,” as shown at block 312.
  • OS 70 copies the data for the page to be swapped in from swap space 74 to the temporary source page that was just allocated. Also, if OS 70 encrypted the data before saving it to swap space 74, OS 70 may decrypt the data before storing it to the source page.
  • OS 70 then populates a register or variable referred to herein as the "Destination_Page_Address" with the physical address of the location in RAM 14 that is to receive the page of data that is being swapped back in (i.e., the physical address of the "returning page"). For instance, OS 70 may populate the location section of the Destination_Page_Address with the address of the physical page to be used, while storing zeroes in the tag section of the destination page address.
  • Destination_Page_Address the physical address of the location in RAM 14 that is to receive the page of data that is being swapped back in (i.e., the physical address of the "returning page"). For instance, OS 70 may populate the location section of the Destination_Page_Address with the address of the physical page to be used, while storing zeroes in the tag section of the destination page address.
  • OS 70 also stores the physical address of the pertinent portion of the MTM for the returning page in a register or variable referred to herein as "Tag_Map_Address.” For instance, in one example, OS 70 uses the address of MTM 52A, or the address of the portion of MTM 52A that corresponds to the returning page. Alternatively, OS 70 may use the address of swapped MTM 76.
  • OS 70 then invokes a special tag management instruction to copy a page of data from the temporary source page to the destination page.
  • a special tag management instruction may be referred to as a "write_tagged_page" instruction.
  • OS 70 supplies the write_tagged_page instruction with the Source_Page_Address, the Tag_Map_Address, and the Destination_Page_Address.
  • destination_line_addr ⁇ - destination_page_addr + i*64 Compute the address of current destination line within the destination page.
  • tagged_line_addr ⁇ set_tag (destination_line_addr, tag) Add the tag to the address of current destination line within the destination page.
  • write_data (tagged_line_addr, data) Write tagged data to the destination line address.
  • the write_tagged_page instruction enables OS 70 to swap a page full of data into RAM 14 while applying the proper tag to each line within that page.
  • OS 70 encrypted the data in swap space 74
  • the "read_data" function shown in the above pseudocode may decrypt that data, if it was not decrypted before it was saved to the source page.
  • the tag for a line represents a KeylD
  • the "write_data" function shown in the above pseudocode may encrypt that data with the key identified by that KeylD.
  • the OS may use a variant of the write_tagged_page instruction to perform a DMA straight from disk, hence eliminating the temporary source page.
  • the write_tagged_page instruction may enable the OS to specify the location of the part of the swap file that contains the data being swapped in, and an operation like the one referred to above as "read_data (source_line_addr)" may read the data from NVS instead of memory.
  • OS 70, core 20A, and or memory controller 30 may then update system MTM 80 to identify the proper tag value for each line in the entering page.
  • OS 70 may then update page table 54A to map the entering page to the proper virtual address or addresses.
  • the process of Figure 3C may then return to Figure 3A through page connector A.
  • OS 70 may then continue to monitor conditions and determine whether more memory has been requested, whether another page should be swapped out, whether a page should be swapped in, or whether COW has been triggered. If OS 70 determines that COW has been triggered, the process may pass from block 160 through page connector D to Figure 3D .
  • Figure 3D depicts an example of a process for handling COW for a page of tagged memory. For purposes of illustration, that process is described below with regard to a hypothetical scenario involving processes 60A and 60B sharing a page of physical memory, as indicated above.
  • the process of Figure 3B may be triggered in response to process 60A executing an instruction which writes to that "shared page.”
  • OS 70 may then allocate a new physical page of memory.
  • OS 70 may then flush the TLBs for processes 60A and 60B and any pertinent caches.
  • OS 70 may then read the tags for the shared page from system MTM 80.
  • core 20A and memory controller 30 support a privileged instruction (e.g., "read_memory_metadata") to read memory metadata from ECM 16 (or from another form of hidden or sequestered memory that is not directly visible to the OS), given a specific physical address of data.
  • read_memory_metadata(phys_addr) returns the metadata for the line at the physical location "phys_addr" in memory.
  • that metadata may include a tag value such as a keylD, a MAC, etc.
  • OS 70 may use a special tag value to tell the memory controller not to read the actual data contents of the addressed memory location, but instead to read the associated ECC memory (or from another form of hidden or sequestered memory) for the given addressed memory and return that metadata.
  • This special tag value (or memory range) can be restricted so that only the OS, or a virtual machine monitor (VMM), or other privileged software may use it to get the tag values for a page, thus, preventing lower-privileged malicious software functions from just reading others' tag assignments.
  • VMM virtual machine monitor
  • OS 70 may then use those tags to read the shared page, one line at a time. For instance, of the tags are KeyIDs, memory protection module 34 may decrypt each line as it is read, using the key identified by the KeylD for that line. As shown at block 416, OS 70 may then also use those tags to write the content to the new page, one line at a time. For instance, if the tags are KeyIDs, memory protection module 34 may encrypt each line as it is written, using the key identified by the KeylD for that line. As shown at block 418, OS 70 may then update page table 64A to map the new physical page to one or more virtual pages of process 60A. As shown at block 420, OS 70 may then allow the write that was originally requested by process 60A to update the new page.
  • the tags are KeyIDs
  • memory protection module 34 may decrypt each line as it is read, using the key identified by the KeylD for that line.
  • OS 70 may then also use those tags to write the content to the new page, one line at a time. For
  • Some of the solutions or protections which software may implement using memory colors or memory tags according to the present disclosure include the following: physical corruption detection, out-of-bounds detection, use-after-free detection, heap coverage (with library support), stack coverage (with compiler support), inter-process/virtual machine (VM) corruption detection, and kernel/virtual machine monitor (VMM) corruption detection.
  • memory tags may be specified as parts of virtual memory addresses and/or physical memory addresses, and memory tags and/or other memory metadata may be stored in MTMs in RAM and/or in ECM or other sequestered memory.
  • a data processing system may provide memory protection with subpage granularity. Furthermore, the data processing system may maintain memory protection with subpage granularity when handling operations such as SI/SO and COW.
  • a data processing system may be configured to launch a process with memory tag protection for all of the memory used by that process, and not just the dynamically allocated memory.
  • the OS may assign a memory tag value to the initial block for the process before launching the process.
  • a device may include instructions and other data which, when accessed by a processor, cause the device to perform particular operations.
  • instructions which cause a device to perform operations may be referred to in general as software.
  • Software and the like may also be referred to as control logic.
  • Software that is used during a boot process may be referred to as firmware.
  • Software that is stored in nonvolatile memory may also be referred to as firmware.
  • Software may be organized using any suitable structure or combination of structures. Accordingly, terms like program and module may be used in general to cover a broad range of software constructs, including without limitation application programs, subprograms, routines, functions, procedures, drivers, libraries, data structures, processes, microcode, and other types of software components.
  • a software module may include more than one component, and those components may cooperate to complete the operations of the module. Also, the operations which the software causes a device to perform may include creating an operating context, instantiating a particular data structure, etc. Any suitable operating environment and programming language (or combination of operating environments and programming languages) may be used to implement software components described herein.
  • a medium which contains data and which allows another component to obtain that data may be referred to as a machine-accessible medium or a machine-readable medium.
  • software for multiple components is stored in one machine-readable medium.
  • two or more machine-readable media may be used to store the software for one or more components.
  • instructions for one component may be stored in one medium, and instructions another component may be stored in another medium.
  • a portion of the instructions for one component may be stored in one medium, and the rest of the instructions for that component (as well instructions for other components), may be stored in one or more other media.
  • software that is described above as residing on a particular device in one example may, in other examples, reside on one or more other devices.
  • some software may be stored locally, and some may be stored remotely.
  • operations that are described above as being performed on one particular device in one example may, in other examples, be performed by one or more other devices.
  • alternative examples include machine-readable media containing instructions for performing the operations described herein.
  • Such media may be referred to in general as apparatus and in particular as program products.
  • Such media may include, without limitation, tangible non-transitory storage components such as magnetic disks, optical disks, dynamic RAM, static RAM, read-only memory (ROM), etc., as well as processors, controllers, and other components that include data storage facilities.
  • ROM may be used in general to refer to nonvolatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc.
  • EPROM erasable programmable ROM
  • EEPROM electrically erasable programmable ROM
  • flash ROM flash memory
  • Such data processing systems may include, without limitation, accelerators, systems on a chip (SOCs), wearable devices, handheld devices, smartphones, telephones, entertainment devices such as audio devices, video devices, audio/video devices (e.g., televisions and set-top boxes), vehicular processing systems, personal digital assistants (PDAs), tablet computers, laptop computers, portable computers, personal computers (PCs), workstations, servers, client-server systems, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframe computers, mini-computers, and other devices for processing or transmitting information.
  • PDAs personal digital assistants
  • PCs personal computers
  • workstations servers, client-server systems, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframe computers, mini-computers, and other devices for processing or transmitting information.
  • references to any particular type of data processing system should be understood as encompassing other types of data processing systems, as well.
  • a data processing system may also be referred to as an apparatus.
  • the components of a data processing system may also be referred to as apparatus.
  • components that are described as being coupled to each other, in communication with each other, responsive to each other, or the like need not be in continuous communication with each other and need not be directly coupled to each other.
  • components of the data processing system may be implemented as adapter cards with interfaces (e.g., a connector) for communicating with a bus.
  • devices or components may be implemented as embedded controllers, using components such as programmable or non-programmable logic devices or arrays, ASICs, embedded computers, smart cards, and the like.
  • bus includes pathways that may be shared by more than two devices, as well as point-to-point pathways.
  • terms such as “line,” “pin,” etc. should be understood as referring to a wire, a set of wires, or any other suitable conductor or set of conductors.
  • a bus may include one or more serial links, a serial link may include one or more lanes, a lane may be composed of one or more differential signaling pairs, and the changing characteristics of the electricity that those conductors are carrying may be referred to as signals on a line.
  • processor denotes a hardware component that is capable of executing software.
  • a processor may be implemented as a central processing unit (CPU), a processing core, or as any other suitable type of processing element.
  • a CPU may include one or more processing cores, and a device may include one or more CPUs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Claims (11)

  1. Procédé de gestion d'étiquettes de mémoire granulaire de sous-pages dans un système de traitement de données, le procédé comprenant :
    en lien avec le transfert d'une page de données de la mémoire vive - RAM - (14) du système de traitement de données vers un stockage non-volatile - NVS - (18) du système de traitement de données, l'utilisation d'une carte d'étiquettes de mémoire - MTM - (76) pour appliquer des valeurs d'étiquettes de mémoire à des sous-pages respectives dans la page qui est transférée ;
    en lien avec le transfert de la page de données du NVS en retour vers la RAM, l'application de valeurs d'étiquettes de mémoire à des sous-pages respectives dans la page qui est retransférée vers la RAM ; et
    dans lequel ledit transfert d'une page de données comprend les étapes de :
    lecture, à l'aide d'une instruction lire_page_étiquetée, de données dans plusieurs sous-pages de mémoire étiquetée contenues dans une page source spécifiée vers une page de destination spécifiée, à l'aide d'une carte d'étiquettes de mémoire spécifiée, par, pour chaque sous-page de la page source spécifiée ;
    obtention, par un cœur de processeur, de la valeur d'étiquette de mémoire pour la sous-page à partir de la carte d'étiquettes de mémoire ;
    ajout, par le cœur de processeur, de cette valeur d'étiquette mémoire à l'adresse physique de la sous-page courante en tant que section étiquette d'une adresse étiquetée ;
    utilisation de cette adresse étiquetée pour lire la sous-page courante dans la page source, ladite lecture comprenant :
    envoi, par le cœur de processeur, de l'adresse étiquetée à un contrôleur de mémoire (30) ;
    retrait, par le contrôleur de mémoire, de l'étiquette de l'adresse étiquetée ;
    comparaison, par le contrôleur de mémoire, de l'étiquette à une valeur propre stockée dans la carte d'étiquettes de mémoire pour l'adresse physique dans l'adresse étiquetée, et si l'étiquette reçue du cœur de processeur correspond à la valeur propre, utilisation de cette étiquette en tant qu'étiquette propre pour l'obtention de ladite sous-page courante ; et
    utilisation de la sous-page qui a été lue dans la page source pour mettre à jour une sous-page correspondante dans la page de destination spécifiée,
    où, lors du transfert d'une page de données de la RAM vers le NVS, la page de destination spécifiée est une page de destination temporaire qui est copiée vers le NVS, ou un emplacement dans un fichier de transfert dans la mémoire NVS mappé pour un Accès OMA, et
    où, lors du transfert d'une page de données du NVS en retour vers la RAM, la page de destination spécifiée est l'adresse physique dans la RAM qui doit recevoir la page de données.
  2. Procédé selon la revendication 1, comprenant en outre, lorsqu'un processus accède à une sous-page particulière dans la page :
    le fait que le processus inclue la valeur d'étiquette de mémoire pour cette sous-page particulière en tant que partie d'une adresse virtuelle pour cette sous-page particulière ; et
    que le processus inclue également une valeur d'emplacement en tant que partie de l'adresse virtuelle pour cette sous-page particulière.
  3. Procédé selon la revendication 1, dans lequel:
    au moins l'une des valeurs d'étiquette de mémoire comprend une valeur d'étiquette qui a été spécifiée par une application tournant dans un processus sur le système de traitement de données ; et
    l'opération d'utilisation de la MTM pour appliquer des valeurs d'étiquette de mémoire à des sous-pages respectives de la page qui est transférée est exécutée au moins en partie par un système d'exploitation tournant sur le système de traitement de données.
  4. Procédé selon la revendication 1, comprenant en outre :
    la détermination automatique du fait qu'une copie sur écriture (COW) a ou non été déclenchée pour une page de données partagée dans la RAM, la page partagée étant partagée par un premier processus et un deuxième processus ;
    en réponse à la détermination du fait qu'une COW a été déclenchée pour la page de données partagée, l'utilisation de valeurs d'étiquette de mémoire associées à des sous-pages respectives de la page de données partagée pour copier les données vers une nouvelle page dans la RAM ; et
    la mise à jour d'une table de pages pour les premiers processus pour mapper la nouvelle page sur un espace d'adresse virtuelle pour le premier processus.
  5. Procédé selon la revendication 1, comprenant en outre :
    la tenue à jour automatique d'une MTM système qui identifie une valeur d'étiquette de mémoire propre pour chaque ligne physique de la mémoire étiquetée qui a été mappée sur une page virtuelle.
  6. Procédé selon la revendication 5, dans lequel la MTM système est stockée dans le système de traitement de données dans une mémoire séquestrée répondant au contrôleur de mémoire, la mémoire séquestrée n'étant pas accessible directement à un système d'exploitation (OS) du système de traitement de données.
  7. Procédé selon la revendication 6, dans lequel la mémoire séquestrée comprend une mémoire à code de correction d'erreur (ECC).
  8. Procédé selon la revendication 6, comprenant en outre :
    l'utilisation d'une instruction de lecture_métadonnées_mémoire privilégiée pour obtenir, à partir de la MTM système dans la mémoire séquestrée, une valeur d'étiquette de mémoire pour une sous-page dans la RAM, en réponse à la fourniture de l'instruction de lecture_métadonnées_mémoire avec l'adresse physique de cette sous-page.
  9. Procédé selon la revendication 1, dans lequel:
    les valeurs d'étiquette de mémoire comprennent au moins un identifiant de clé (KeyID) ;
    l'opération d'utilisation de valeurs d'étiquette de mémoire pour lire des données dans plusieurs sous-pages de mémoire étiquetée contenues dans une page source spécifiée comprend l'utilisation d'une clé correspondant à la KeyID pour déchiffrer les données ; et
    l'opération de mise à jour de la page de destination spécifiée comprend la copie des données déchiffrées sur la page de destination spécifiée.
  10. Support lisible par ordinateur comprenant des instructions informatiques qui, lorsqu'elles sont exécutées sur un système de traitement de données, permettent au système de traitement de données d'exécuter le procédé selon l'une quelconque des revendications 1 à 9.
  11. Système de traitement de données prenant en charge des étiquettes de mémoire granulaire de sous-pages, le système de traitement de données comprenant des moyens pour exécuter le procédé selon l'une quelconque des revendications 1 à 9.
EP20153932.7A 2019-02-28 2020-01-27 Technologie de gestion d'étiquettes de mémoire Active EP3702924B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/288,844 US11003584B2 (en) 2019-02-28 2019-02-28 Technology for managing memory tags

Publications (2)

Publication Number Publication Date
EP3702924A1 EP3702924A1 (fr) 2020-09-02
EP3702924B1 true EP3702924B1 (fr) 2023-01-04

Family

ID=66949538

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20153932.7A Active EP3702924B1 (fr) 2019-02-28 2020-01-27 Technologie de gestion d'étiquettes de mémoire

Country Status (3)

Country Link
US (1) US11003584B2 (fr)
EP (1) EP3702924B1 (fr)
CN (1) CN111625478A (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10884952B2 (en) * 2016-09-30 2021-01-05 Intel Corporation Enforcing memory operand types using protection keys
US11868273B2 (en) 2019-06-29 2024-01-09 Intel Corporation Memory protection with hidden inline metadata to indicate data type
US20210144170A1 (en) * 2019-11-09 2021-05-13 Indian Institute Of Science System and method for protection against side channel attacks
GB2594062B (en) * 2020-04-14 2022-07-27 Advanced Risc Mach Ltd Data integrity check for granule protection data
EP3916568A1 (fr) * 2020-05-29 2021-12-01 ARM Limited Appareil et procédé de vérification d'étiquette
CN112817775A (zh) * 2020-08-19 2021-05-18 北京辰信领创信息技术有限公司 多个实体高效同时利用有限共享的方法
TWI764771B (zh) * 2021-06-29 2022-05-11 群聯電子股份有限公司 跨框編碼管理方法、記憶體儲存裝置及記憶體控制電路單元
CN113434331B (zh) * 2021-07-05 2023-07-25 群联电子股份有限公司 跨框编码管理方法、存储器存储装置及存储器控制电路
US20230029331A1 (en) * 2021-07-26 2023-01-26 Microsoft Technology Licensing, Llc Dynamically allocatable physically addressed metadata storage
US11940927B2 (en) * 2022-06-14 2024-03-26 Intel Corporation Technologies for memory tagging
WO2024082232A1 (fr) * 2022-10-20 2024-04-25 华为技术有限公司 Procédé et appareil contrôle d'accès à la mémoire

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4922414A (en) * 1982-12-17 1990-05-01 Symbolics Inc. Symbolic language data processing system
US5335334A (en) * 1990-08-31 1994-08-02 Hitachi, Ltd. Data processing apparatus having a real memory region with a corresponding fixed memory protection key value and method for allocating memories therefor
US7734926B2 (en) * 2004-08-27 2010-06-08 Microsoft Corporation System and method for applying security to memory reads and writes
US10489309B2 (en) 2014-10-21 2019-11-26 Intel Corporation Memory protection key architecture with independent user and supervisor domains
US9870467B2 (en) * 2015-03-27 2018-01-16 Intel Corporation Apparatus and method for implementing a forked system call in a system with a protected region
US9904805B2 (en) * 2015-09-23 2018-02-27 Intel Corporation Cryptographic cache lines for a trusted execution environment
US10594491B2 (en) 2015-12-24 2020-03-17 Intel Corporation Cryptographic system memory management
US9990249B2 (en) * 2015-12-24 2018-06-05 Intel Corporation Memory integrity with error detection and correction
US10585809B2 (en) 2016-04-01 2020-03-10 Intel Corporation Convolutional memory integrity
US10235304B2 (en) 2016-10-01 2019-03-19 Intel Corporation Multi-crypto-color-group VM/enclave memory integrity method and apparatus
US10387305B2 (en) 2016-12-23 2019-08-20 Intel Corporation Techniques for compression memory coloring
US10896267B2 (en) * 2017-01-31 2021-01-19 Hewlett Packard Enterprise Development Lp Input/output data encryption
US10540297B2 (en) * 2017-08-03 2020-01-21 Arm Limited Memory organization for security and reliability
US10678636B2 (en) 2018-02-28 2020-06-09 Intel Corporation Techniques for detecting and correcting errors in data
US10684945B2 (en) 2018-03-29 2020-06-16 Intel Corporation System, apparatus and method for providing key identifier information in a non-canonical address space
US10838773B2 (en) 2018-03-30 2020-11-17 Intel Corporation Techniques for dynamic resource allocation among cryptographic domains
US11630920B2 (en) * 2018-06-29 2023-04-18 Intel Corporation Memory tagging for side-channel defense, memory safety, and sandboxing
US10877897B2 (en) * 2018-11-02 2020-12-29 Intel Corporation System, apparatus and method for multi-cacheline small object memory tagging
US11288213B2 (en) * 2019-03-29 2022-03-29 Intel Corporation Memory protection with hidden inline metadata

Also Published As

Publication number Publication date
US20190196977A1 (en) 2019-06-27
US11003584B2 (en) 2021-05-11
EP3702924A1 (fr) 2020-09-02
CN111625478A (zh) 2020-09-04

Similar Documents

Publication Publication Date Title
EP3702924B1 (fr) Technologie de gestion d'étiquettes de mémoire
US11636049B2 (en) Memory protection with hidden inline metadata
US20210374069A1 (en) Method, system, and apparatus for page sizing extension
EP3491520B1 (fr) Contrôle d'accès à des pages dans une mémoire dans un dispositif informatique
US6789156B1 (en) Content-based, transparent sharing of memory units
KR100881187B1 (ko) 하이브리드 하드 디스크 드라이브, 하이브리드 하드 디스크드라이브를 내장하는 컴퓨터 시스템, 그리고 하이브리드하드 디스크 드라이브의 플래시 메모리 ｄｍａ 회로
US8190914B2 (en) Method and system for designating and handling confidential memory allocations
CN112149143A (zh) 用于存储器标记的低存储器开销堆管理
KR930009062B1 (ko) 가상 메모리 장치를 갖는 계산장치
US7512767B2 (en) Data compression method for supporting virtual memory management in a demand paging system
US10169244B2 (en) Controlling access to pages in a memory in a computing device
US11847243B2 (en) Memory system
US10387305B2 (en) Techniques for compression memory coloring
US10877897B2 (en) System, apparatus and method for multi-cacheline small object memory tagging
JP2021512400A (ja) メモリ・アクセスにおける保護タグ・チェックの制御
US20170220482A1 (en) Manipulation of virtual memory page table entries to form virtually-contiguous memory corresponding to non-contiguous real memory allocations
US10909045B2 (en) System, method and apparatus for fine granularity access protection
US11726924B2 (en) Memory system for data encryption
CN116964564A (zh) 通过页重映射和旋转增加地址空间布局随机化熵
US11836094B2 (en) Cryptographic data objects page conversion
US20230393769A1 (en) Memory safety with single memory tag per allocation

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200929

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CHHABRA, SIDDHARTHA

Inventor name: CONG, KAI

Inventor name: DEUTSCH, SERGEJ

Inventor name: GREWAL, KARANVIR

Inventor name: DURHAM, DAVID M.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210922

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20220726

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602020007267

Country of ref document: DE

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1542464

Country of ref document: AT

Kind code of ref document: T

Effective date: 20230115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: FP

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1542464

Country of ref document: AT

Kind code of ref document: T

Effective date: 20230104

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230518

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230504

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230404

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230504

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230405

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230127

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20230131

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602020007267

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230131

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230131

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20230925

Year of fee payment: 5

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230131

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20230921

Year of fee payment: 5

26N No opposition filed

Effective date: 20231005

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20231102

Year of fee payment: 5

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230127

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20231220

Year of fee payment: 5

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230104