Patent Description:
Methods, systems and computer program products are provided for managing protection domains (PDs) for files at a file-level or a page-level. PDs may be allocated for multiple purposes, e.g., to protect processes, files, buffers, etc. Files stored in nonvolatile memory (NVM) subject to direct access (DAX) may be protected by file-level or page-level PDs. PDs may comprise protection keys (PKEYs) with user-configurable read and write access control registers (PKRUs). NVM files may be protected from corruption (e.g. by stray writes) by leaving write access disabled except for temporary windows of time for valid writes. File PDs may be managed by a file manager while buffer PDs may be managed by a buffer pool manager. File associations between PDs, files and file address space may be maintained in a file object. Buffer associations between PDs, buffers and buffer address space may be maintained in a buffer descriptor.

Further features and advantages of the invention, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

Advantageous embodiments and further developments are the subject-matter of the dependent claims. The in the following described exemplary embodiments merely serve to illustrate certain technical aspects for a better understanding of the claimed invention.

Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the discussion, unless otherwise stated, adjectives such as "substantially" and "about" modifying a condition or relationship characteristic of a feature or features of an example embodiment of the disclosure, are understood to mean that the condition or characteristic is defined to within tolerances that are acceptable for operation of the embodiment for an application for which it is intended.

Computers may comprise primary and secondary storage. Primary storage may comprise, for example, fast access, but typically volatile (e.g. temporary storage), memory devices, such as random access memory (RAM) internal to a processor (e.g. CPU cache) or external to and directly accessible by a processor (e.g. main memory). Compared to static RAM (SRAM), dynamic RAM (DRAM) may be less costly and use less power, but may need to be refreshed (e.g. thousands of times per second). Primary storage many include some non-volatile (e.g. permanent) memory (e.g. read-only memory (ROM) devices that store programs called firmware). Secondary storage may comprise, for example, slower access, but larger and non-volatile (e.g. permanent storage) memory devices that may be indirectly accessed by a processor, such as a hard disk drive (HDD), solid state drive (SSD), optical drive, ROM, flash memory, non-volatile memory (NVM) or other non-volatile storage. NVM may be the fastest type of secondary storage (e.g. nearly as fast or a few multiples slower than primary storage).

Computers may be programmed (e.g. with programs) to perform specified functions. An integrated program may comprise multiple programs. A program (e.g. an application) executed by one or more processors (e.g. CPUs) may be referred to as a process. A process may be divided into tasks (e.g. sequences of instructions) that may be executed (e.g. concurrently) as threads. Processes (and threads) may be assigned portions of memory to accomplish their respective functions or tasks. Computer hardware (e.g. a memory management unit (MMU)) and software (e.g. a memory management portion of an operating system (OS) program) may manage memory resources for processes. Primary (main) memory resources may be insufficient for all processes. Secondary memory may supplement primary memory to provide sufficient memory assigned to processes. Available primary and secondary memory may be discontinuous (fragmented).

Virtual memory may simplify processes by appearing to provide each process with its own continuous block of main memory, even though the virtual memory block may actually map to disparate portions of primary and/or secondary memory and even though the total virtual (primary) memory may exceed actual (physical) memory. Virtual memory may (e.g. in addition to simplifying processes) improve process security by isolating process memory. An OS virtual memory manager (VMM) and CPU MMU may manage memory for processes, including mapping from virtual addresses to physical addresses. A process may operate based on virtual memory specified by an OS while a CPU may interface with the OS to fetch and execute instructions from physical (e.g. primary or secondary) memory.

An OS virtual memory manager (VMM) may use paging, for example, to overcome primary memory limitations. A VMM may reserve space on secondary memory to virtually extend primary memory. The reserved area of secondary memory used by an OS as if it were primary memory may be referred to as a page (or paging) file. A VMM may move data between primary and secondary memory (e.g. to or from the paging file in secondary memory), for example, when a process references data stored on secondary memory. Transferring data between primary and secondary memory may be referred to as disc paging or swapping (e.g. paging-in from secondary to primary memory or paging-out from primary to secondary memory), although secondary memory is not limited to a disc. Demand paging may refer to allocating (paging/swapping) primary memory at a thread level, for example, for multiple concurrent processes when there is insufficient primary memory for full processes. A VMM may access (e.g. read or write) data between primary storage and secondary storage in blocks, which may be referred to as pages. Paging algorithms may implement one or more page sizes. Like physical memory, virtual memory may be divided into units called pages. A page may comprise a virtual entity that exists in the form of a page address in a page table. A page in virtual memory may correspond to a page frame array in physical memory.

An OS may maintain a virtual to physical address translation table called a page table for each process. An OS paging supervisor may manage page tables. A page table, which is a data structure, may map virtual page addresses (used by processes) to physical page addresses (used by hardware such as a CPU). A page table may comprise page addresses in an array. Indexes of the array may represent virtual page addresses. Array values (referred to as page table entries (PTEs)) may represent the corresponding page frame addresses in physical memory. A virtual address may comprise a page number (p) and an offset into a page (d). A physical address may comprise a frame number (f) and an offset (d). PTEs may (e.g. also) include process control information, which may indicate, for example, the state and attributes of a process memory, such as validity (e.g. to indicate whether the address refers to a page frame on physical memory), modified data (e.g. to indicate process data has been modified), access protection (e.g. to limit read and/or write access) and process identification. A page directory may reference each page table.

A CPU MMU may have a virtual to physical address translation cache, which may be referred to as a translation lookaside buffer (TLB). A TLB may store recently translated addresses for pages in the page table. An MMU may check the (e.g. faster) TLB before checking the page table. When the translated address exists in the TLB, it is called a TLB Hit, and when a page is not found, it is called a TLB Miss, leading to a page table access in memory and (e.g. if a mapping exists in the page table) writing the mapping to the TLB. A page fault may occur, for example, when a process references a page that is not present in primary memory. An OS may use a page replacement algorithm to determine which pages to swap between primary and secondary memory (e.g. for page faults and/or for swap prefetch).

Information in storage devices such as NVM subject to direct access (DAX) writes may be vulnerable to corruption, for example, by stray overwrites. In a typical storage system, stored data may be read and written in local storage. A write occurs to where a page is cached in RAM, before eventually being pushed out to storage (e.g. HDD), such that, if a stray write were to corrupt data in local storage, a correction may be made prior to pushing to storage. DAX access to NVM for buffer pool page writes and memory mapped file writes may eliminate caching data in local storage, which may (e.g. also) eliminate the opportunity to correct stray writes, leading to potential corruption of NVM files.

<FIG> shows a block diagram of an example computing environment <NUM> to manage protection domains for files, according to an example embodiment. Example computing environment <NUM> comprises server computer <NUM> and client computer(s) <NUM> coupled by network <NUM>. Features presented for one computer may be implemented on any computer. For example, features presented for server computer <NUM> may be implemented on client computer(s) <NUM> an any other computer.

Network <NUM> may comprise any computer network supporting interaction between client computer(s) <NUM> and server computer <NUM>, whether private and/or publicly accessible, and may support wired and/or wireless connectivity. For example, network <NUM> may include one or more of any of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a combination of communication networks, such as the Internet, and/or a virtual network. Server computer <NUM> and client computer(s) <NUM> may have at least one network interface. Examples of a network interface, wired or wireless, may include an IEEE <NUM> wireless LAN (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth™ interface, a near field communication (NFC) interface, etc. Further examples of network interfaces are described for <FIG>. Network <NUM> may be implemented using any available network communication protocol, such as, but not limited to, Ethernet and/or TCP/IP.

Server computer <NUM> and client computer(s) <NUM> may comprise any computing device. An example computing device is shown in <FIG>. Server computer <NUM> and client computer(s) <NUM> may represent any number of computing devices. Server computer <NUM> and client computer(s) <NUM> may comprise any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone, a wearable computing device, or other type of mobile device, or a stationary computing device such as a desktop computer or PC (personal computer), or a server. Server computer <NUM> and client computer(s) <NUM> are not limited to physical machines, but may include other types of machines or nodes, such as a virtual machine. Server computer <NUM> and client computer(s) <NUM> may comprise one or more applications, operating systems, program interfaces, network interfaces, virtual machines, storage devices, etc. that may be executed, hosted, and/or stored therein or via one or more other computing devices via network <NUM>.

Server computer <NUM> comprises, for example, buffer pool <NUM>, local memory <NUM>, buffer pool manager <NUM>, file manager <NUM>, protection domain (PD) manager <NUM>, non-volatile memory (NVM) <NUM>, transaction processor <NUM> and storage device <NUM>. <FIG> presents a simplified component diagram of server computer <NUM> that does not show or describe many hardware, firmware and software components that may be implemented on server computer <NUM> and other computers that may implement the subject matter described herein (e.g. protection domains for files at one or more levels).

Server computer <NUM> may store data (e.g. persistently) in persistent storage devices, such as storage device <NUM> and NVM <NUM>, which may be utilized as a persistent storage device in a manner similar to storage device <NUM>. Storage device <NUM> may comprise, for example, one or more disk-based storage and/or solid state storage devices (SSDs). Other examples are shown in <FIG>.

NVM <NUM> may have a lower latency, for example, than disk-based storage devices and SSD. Latency of a memory or storage device, as used herein, is the amount of time between the time a read request is received on an input and the time the requested data is provided on an output. In an example memory system, some forms of NVM that may be used as a persistent storage device may have a latency on the same order of magnitude as, or a small multiple of, latency of other memory devices that may be used as local memory <NUM>, such as dynamic random-access memory (DRAM) or static random-access memory (SRAM).

NVM <NUM> may comprise any of variety of nonvolatile memory technologies that may be referred to (e.g. interchangeably) as NVM, storage class memory (SCM), persistent memory (PMEM), direct access (DAX) memory, byte addressable storage, etc. A nonvolatile memory may be a computer storage device whose contents are not lost when power is removed. A device may be byte-addressable when a single, addressable unit of data, e.g., a byte, may be accessed without requiring access to neighboring units of data (e.g. without accessing a block such as a page of data). Memory may be considered storage class, for example, when it is sufficiently high capacity to persistently store data in an application, such as a file system or database system. Examples of NVM include, 3D-XPoint™ memory (available under the QuantX™ brand from Micron® Technology and OPTANE™ brand from Intel®) and NVDIMM memory modules from Hewlett Packard Enterprise™. Other examples of NVM include NAND and NOR flash memories, ferroelectric RAM (FeRAM, F-RAM or FRAM), programmable metallization cell (PMC) memory, conductive bridging RAM (CBRAM), phase-change RAM (PRAM or PCM), silicon-oxide-nitride-oxide-silicon (SONOS) memory, resistive RAM (RRAM or ReRAM), Racetrack or domain-wall memory (DWM), carbon nanotube based RAM (NRAM or Nano-RAM), and spin-transfer torque-magnetoresistive random-access memory (STT-MRAM).

Access to files in storage device <NUM> or NVM <NUM> may be buffered, for example, by copying files stored therein to page cache (e.g. local memory <NUM>). Copying to local memory <NUM> may be eliminated for data stored on NVM <NUM>. Applications may access NVM <NUM> like they do local memory <NUM>, which may eliminate paging blocks of data to/from local memory <NUM>, for example, as may occur back and forth between local memory <NUM> and storage device <NUM>. Applications (e.g. transaction processor <NUM>) may use system calls (e.g. memcpy(), memmap()) to access NVM <NUM>.

Local memory <NUM> may (e.g. generally) be volatile memory, which is computer memory that requires power to maintain stored information. Examples of volatile memory include SRAM and DRAM. SRAM may (e.g. generally) use six transistors to store a bit of information. SRAM maintains its state so long as it is powered. SRAM may have simple controls to read and write data given an input address. DRAM may (e.g. generally) use a single transistor and capacitor to store a bit of information. DRAM utilizes (e.g. regular) refresh signals to maintain its state. DRAM may have more complex interactions than SRAM for reading and writing data given an input address. Other examples of local memory <NUM> include, for example, volatile memory such as zero-capacitor RAM (Z-RAM) and capacitor-less twin-transistor RAM (TTRAM). In some implementations, local memory <NUM> may comprise a form of NVM.

Transaction processor <NUM> may comprise an application, such as Microsoft SQL Server®. Transaction processor <NUM> may be responsive to requests (e.g. from applications (not shown) on client computer(s) <NUM>) to process data (e.g. in a database or other storage that may be accessible by server computer <NUM>). Transaction processor <NUM> may access data from a database, for example, through buffer pool <NUM>. There may be multiple transaction processors <NUM>. Buffer pool manager <NUM> may assign one or more logical buffers in buffer pool <NUM> to (e.g. each) transaction processor <NUM>.

While <FIG> illustrates a server computer and transaction processor for a database application, this configuration is merely illustrative. Other computers and other applications may be utilized with protection domains (e.g. for buffers, files, processes and so on).

Buffer pool <NUM> may comprise a resource (e.g. shared by multiple databases) for cached data pages. Buffer pool <NUM> may comprise a portion of virtual address space allocated to an application (e.g. a database application such as Microsoft SQL Server®). Buffer pool <NUM> may cache recently or frequently used pages in buffers. In an example, there may be a buffer pool per instance of Microsoft SQL Server®.

Buffer pool <NUM> may reference an array of buffers. Buffer pool <NUM> may reference a larger array of buffers, for example, by directly referencing NVM <NUM> without caching (e.g. in local memory <NUM>) data stored in NVM <NUM>. A larger array of buffers may provide a larger working set, which may reduce page evictions, reduce a frequency of writing dirty pages to storage and increase transaction capacity and throughput. Buffer pages may be linked directly to NVM locations of database files. In other words, files on NVM may be mapped into memory direct to NVM without copying to RAM.

Buffer pool <NUM> may comprise a data structure that defines a collection of logical buffers in which data resides for access by applications, such as transaction processor <NUM>. A logical buffer may comprise a data structure (e.g. buffer descriptor) with (e.g. among other information) a state and a reference to a set of locations in memory. In an example memory system, memory locations of a buffer may refer to a local memory <NUM>, such as dynamic random-access memory (DRAM) or static random-access memory (SRAM), or NVM <NUM>, which may be used as a persistent storage device (e.g. for a file system or database system).

Memory location data in a logical buffer data structure may reference local memory <NUM> or NVM <NUM>, for example, when the state of a logical buffer permits read and/or write access. In a typical storage system, stored data may be read and written in local storage. A write occurs to where a page is cached in RAM, before eventually being pushed out to storage (e.g. HDD), such that, if a stray write were to corrupt data in local storage <NUM>, a correction may be made prior to pushing to storage device <NUM>. Direct write access to NVM <NUM> for buffer pool page reads and writes may eliminate caching data in local storage <NUM>, which may (e.g. also) eliminate the opportunity to correct stray writes, leading to potential corruption of NVM <NUM>.

Buffer pool manager <NUM> may manage buffer pool <NUM>. Buffer pool manager <NUM> may, for example, manage (e.g. allocate and free) data structures (e.g. buffer descriptors) and page frames for buffers. A buffer descriptor may describe a cached page and its state. A page frame may comprise memory (e.g. local memory <NUM> or NVM <NUM>) containing data referenced by a buffer descriptor. Buffer pool manager <NUM> may communicate with transaction processor <NUM>, for example, to determine which information (e.g. in storage device <NUM> and/or NVM <NUM>) buffer pool manager <NUM> should reference in buffer pool <NUM>, and what information to copy (e.g. from storage device <NUM>) into local memory <NUM>. Buffer pool manager <NUM> may allocate a page frame, for example, when a buffer without a page frame (e.g. in local memory <NUM> or NVM <NUM>) is referenced. Buffer pool manager <NUM> may create a buffer descriptor for a page frame. Buffer pool manager <NUM> may copy data from storage device <NUM> to local memory <NUM>, for example, when data is stored in storage device <NUM>. Buffer pool manager <NUM> may not copy data from NVM <NUM> to local memory <NUM>, for example, when data is stored in NVM <NUM>.

Transaction processor <NUM> may comprise an application (e.g. Microsoft SQL Server®). Transaction processor <NUM> may process requests (e.g. database queries) received from client computer(s) <NUM>. Transaction processor <NUM> may utilize (e.g. read and write) data in buffer pool <NUM>, for example, to process transactions. Transaction processor <NUM> may directly write to and read from NVM <NUM> without copying the data into local memory <NUM> and without significantly affecting performance. In various implementations, NVM latency be approximately the same (e.g. within <NUM> to <NUM>% above or below) or a relatively small multiple of (e.g. <NUM> to <NUM> times) local memory latency. Direct access to data in NVM <NUM> versus local memory <NUM> may not significantly impact performance considering the avoidance of caching data in NVM <NUM> in local memory <NUM>. In an example, NVM <NUM> may have a latency less than ten times the latency of local memory <NUM>. For example, NVM <NUM> (e.g. 3D-XPoint NVM) may have a latency of approximately <NUM> nanoseconds to <NUM> nanoseconds while local memory <NUM> (e.g. for DRAM) may have latencies, for example, in the range of <NUM> to <NUM> nanoseconds.

File manager <NUM> may manage files accessed by applications (e.g. transaction processor <NUM>). File manager <NUM> may memory map files stored in storage device <NUM> or NVM <NUM>. A memory-mapped file may contain the contents of a file in virtual memory. Mapping between a file and memory space enables an application (e.g. with one or more processes) to modify the file by reading and writing directly to the memory. Memory-mapped files (MMFs) may permit applications to access files on disk in the same way they access local memory (e.g. using pointers). A view of all or part of a file on storage device <NUM> or NVM <NUM> may be mapped to a range of addresses within a process's address space. The process may access the content of a memory-mapped file by referencing an address in the designated range of addresses.

File manager <NUM> may, for example, memory map file <NUM> stored on NVM <NUM>. Memory mapping a file (e.g. file <NUM>) for access by an application (e.g. transaction processor <NUM>) may involve file manager <NUM> (e.g. part of an OS) mapping a file (e.g. using CreateFileMapping() in Microsoft® Windows® or mmap() in Linux®) from address space in storage device <NUM> or NVM <NUM> to address space exposed to an application's virtual address space. Server computer <NUM> may use memory mapping and direct access (DAX) to access data stored in NVM <NUM>. A memory mapped file in NVM <NUM> may be treated as byte addressable storage. DAX may eliminate copying file <NUM> to page cache (e.g. local memory <NUM>) by enabling direct read and write access to files (e.g. file <NUM>) stored in NVM <NUM>. DAX may provide byte-addressable loads and stores to NVM in a persistent-memory-aware (PM-aware) file system. Memory mapped files may be mapped directly to virtual memory of an application with a byte-for-byte correlation between the two. An application may use pointers to operate on the data through normal loads and stores in a byte-addressable fashion. Although, in a PM-unaware file system, paging (rather than byte-addressable) operations may be performed. DAX in a PM-aware file system allows an OS kernel to configure direct load-store access to NVM for direct byte-level access. Applications (e.g. transaction processor <NUM>) may use system calls (e.g. memcpy(), memmap()) to access NVM <NUM>.

File manager <NUM> may maintain data structures for files. A File Control Block (FCB) is an example of a file system data structure. An FCB may maintain information about the state of an open file (e.g. similar to a buffer descriptor maintaining a state of a page portion of a file). In an example, a file object (e.g. FCB) may maintain information, such as a file handle, a file name, an address, a file size, a PD, PD access control information (e.g. address and current settings), a timestamp of a most recent modification, and so on. An FCB may reference memory locations for data stored in local memory <NUM> or NVM <NUM>. Although file manager <NUM> may be implemented in an operating system (OS), an FCB for a file may reside in process address space for an application that uses the file (e.g. transaction processor <NUM>), for example, rather than in OS memory address space.

Server computer <NUM> (e.g. database server) may have a subsystem (not shown) to provide data atomicity and durability while writing data, such as a subsystem that implements write-ahead logging (WAL) in association with writing data to a database. Buffer pool manager <NUM> may (e.g. also) include an algorithm that determines whether buffers in buffer pool <NUM> are freed to use for other data. A replacement algorithm may be referred to as a "page replacement algorithm," such as a least-recently used (LRU) replacement algorithm. Page replacement algorithms and WAL subsystems may be utilized with file protection domains and management thereof (e.g. using a buffer pool manager and/or a file manager) described herein.

An application (e.g. transaction processor <NUM>) may access data stored in buffer pool <NUM>. Buffer pool manager <NUM> may manage buffer pool <NUM>. An application (e.g. transaction processor <NUM>) may be assigned a range of memory locations in a virtual memory of a computer (e.g. server computer <NUM>). A memory manager (e.g. in an OS for the computer) may map the range of virtual memory locations to buffers in buffer pool <NUM>. Buffer pool manager <NUM> may determine which buffers are available or free, and which buffers are used.

An application (e.g. transaction processor <NUM>) may request access to data stored persistently in NVM <NUM>. File manager <NUM> may instruct a memory manager to perform memory mapping, where a range of addresses in the application's virtual address space may be mapped to a range within the data stored in NVM <NUM>. This correlation may permit applications to treat data (e.g. file <NUM>) as if it were in local memory. A memory manager may manage movement of data into and out of buffer pool <NUM> in a manner transparent to applications. A memory manager may transfer an address range of data in NVM <NUM> into an available buffer in buffer pool <NUM>, for example, when access to data in that range of data is requested by the application. Buffer pool manager <NUM> may, e.g., using a replacement algorithm, identify one or more buffers to be made free, e.g., for replacement. A variety of replacement algorithms may be used, such as an LRU algorithm, an example of which may be found in <NPL>.

Buffer pool manager <NUM> may not free a buffer associated with new or modified application data, for example, before logging a commit record for a transaction (e.g. a set of actions that are atomic and durable) to durable storage. Such buffers may be referred to as "dirty. " A buffer that contains data from a file or database that is intended to be modified, such as a file that has been open for write access, but where the data has not yet been modified, may be distinguished from a buffer with modified data. A buffer of unmodified data may be referred to as "ready to dirty. " Such data, and buffers including read-only data, may readily be made free by buffer pool manager <NUM>.

In database systems, and some file systems and some other computer systems, additional protocols may be used to ensure data atomicity and durability. For example, a database system may not allow a "dirty" buffer to be freed before logging a commit record for a transaction to durable storage. Atomicity, consistency, isolation, and durability (ACID) principles in transaction-oriented systems may support recovery in the event of failures include. Recovery principles may be embodied in commercial implementations of transactional database systems and other transaction-oriented systems, such as distributed file systems, distributed operating systems, relational database systems, object-oriented database systems, fault-tolerant computer systems, highly available computer systems, real-time operating systems, object-oriented operating systems, distributed data collection systems, and the like.

For example, a database server may implement WAL. Data in a dirty buffer may be written back to the same storage location in NVM <NUM> from where it was read. Log records representing changes to the data may (e.g. must) already be on durable storage before the changed data replaces the previous version of that data on nonvolatile storage. A system may not be allowed to write data from a dirty buffer to NVM <NUM> until undo portions of log records that describe the changes to the data have been written to durable storage. Details of an implementation of WAL may be found in <NPL>.

An I/O stack may contribute significant overhead to access information on storage device <NUM>. In contrast, DAX loads and stores to NVM <NUM> may significantly reduce latency and improve SQL CPU efficiency. However, malfunctions (e.g. stray writes directly to NVM) may corrupt a database file such as file <NUM>. File <NUM> may be at risk of corruption, for example, given direct write access to NVM <NUM> without writing to data in local memory <NUM> first then pushing out to NVM <NUM>. For example, an application, such as transaction processor <NUM> (e.g. SQL Linux or SQL Windows), may use memory mapping based DAX read and write accesses for NVM resident files such as file <NUM>.

Protection domains (PDs) may protect buffers (e.g. buffer pages) and/or files (e.g. at file or page level) from corruption (e.g. by a stray write access). A protected page may be associated with address space in local memory <NUM> or NVM <NUM>. A protected file may be associated with address space in NVM <NUM>. Embodiments with buffer and/or file protection domains (PDs) may be implemented, for example, transparent to page replacement algorithms and WAL.

PD manager <NUM> may reserve and allocate PDs. PD manager <NUM> may manage PDs for assignment to processes, pages, files, etc. PDs may be assigned, controlled and enforced to protect processes and/or data (e.g. buffer pages, memory mapped files at file or page levels and so on) from corruption and/or other undesirable access. PD manager <NUM> may, for example, allocate a set of PDs and disable access (e.g. write and/or read access) by a (e.g. each or every) process and/or thread to memory protected by a PD (e.g. even when there may not be any allocations at the time). In an example, a maximum number of PDs may be reserved or configured to protect process address spaces and/or for other purposes (e.g. protecting, at a file-level or page-level, memory mapped files stored on non-volatile memory). A PD may be freed and reassigned to a different process, file, page, etc. or may be concurrently assigned to multiple processes, files, pages, etc., for example, when the number of processes, files, pages, etc. exceeds the number of PDs. PD manager <NUM> may be implemented, for example in an operating system (OS), such as Windows® NT or Linux®.

PD manager <NUM> may, for example, reserve and allocate PDs, e.g., based on request/demand or predefined configuration. In an example, PD manager <NUM> may, for example (e.g. out of M PDs), reserve N PDs to protect processes, X PDs to protect pages and Y PDs to protect files. Buffer pool manager <NUM> may, for example, manage the X PDs to protect pages. Buffer pool manager <NUM> may manage one or more of the X PDs, for example, to protect files at a page-level. File manager <NUM> may manage Y PDs to protect files at a file level. In an example, PD manager <NUM> may allocate N PDs to a library OS executed in user space with multiple application processes, where the library OS may manage the N process PDs. In an example, an application (e.g. transaction processor <NUM> such as Microsoft SQL Server®) may be executed with a library OS in a host OS process that shares memory in user mode, in which case multiple processes may be protected by process PDs, buffers may be protected by buffer PDs and/or memory mapped files may be protected by file PDs at file or page levels. Process, buffer and file PDs may overlap or nest. Overlapping PDs may operate together (e.g. a process PD may operate independent of a buffer PD) or may override one another (e.g. a PD associated with a narrow (subrange) address space may override a PD associated with a larger address space).

A page protection key (PKEY) is an example of a PD. A PKEY may provide a user-accessible, page-level procedure to grant and revoke access permission without impacting performance (e.g. without changing page tables). PKEYs may be used with or without page-based memory permissions in page tables. In contrast to PKEY type PDs, changing permissions in page tables may involve time-consuming system calls, TLB shoot downs and misses.

In an example of a PKEY (e.g. as a userspace feature in Intel® Skylake™ Scalable Processor Server CPUs), a page table entry (PTE) may support multiple (e.g. <NUM>) protection domains (e.g. <NUM> bit PKEY in a <NUM> bit PTE). A PKEY may be allocated (e.g. prior to use), for example, by using a pkey_alloc() system call in Linux, which may, for example, "tag" an address space (e.g. a page in a page table) with a selected PKEY. A pkey_mprotect system call in Linux may be used to designate access control (e.g. read access, write access) for address space associated with a PKEY. A pkey_free system call in Linux may free a process, buffer or file and its associated address space (e.g. disassociate it with a PKEY). Permissions may be specified for a (e.g. each) protection domain (PKEY), for example, in a thread-private userspace CPU register, referred to as PKRU. As a CPU register, a PKRU may be thread-local, which may provide a (e.g. each) thread a different set of protections from every other thread for the same memory pages. PKRU permissions may be accessed, for example using read and write instructions (e.g. RDPKRU and WRPKRU). In an example memory access, a PTE in a page table lookup may provide a protection domain (PKEY) for an access while PKRU register content may provide a corresponding domain-specific permission (e.g. to determine whether access permission and write permission are enabled or disabled).

A buffer (e.g. regardless whether it references local memory <NUM> or NVM <NUM>) may be protected from access (e.g. unauthorized access or overwrite corruption) by a PD (e.g. PKEY). Similarly, a PD may be used to protect file <NUM> at a page level (e.g. as shown in <FIG>) or a file level (e.g. as shown in <FIG>). Buffer and file PDs may be managed, respectively, by buffer pool manager <NUM> and file manager <NUM>.

Buffer pool manager <NUM> may, for example, manage (e.g. assign and configure) buffer (e.g. page-level) PDs. PDs may be allocated, for example, on demand. Buffer pool manager <NUM> may associate a PD with a buffer (e.g. buffer page), creating a buffer PD. Buffer pool manager <NUM> may associate a buffer PD (e.g. a PKEY) with an address space. In an example, a buffer object (e.g. buffer descriptor) may indicate an association between a page PD and an address space associated with a buffer page. Buffer pool manager <NUM> may set and enforce protections for a protection domain that protects a buffer page.

File manager <NUM> may, for example, manage (e.g. assign and configure) file (e.g. page-level) PDs. PDs may be allocated, for example, on demand. File manager <NUM> may associate a PD with a file, creating a file PD, and protect the file at a file or page level. File manager <NUM> may associate a file PD (e.g. a PKEY) with an address space. In an example, a file object (e.g. file control block) may indicate an association between a file PD and an address space associated with a file. file manager <NUM> may set and enforce protections for a protection domain that protects a file.

<FIG> shows an example of protecting a file at a page-level, according to an example embodiment. <FIG> shows an example of buffer protection domains, including protection of a file at a page-level. <FIG> shows a block diagram of example data structure <NUM> for buffer pool <NUM>. Buffer pool <NUM> shows an example of buffer pool <NUM> comprising buffers that may be associated with PDs, which may be managed by a buffer pool manager (e.g. buffer pool manager <NUM>).

Buffer pool <NUM> may comprise a data structure that defines a collection of logical buffers <NUM>, <NUM>, etc. Buffer pool <NUM> may comprise a paged buffer pool. A buffer pool data structure may use any suitable structure to represent a collection of logical buffers, such as an array (e.g. of page buffers). A logical buffer may reference memory locations (e.g. for pages of data stored) in local memory <NUM> (such as DRAM) or in NVM <NUM>. In an example, first logical buffer <NUM> may reference local memory <NUM> and second logical buffer <NUM> may reference NVM <NUM>. In an example, there may be tens of thousands of pages per file in NVM <NUM>. A (e.g. each) logical buffer may be represented by a data structure, which may be referred to as a buffer descriptor. In an example (e.g. as shown in <FIG>), first logical buffer <NUM> may be represented by first buffer descriptor <NUM> and second logical buffer <NUM> may be represented by second buffer descriptor <NUM>.

A buffer descriptor may include, for example, data defining a buffer state, a reference to memory locations, such as a pointer, among other information, such as a protection domain (PD), protection state (e.g. read and/or write access settings) and/or protection control information (e.g. PKRU address bits). A buffer state may be selected from a set of possible states of the buffer, including, for example, read-only, ready to dirty, dirty (e.g. data in the buffer has been modified or is new and is not yet written to persistent storage), or other state. A reference in a buffer descriptor to memory locations may be a reference to memory locations in local memory <NUM> or in NVM <NUM>. A buffer descriptor may have one or more memory location fields. In an example, a buffer descriptor may have multiple memory location references (e.g. a first reference to local memory <NUM> and a second reference to NVM <NUM>).

In an example, buffer pool manager <NUM> may associate a first buffer PD (e.g. PD <NUM>) with a first buffer (e.g. buffer <NUM>) and a second buffer PD (e.g. PD <NUM>) with a second buffer (e.g. buffer <NUM>). Buffer pool manager <NUM> may associate (e.g. in first buffer descriptor <NUM>) the first buffer PD (e.g. PD <NUM>) with a first address space (e.g. memory locations <NUM>) associated with the first buffer (e.g. buffer <NUM>). Buffer pool manager <NUM> may associate (e.g. in a second buffer descriptor <NUM>) the second buffer PD (e.g. PD <NUM>) with a second address space (e.g. memory locations <NUM>) associated with the second buffer (e.g. buffer <NUM>).

First buffer descriptor <NUM>, representing first logical buffer <NUM>, may include, for example, first buffer state <NUM>, first memory locations <NUM> and first protection domain <NUM> (e.g. alone or combined with other information, such as protection state and/or protection control information). First memory locations <NUM> may, for example, reference memory locations storing a page of data. First memory locations <NUM> may comprise, for example, an address pointer to data in local memory <NUM>.

Second buffer descriptor <NUM>, representing second logical buffer <NUM>, may include, for example, second buffer state <NUM>, second memory locations <NUM> and second protection domain <NUM> (e.g. alone or combined with other information, such as protection state and/or protection control information). Second memory locations <NUM> may, for example, reference memory locations storing a page of data. Second memory locations <NUM> may comprise, for example, an address pointer to data in NVM <NUM>.

Buffer pool manager <NUM> may manage buffer PDs, for example, by assigning and reassigning first and second buffer PDs <NUM>, <NUM> to various buffers in buffer pool <NUM> according to buffer PD assignment logic. Buffer PD assignment logic may be based on, for example, whether a buffer references address space in NVM <NUM>. In examples, buffer PD assignment logic may be randomly assigned to buffers or to buffers accessed by a process. In an example, second logical buffer <NUM> may be assigned second PD <NUM> because second memory locations <NUM> reference file <NUM> in NVM <NUM>. An association between second PD <NUM> and second logical buffer <NUM> may be used to create an association between PD <NUM> and second memory locations <NUM> in second buffer descriptor <NUM>.

In an example, second buffer PD <NUM> may comprise a PKEY. Buffer pool manager <NUM> may manage second buffer PD <NUM>, for example, by disabling access (e.g. write access) to second memory locations <NUM> that reference address space storing at least a portion of file <NUM> in NVM <NUM>. Buffer pool manager <NUM> may enable access (e.g. write access) to memory locations <NUM> for a window of time before and after a permitted access (e.g. a specific call), such as write access through a call stack by an application (e.g. transaction processor <NUM>). Buffer pool manager <NUM> may control access by controlling PKRU read and write access control bits for second PD <NUM>. For example, right before a write to file <NUM>, buffer pool manager <NUM> may set a PKRU write access bit for second PD <NUM> to enable write access, perform a mem copy then, right after the mem copy, set the PKRU write access bit for second PD <NUM> to disable write access. Disabling access (e.g. write access) to memory locations <NUM> referencing address space in NVM <NUM> most of the time may substantially reduce the probability of errant corruption of NVM <NUM>. In an example, tens to hundreds of databases may comprise NVM storage storing millions of files. A number of PDs may be limited. A PD may be assigned (e.g. alternatively or concurrently) to one or more buffers. A limited number of PDs may be sufficient to fend off a vast majority of potential errant corruptions by substantially reducing probabilities of errant corruptions.

<FIG> shows an example of protecting a file at a file-level, according to an example embodiment. Example file system <NUM> shows an example of file protection domains that protect a file at a file-level. File manager <NUM> may be part of an OS. File manager <NUM> may be implemented, for example, as part of an OS (e.g. a host OS, a library OS, a host (e.g. host OS) extension (HE), SQL OS) and/or as part of an application (e.g. SQL Linux, SQL Windows). File manager <NUM> may generate file objects (e.g. file object <NUM>) for open instances of files (e.g. file <NUM>). File objects may be used for interaction between buffer pool <NUM> and NVM <NUM>.

File manager <NUM> may manage (e.g. assign and configure) file PDs. File manager <NUM> may allocate file PDs, for example, on demand. File manager <NUM> may manage file PDs (e.g. PD <NUM>), for example, by assigning and reassigning file PDs to various files in NVM <NUM> (and/or other NVMs) according to file PD assignment logic. File PD assignment logic may be based on, for example, whether a file references address space in NVM <NUM>. In examples, file PD assignment logic may be randomly assigned to files or to files accessed by a process. An association between file PD <NUM> and file <NUM> may be used to create an association between PD <NUM> and file memory locations <NUM> in file object <NUM>.

In an example, tens to hundreds of databases may comprise NVM storage storing millions of files. A number of PDs may be limited. A PD may be assigned (e.g. alternatively or concurrently) to one or more files. In an example, such as when a number of files exceeds a number of PDs allocated for files accessed by applications, PD <NUM> may be (e.g. alternatively or concurrently) assigned to multiple files. A limited number of file PDs may be sufficient to avoid a vast majority of potential errant corruption by substantially reducing probabilities of errant corruption.

File manager <NUM> may manage files (e.g. file <NUM>) stored on NVM <NUM>, for example, to support access to the files by applications (e.g. transaction processor <NUM>) and to support buffering pages of data in buffer pool <NUM>. File manager <NUM> may memory map file <NUM>, for example, using CreateFileMapping() in Windows® or mmap() in Linux®, from address space in NVM <NUM> to address space exposed to an application's virtual address space. Files may be memory mapped automatically, for example, when stored on NVM. A view of all or part of address space occupied by file <NUM> on NVM <NUM> may be mapped to a range of addresses within an application's address space.

In an example (e.g. using PKEYs in a computer running Linux OS), one or more PKEYs may be allocated for files, for example, by using pkey_alloc(). File <NUM> may be memory mapped, for example, by calling pkey_mprotect with the address range (memory locations <NUM>) of all or a portion of file <NUM> to be mapped to associate memory locations <NUM> with the PKEY. File object (e.g. FCB) <NUM> may be saved with file information <NUM> (e.g. file handle, file name, file size, PKRU access control information for PKEY, PKRU current settings, a timestamp of a most recent modification, and so on), memory locations <NUM> (e.g. address pointer, address range(s)), PD (e.g. PKEY) <NUM>. PD (e.g. PKEY) may be freed to make it available for other allocations, for example, using pkey_free().

File manager <NUM> may manage memory mapped files, for example, using file objects. In an example, file manager <NUM> may create file object <NUM> to manage file <NUM>. File object <NUM> may comprise an FCB, which may reside in process address space for an application that uses the file (e.g. transaction processor <NUM>). File manager <NUM> may associate a PD (e.g. PD <NUM>) with file <NUM>. File manager <NUM> may associate file PD (e.g. PKEY) <NUM> with an address space. In an example, file object (e.g. FCB) <NUM> created by file manager <NUM> may indicate an association between a file PD (e.g. PD <NUM>) and an address space (e.g. memory locations <NUM>) associated with a file (e.g. file <NUM>).

File object <NUM> may maintain information about the state of file <NUM>. In an example, file object <NUM> may maintain information, such as a file handle, a file name, an address space storing the file (e.g. memory locations <NUM>), a file size, a PD (e.g. PD <NUM>), PD access control information (e.g. PD access control address and current settings), a timestamp of a most recent modification, and so on. PD <NUM> may comprise a PKEY. PD access control information may comprise PKRU read and write access control bits for the PKEY.

Memory-mapped file <NUM>, represented by file object <NUM>, may be addressable in virtual address space for an application, permitting the application to modify memory mapped file <NUM> by reading and writing directly to address space on NVM <NUM> in the same way the application accesses local memory. An application may use direct access (DAX) to access memory mapped file <NUM>. An application may treat memory mapped file <NUM> as byte addressable storage. DAX may eliminate copying file <NUM> to page cache (e.g. local memory <NUM>) by enabling direct read and write access to file <NUM>. Applications (e.g. transaction processor <NUM>) may use a memory copy call (e.g. memcpy(), memmap()) to access (e.g. read and write) file <NUM>.

File <NUM> may be protected (e.g. by protecting address space storing the file) at a file level or a page level. File object <NUM> may be utilized in support of protecting a file a file level or a page level. File manager <NUM> and/or an application (e.g. transaction processor <NUM>) using file <NUM> may set and enforce protections for file PD <NUM>. In an example process to protect a file with a PD, write access may be mostly disabled, with temporarily enablement of write access to an address range storing file <NUM> for a valid write (e.g. a write by an application that goes through a proper call stack).

In an example, file PD <NUM> may comprise a PKEY. File manager <NUM> (or an application accessing file <NUM>) may manage access to a file <NUM> by controlling access associated with file PD <NUM>. Access may be controlled, for example, by disabling access (e.g. write access) to file memory locations <NUM> that reference address space storing all or a portion of file <NUM> in NVM <NUM>. File manager <NUM> may enable access (e.g. write access) to file memory locations <NUM> for a window of time before and after a permitted access, which may comprise a write access through a proper call stack by an application (e.g. transaction processor <NUM>). File manager <NUM> (or application <NUM>) may control access to file <NUM>, for example, by controlling PKRU read and write access control bits for file PD <NUM>. In an example, right before a write to file <NUM>, file manager <NUM> (or application <NUM>) may set a PKRU write access bit for file PD <NUM> to enable write access to memory locations <NUM>, perform a mem copy to complete the write then, right after the mem copy, set the PKRU write access bit for file PD <NUM> to disable write access to memory locations <NUM>. Disabling access (e.g. write access) to file memory locations <NUM> referencing address space in NVM <NUM> most of the time may substantially reduce the probability of errant corruption of file <NUM>.

Implementations are not limited to the examples shown. Any number of computing devices and/or servers (including but not limited to machines and/or virtual machines) may be coupled in any manner via any type of computing environment. For example, one or more of computing device, server or storage components may be co-located, located remote from each other, combined or integrated on or distributed across one or more real or virtual machines. For example, authentication server <NUM> may include an authorization server. Example system <NUM> or components therein may operate, for example, according to example methods presented in <FIG>.

Embodiments may also be implemented in processes or methods. For example, <FIG> shows a flowchart of a method for managing protection domains, according to an example embodiment. Embodiments disclosed herein and other embodiments may operate in accordance with example method <NUM>. Method <NUM> comprises steps <NUM>-<NUM>. However, other embodiments may operate according to other methods. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the foregoing discussion of embodiments. No order of steps is required unless expressly indicated or inherently required. There is no requirement that a method embodiment implement all of the steps illustrated in <FIG> is simply one of many possible embodiments. Embodiments may implement fewer, more or different steps.

Method <NUM> is an example of managing PDs for multiple (e.g. configurable) purposes (e.g. processes, files at buffer page-level or file-level). Method <NUM> comprises step <NUM>. In step <NUM>, PDs may be allocated. For example, N PDs may be allocated as process PDs and M PDs may be allocated as file PDs or buffer PDs. N may be an integer value of zero or more and M may be an integer value of zero or more. A combined value of N and M may be limited by a maximum number of PDs available for allocation. For example, as shown in <FIG>, PD manager <NUM> may allocate PDs based on allocation logic. PD allocation logic may depend on an implementation (e.g. sandboxed implementation of an application with a library OS).

In step <NUM>, an election or determination may be made to protect a memory mapped file with a PD at a file-level by a file manager and/or at a page-level by a buffer manager. For example, as shown in <FIG>, server computer <NUM> (e.g. its OS) may be configured to protect memory mapped files with PDs at a page level with buffer pool manager <NUM> or at a file-level with file manager <NUM>.

<FIG> shows a flowchart of a method for managing protection domains for files at a file-level, according to an example embodiment. Embodiments disclosed herein and other embodiments may operate in accordance with example method <NUM>. Method <NUM> comprises steps <NUM>-<NUM>. However, other embodiments may operate according to other methods. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the foregoing discussion of embodiments. No order of steps is required unless expressly indicated or inherently required. There is no requirement that a method embodiment implement all of the steps illustrated in <FIG> is simply one of many possible embodiments. Embodiments may implement fewer, more or different steps.

Method <NUM> comprises step <NUM>. In step <NUM>, a file stored in persistent memory (PM) may be memory mapped to create a memory mapped file. For example, as shown in <FIG> and <FIG>, file <NUM> stored in NVM <NUM> may be mapped to virtual address space for an application (e.g. transaction processor <NUM>), creating a memory mapped file represented by file object <NUM>.

In step <NUM>, a file association may be created between the memory mapped file and a protection domain (PD). For example, as shown in <FIG>, a file association is created by associating PD <NUM> with memory mapped file <NUM>.

In step <NUM>, a memory association may be created between the PD and an address range of the memory mapped file based on the file association. For example, as shown in <FIG>, a memory association is created by associating PD <NUM> with memory locations <NUM> for memory mapped file <NUM>, based on the file association between PD <NUM> and memory mapped file <NUM>.

In step <NUM>, a file object may be created for the memory mapped file and the file association and the memory association may be stored in the file object. For example, as shown in <FIG>, file object <NUM> is created for memory mapped file <NUM>. The file association between file <NUM> and PD <NUM> and the memory association between PD <NUM> and memory locations <NUM> are stored in file object <NUM>.

<FIG> shows a flowchart of a method for controlling access to a protection domain for a file at a file-level, according to an example embodiment. Embodiments disclosed herein and other embodiments may operate in accordance with example method <NUM>. Method <NUM> comprises steps <NUM>-<NUM>. However, other embodiments may operate according to other methods. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the foregoing discussion of embodiments. No order of steps is required unless expressly indicated or inherently required. There is no requirement that a method embodiment implement all of the steps illustrated in <FIG> is simply one of many possible embodiments. Embodiments may implement fewer, more or different steps.

Method <NUM> comprises step <NUM>. In step <NUM>, write access may be disabled for a file PD. For example, as shown in <FIG> and <FIG>, file manager <NUM> or <NUM> or transaction processor <NUM> may disable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to disabled, e.g., based on PKRU control information in file object <NUM>.

In step <NUM>, temporary write access may be enabled for the PD responsive to an authorized write to the memory mapped address range. For example, as shown in <FIG> and <FIG>, file manager <NUM> or <NUM> or transaction processor <NUM> may temporarily enable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to enabled, e.g., based on a valid write access.

In step <NUM>, write access may be disabled for the PD after the authorized write. For example, as shown in <FIG> and <FIG>, file manager <NUM> or <NUM> or transaction processor <NUM> may disable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to disabled, e.g., after completion of a memory copy call to file <NUM>.

In step <NUM>, write access may be denied to the address range of the memory mapped file based on the disabled write access for the PD or an unauthorized attempt to write to the address range of the memory mapped file. For example, as shown in <FIG> and <FIG>, file manager <NUM> or <NUM> may deny write access to file <NUM> based on association with PD <NUM> and its PKRU write access bit set to disabled, as may be indicated in file object <NUM>.

<FIG> shows a flowchart of a method for managing protection domains for files at a page-level, according to an example embodiment. Embodiments disclosed herein and other embodiments may operate in accordance with example method <NUM>. Method <NUM> comprises steps <NUM>-<NUM>. However, other embodiments may operate according to other methods. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the foregoing discussion of embodiments. No order of steps is required unless expressly indicated or inherently required. There is no requirement that a method embodiment implement all of the steps illustrated in <FIG> is simply one of many possible embodiments. Embodiments may implement fewer, more or different steps.

Method <NUM> comprises step <NUM>. In step <NUM>, a buffer association may be created between the buffer and a protection domain (PD). For example, as shown in <FIG>, a buffer association may be created by associating PD (e.g. PKEY) <NUM> with buffer <NUM>.

In step <NUM>, a memory association may be created between the PD and an address range referenced by the buffer data structure based on the buffer association. For example, as shown in <FIG>, a memory association may be created by associating PD <NUM> with memory locations <NUM> for memory mapped file <NUM>, based on the buffer association between PD <NUM> and buffer <NUM>.

In step <NUM>, a buffer data structure may be created for the buffer and the buffer association and the memory association may be stored in the buffer data structure. For example, as shown in <FIG>, buffer descriptor <NUM> may be created for buffer <NUM>. The buffer association between buffer <NUM> and PD <NUM> and the memory association between PD <NUM> and memory locations <NUM> may be stored in buffer descriptor <NUM>.

<FIG> shows a flowchart of a method for controlling access to a protection domain for a file at a page-level, according to an example embodiment. Embodiments disclosed herein and other embodiments may operate in accordance with example method <NUM>. Method <NUM> comprises steps <NUM>-<NUM>. However, other embodiments may operate according to other methods. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the foregoing discussion of embodiments. No order of steps is required unless expressly indicated or inherently required. There is no requirement that a method embodiment implement all of the steps illustrated in <FIG> is simply one of many possible embodiments. Embodiments may implement fewer, more or different steps.

Method <NUM> comprises step <NUM>. In step <NUM>, write access may be disabled for a buffer PD. For example, as shown in <FIG>, buffer pool manager <NUM> or <NUM> or transaction processor <NUM> may disable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to disabled, e.g., based on PKRU control information in buffer descriptor <NUM>.

In step <NUM>, temporary write access may be enabled for the PD responsive to an authorized write to the buffer data structure address range comprising a memory mapped address range. For example, as shown in <FIG>, buffer pool manager <NUM> or <NUM> or transaction processor <NUM> may temporarily enable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to enabled, e.g., based on a valid write access.

In step <NUM>, write access may be disabled for the PD after the authorized write. For example, as shown in <FIG>, buffer pool manager <NUM> or <NUM> or transaction processor <NUM> may disable write access to file <NUM> protected by PD (e.g. PKEY) <NUM> by setting PKRU write access bit for PKEY <NUM> to disabled, e.g., after completion of a memory copy call to file <NUM>.

In step <NUM>, write access may be denied to the buffer data structure address range comprising the memory mapped address range based on the disabled write access for the PD or an unauthorized attempt to write to the address range of the memory mapped file. For example, as shown in <FIG>, buffer pool manager <NUM> or <NUM> may deny write access to file <NUM> based on association with PD <NUM> and its PKRU write access bit set to disabled, as may be indicated in buffer descriptor <NUM>.

As noted herein, the embodiments described, along with any modules, components and/or subcomponents thereof, as well as the flowcharts/flow diagrams described herein, including portions thereof, and/or other embodiments, may be implemented in hardware, or hardware with any combination of software and/or firmware, including being implemented as computer program code configured to be executed in one or more processors and stored in a computer readable storage medium, or being implemented as hardware logic/electrical circuitry, such as being implemented together in a system-on-chip (SoC), a field programmable gate array (FPGA), and/or an application specific integrated circuit (ASIC). A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.

<FIG> shows an exemplary implementation of a computing device <NUM> in which example embodiments may be implemented. Consistent with all other descriptions provided herein, the description of computing device <NUM> is a non-limiting example for purposes of illustration. Example embodiments may be implemented in other types of computer systems, as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing components and steps shown in examples and/or other example embodiments.

Example embodiments are also directed to such communication media that are separate and non-overlapping with embodiments directed to computer-readable storage media.

Such computer programs, when executed or loaded by an application, enable computing device <NUM> to implement features of example embodiments described herein.

Example embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium.

In an example, a computing device may comprise one or more processors; and one or more memory devices that store program code configured to be executed by the one or more processors. The program code may comprise at least one of a file manager and a buffer manager. The file manager many be configured to memory map a file stored in persistent memory (PM) to create a memory mapped file; create a file association between the memory mapped file and a file protection domain (PD); and create a file memory association between the file PD and an address range of the memory mapped file based on the file association, wherein the file PD is configurable to control write access to the address range of the memory mapped file. The buffer manager may be configured to: create a buffer association between the buffer and a buffer PD; and create a buffer memory association between the buffer PD and an address range for the buffer based on the buffer association, wherein the buffer PD is configurable to control write access to the address range for the buffer.

In an example, the computing device comprises the file manager and the buffer manager and the address range for the buffer references at least a portion of the memory mapped file, and the program code further comprises: at least one of an application, an operating system and an operating system extension configured to determine whether to protect the memory mapped file with a PD at one of a file-level by the file manager and at a page-level by the buffer manager.

In an example, the file manager may be configured to: disable write access for the file PD; enable temporary write access for the file PD responsive to an authorized write to the memory mapped address range; and disable write access for the file PD after the authorized write.

In an example, the buffer manager may be configured to: disable write access for the buffer PD; enable temporary write access for the buffer PD responsive to an authorized write to the memory mapped address range; and disable write access for the buffer PD after the authorized write.

In an example, the computing device may further comprise an operating system configured to: allocate N PDs as process PDs; and allocate M PDs as file PDs or buffer PDs.

In an example, the file manager may be configured to: create a first file association between a first memory mapped file and a first PD; and create a second file association between a second memory mapped file and the first PD concurrently with or alternatively to the first file association when a number of memory mapped files exceeds the M allocated PDs.

In an example, the buffer manager may be configured to: create a first buffer association between a first buffer and a second PD; and create a second buffer association between a second buffer and the second PD concurrently with or alternatively to the first buffer association when a number of buffers exceeds the M allocated PDs.

In an example, at least one of the file PD and the buffer PD is specified by a protective key (PKEY) configured with a write access register for enabling and disabling write access.

In an example, a method for managing a protective domain (PD) for a file may comprise, for example, memory mapping a file stored in persistent memory (PM) to create a memory mapped file; creating a file association between the memory mapped file and the PD; and creating a memory association between the PD and an address range of the memory mapped file based on the file association, wherein the PD is configurable to control write access to the address range of the memory mapped file.

In an example, the method may further comprise, for example, disabling write access for the PD; enabling temporary write access for the PD responsive to an authorized write to the memory mapped address range; and disabling write access for the PD after the authorized write.

In an example, the method may further comprise, for example, disabling write access to the address range of the memory mapped file based on the disabled write access for the PD or an unauthorized attempt to write to the address range of the memory mapped file.

In an example, the method may further comprise, for example, creating a file object for the memory mapped file; and storing the file association and the memory association in the file object.

In an example, the file object may be maintained by an application, an operating system or a host operating system (OS) extension in an isolated process comprising the application.

In an example, the method may further comprise reading from and writing to the memory address range of the memory mapped file by a user-mode memory copy call.

In an example, the memory copy call may comprise reading a page of the memory mapped file to a buffer pool; or writing a page from the buffer pool to the memory mapped file.

In an example, the PD may be specified by a protective key (PKEY) configured with a write access register for enabling and disabling write access.

In an example, a method for managing a protective domain (PD) for a buffer may comprise, for example, creating a buffer association between the buffer and the PD; and creating a memory association between the PD and an address range referenced by the buffer data structure based on the buffer association, wherein the PD is configurable to control write access to the address range referenced by the buffer data structure.

In an example, the address range may comprise a memory mapped address range associated with a memory mapped file stored in persistent memory (PM). The method may further comprise disabling write access for the PD; enabling temporary write access for the PD responsive to an authorized write to the memory mapped address range; and disabling write access for the PD after the authorized write.

In an example, the method may further comprise disabling write access to the address range of the memory mapped file based on the disabled write access for the PD or an unauthorized attempt to write to the address range of the memory mapped file.

In an example, the method may further comprise creating a buffer data structure for the buffer; and storing the buffer association and the memory association in the buffer data structure.

Claim 1:
A computing device (<NUM>, <NUM>), comprising:
one or more processors; and
one or more memory devices that store program code configured to be executed by the one or more processors, the program code, when executed by the one or more processors, comprising:
a file manager (<NUM>) configured to:
memory map a file stored in persistent memory, PM, to create a memory mapped file;
create a first file association between the memory mapped file and a file protection domain, PD; and
create a file memory association between the file PD and an address range of the memory mapped file based on the first file association, wherein the file PD is configurable to control write access to the address range of the memory mapped file; and
a buffer manager (<NUM>) configured to:
create a first buffer association between a buffer and a buffer PD; and
create a buffer memory association between the buffer PD and an address range for the buffer based on the first buffer association, wherein the buffer PD is configurable to control write access to the address range for the buffer;
wherein the file manager (<NUM>) is further configured to:
create a second file association between a second memory mapped file and the first PD concurrently with or alternatively to the first file association when a number of memory mapped files exceeds a number of PDs allocated as file PDs or buffer PDs; or
wherein the buffer manager (<NUM>) is further configured to:
create a second buffer association between a second buffer and the second PD concurrently with or alternatively to the first buffer association when a number of buffers exceeds the number of PDs allocated as file PDs or buffer PDs.