Reliable flash storage

Abstract

This document describes techniques and apparatus for reliable flash storage that may enable reliable read, write, and erase operations in flash storage. In an embodiment, data may be stored in a flash memory device through the use of two or more pages. A primary page may be determined from the two or more pages as a suitable page for performing a storage operation. An empty entry may be determined in the primary page, and data may be stored in the empty entry. After data is written to an entry, the previous entry may be invalidated, such as to prevent attempts to access or use invalid or deprecated data. In doing so, the previous entry may only be modified at the time a new entry is stored in the flash device. Thus, the described techniques and apparatus may enable reliable flash storage.

Description

[Background technology]

[0001] background Electronic devices are continually used to perform tasks of increasing complexity and importance. As a result, electronic devices require the implementation of robust, high-performance memory devices. Currently, many electronic devices utilize flash memory as a non-volatile storage medium. However, many flash memory devices have limitations, such as write endurance, which dictates the number of program and erase operations that can be performed before damaging the flash memory device. Furthermore, in some situations, data stored within a flash memory device may be corrupted during a power fluctuation event, such as a power loss during a storage operation. Such an event may permanently compromise data essential to the operation of the electronic device. Therefore, memory failures can damage electronic devices and, in some cases, render them unusable. Summary of the Invention

[0002] overview This document describes techniques and apparatus for reliable flash storage that may enable reliable read, write (e.g., program), and erase operations in flash storage. In aspects, data may be stored in a flash memory device through the use of two or more pages. A main page may be determined with respect to the two or more pages to determine an appropriate page for performing a storage operation. An empty entry may be determined within the main page, and data may be stored in the empty entry. After data is written to an entry, the previous entry may be invalidated, such as to prevent access or use of invalid or deprecated data. In doing so, the previous entry may only be changed at the time a new entry is stored in the flash device. Thus, the described techniques and apparatus may enable aspects of reliable flash storage.

[0003] A method is described that includes storing data in one of two or more pages of a flash memory. Storing the data includes determining a primary page of the two or more pages of the flash memory. A first empty entry in the primary page may be determined, and data (e.g., boot code, boot data, data structures, etc.) may be stored in the first empty entry of the primary page. In some cases, this ensures that previous data in the primary page is available in the event of a write failure when new or updated data is written to the empty entry in the primary page.

[0004] In an aspect, a flash reliability manager implemented in a computer-readable storage medium that may be executed by a processor to perform methods or other operations for a trusted flash memory is also described. In another aspect, a system including a flash memory and a flash reliability manager configured to implement aspects of the trusted flash memory is further described in this document.

[0005] This summary is provided to introduce simplified concepts of techniques and apparatus for reliable flash storage that are further described below in the detailed description and drawings. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0006]

[0013] One or more aspects of the reliable flash storage are described in detail below. The use of the same reference numbers in different instances in the description and figures indicates similar elements. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example operating environment in which trusted flash storage may be implemented in accordance with one or more aspects. [Figure 2]FIG. 1 illustrates an example of a system including a flash reliability manager. [Figure 3] FIG. 2 illustrates an example of a flash bank in a flash memory. [Figure 4] FIG. 1 illustrates an example of a flash memory including multiple pages in accordance with one or more aspects of reliable flash storage. [Figure 5] FIG. 1 illustrates an example of a counter implementation for main page determination in accordance with one or more aspects. [Figure 6] FIG. 1 illustrates an example of a state scheme for main page determination in accordance with one or more aspects of reliable flash storage. [Figure 7] FIG. 1 illustrates an example implementation of a write operation in accordance with one or more aspects. [Figure 8] FIG. 1 illustrates an example implementation of a read operation in accordance with one or more aspects of reliable flash storage. [Figure 9] FIG. 1 illustrates an example method for a write operation in accordance with one or more aspects of reliable flash storage. [Figure 10] FIG. 1 illustrates an example method for a read operation in accordance with one or more aspects of trusted flash storage. DETAILED DESCRIPTION OF THE INVENTION

[0008] Detailed Description overview This document describes techniques and apparatus for reliable flash storage. Many electronic devices may utilize flash memory to store data that is useful for the operation of the device. When provisioned, flash memory contains pages, with each page containing a set number of bits initialized to a value of 1. Bits can be programmed from 1 to 0 through a write operation. However, to program bits with a value of 0 back to their original value of 1, an erase operation is used. Erase operations cannot be performed on individual bits; instead, they program all bits in a page (or bank) of flash memory to a value of 1, which may damage the flash device over time. Furthermore, flash devices may experience power loss during write or erase operations, which can corrupt the data being written or erased. Reliable flash storage is necessary to limit damage to flash devices and provide a robust solution for storing data in flash memory.

[0009] This specification describes reliable flash storage that utilizes at least two pages in an append-only fashion to store data within the flash memory. Generally, flash memory can be accessed through three operations: read, write, and erase. A read operation can retrieve data stored in the flash memory and output the contents to be used by another device. A write operation can determine the appropriate entry to store the data by programming the appropriate bits of the entry to zero. An erase command can reprogram all bits within a page (or bank or block) to a value of one. To provide reliable flash storage, two or more pages are used to ensure that previous entries are retained until new entries are written. Thus, even if data is corrupted, the previous entries may remain available for reading. Furthermore, a primary page on which read and write operations should be performed can be determined between two pages. Data structures (e.g., boot code, boot data, etc.) are written to entries within each page and set to a valid or invalid state. In an embodiment, the primary page can be determined through a counter method or a state method. The counter method can utilize a counter field in each data structure to determine the page containing the valid entry with the highest data structure counter field. The state scheme can utilize storage space within each page where the state of the page is stored. Based on the state of each page, a primary page can be determined. Thus, write and read operations can be performed on the primary page, minimizing the computation required to determine the appropriate interaction with the flash memory.

[0010] In the case of reliable flash storage, the write operation may be performed on the first empty entry in the main page. The write operation may further invalidate the previous entry by modifying a field of a data structure stored in the previous entry, for example, by setting all or some bits of a field of the data structure known to have at least one non-zero bit to zero. Doing so may allow valid entries to be found more easily, thereby requiring less computation to determine the main page. Furthermore, when the main page is changed from a first page to a second page, for example because the main page is full, the second page may be erased to make space for the new entry without modifying the previous entry in the first page. In an aspect, as described, the reliable flash storage is performed by a flash reliability manager operatively coupled with the flash memory.

[0011] The described aspects may provide one or more advantages over prior art flash memory writes. For example, reliable flash storage may provide an opportunity to recover from a write failure because a previous entry is invalidated only after a successful write, or may provide an opportunity to recover from an erase failure without falling back to a default value. Furthermore, these aspects may perform one erase every N writes instead of one erase per write, reducing the likelihood of data corruption due to power outages. Alternatively or additionally, erase cycles may be distributed across at least two pages of information, resulting in reduced flash wear. These are just a few examples of aspects and advantages provided by reliable flash storage; other aspects and advantages are described throughout this disclosure.

[0012] 1 illustrates an example operating environment 100 for trusted flash storage according to one or more aspects. For example, the trusted flash storage may be implemented within an electronic device 102, such as a mobile device 102-1, a tablet 102-2, a personal computer 102-3, a wearable computing device 102-4, or a vehicle 102-5 (e.g., a vehicle navigation, control, or entertainment system). Although not shown, other configurations of the electronic device 102 are possible, such as a desktop, a server, a printer, a digital camera, a gaming console, a home automation terminal, a mobile hotspot, a security chip, etc.

[0013] In an aspect, an electronic device 102 capable of implementing trusted flash storage includes a processor 104 and a computer-readable storage medium 106. The computer-readable storage medium 106 may be implemented within or in association with the processor 104, for example, as a system-on-chip (SoC) or another form of internal or embedded system that provides processing or functionality for the electronic device 102. Alternatively, the computer-readable storage medium 106 may be external but associated with the processor 104. The computer-readable storage medium 106 includes a volatile memory 108 and a non-volatile memory 110, which may include any suitable type, combination, or number of internal or external memory devices. Each memory of the computer-readable storage medium 106 may be implemented as on-chip memory in a hardware circuit or as an off-chip memory device that communicates data with the processor 104 via a data interface or bus. In one example, the volatile memory 108 includes random access memory (RAM). Alternatively or additionally, the volatile memory 108 may include other types of memory, such as static random access memory (SRAM), synchronous dynamic random access memory (DRAM), asynchronous DRAM, double data rate RAM (DDR), etc.

[0014] Additionally, non-volatile memory 110 may include flash memory 114 and read-only memory 112 (ROM 112), either of which may be used to store separate code partitions with various security requirements. Other non-volatile memories not shown may include non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), embedded multimedia card (eMMC) devices, single-level cell (SLC) flash memory, multi-level cell (MLC) flash memory, etc. In one example, ROM 112 is implemented as an on-chip memory area. Boot code may be stored in one or more non-volatile memory components, such as flash memory 114 and ROM 112. In a particular example, the lowest level of boot code is written or masked in ROM 112. This prevents the boot code in ROM 112 or in metal mask ROM / boot ROM from being modified after the chip is manufactured. The unmodifiable nature of ROM 112 ensures the authenticity of the lowest level of boot code. Higher level boot code may be implemented in an extension of ROM 112 such as flash memory 114 .

[0015] The flash memory 114 may be implemented through a flash bank that includes multiple partitions, each accessible to a different system of the electronic device 102. In some implementations, the flash memory 114 may include a data partition that holds general-purpose data and an information partition that holds metadata about the data partition and design-specific confidential data. The flash memory 114 may be durable and therefore capable of supporting changes through multiple write and erase commands. Additionally, the flash memory 114 may support read commands that output data stored within the flash memory 114.

[0016] The electronic device 102 further includes a flash reliability manager 116 that enables reliable flash storage. The flash reliability manager 116 may be implemented through machine-readable instructions executable by the processor 104. In this implementation, the flash reliability manager 116 may provide high-level protocol commands, such as read, write, and erase, to the flash controller in accordance with techniques for reliable flash storage. As a result, the flash controller can arbitrate the high-level protocol commands to perform read, write, and erase operations on the flash memory 114. In other implementations, the flash reliability manager 116 may be implemented as hardware within the flash controller and function to arbitrate the high-level protocol commands to perform reliable flash storage. Accordingly, the flash reliability manager 116 may be implemented through any number of fixed logic circuits, including, but not limited to, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), an SoC, a complex programmable logic device (CPLD), etc.

[0017] The electronic device 102 may execute an operating system or applications from any suitable type of computer-readable storage medium 106, including volatile memory 108 and non-volatile memory 110. Alternatively or additionally, the operating system or applications may be embodied as firmware or any other computer-readable instructions, binaries, or code. The electronic device 102 may include a user interface provided by the operating system or applications to enable certain functions or services of the electronic device 102.

[0018] The electronic device 102 may also include I / O ports 118. The I / O ports 118 enable the embedded device 102 to interact with other devices or users, such as programming code or values ​​described herein into respective memories, registers, etc. The I / O ports 118 may include any combination of internal or external ports, such as USB ports, Joint Test Action Group (JTAG) ports, Test Access and Programming (TAP) ports, audio ports, Serial ATA (SATA) ports, PCI-express-based ports or card slots, Secure Digital Input / Output (SDIO) slots, and / or other legacy ports. Various peripherals, such as human input devices (HIDs), external computer-readable storage media, or other peripherals, may be operatively coupled to the I / O ports 118.

[0019] 2 illustrates an example of a system 200 including a flash reliability manager 116. The flash reliability manager 116 may be disposed between the software interface of the host 202, other hardware components, and the flash physical controller 204. In some implementations, the flash reliability manager 116 translates read, write, and erase requests from the host 202 into a high-level protocol for the flash physical controller 204. While the flash physical controller 204 is shown implemented within the flash memory 114, it may also be external and connected to the flash memory 114. The flash physical controller 204 is connected to a flash bank 206 that includes one or more partitions accessible to various systems within the electronic device. Thus, the flash physical controller 204 can execute the high-level protocol provided by the flash reliability manager 116 to arbitrate read, write, and erase commands to one or more partitions of the flash bank 206. Additionally, the flash physical controller 204 or the flash reliability manager 116 may be utilized to perform various security functions on the flash memory 114, such as scrambling or buffering.

[0020] FIG. 3 illustrates an example of a flash bank 206 at 300. Flash memory may not be organized as a contiguous block of general-purpose storage, but instead may be organized into a data partition and an information partition. For example, as illustrated, the flash bank 206 includes an information partition 302, an information partition 304, and a data partition 306. The data partition 306 may store general-purpose data, like general-purpose memory. The information partitions 302 and 304 may store metadata and design-specific confidential data related to the data partitions. For example, the information partitions (e.g., the information partitions 302 and 304) may include, but are not limited to, redundant information, manufacturer-specific information, manufacturer flash timing information, a design-specific unique seed, and redundant pages. Each partition may include or be divided into pages; for example, the information partition 302, the information partition 304, and the data partition 306 each include up to an integer number N of pages with a set number of entries capable of storing a set number of words. Each word may consist of a set number of bits that determine the word size. In a default state, each bit may be set to 1. In an embodiment, the flash bank 206 may include multiple information partitions, none of which need be the same size as the data partition 306 .

[0021] For each type of partition, the page size and word size may be required to be the same, but each type of partition may contain a different number of pages. Thus, the size of one or more partitions may differ from other partitions. However, all types of partitions may follow the same program and erase rules, e.g., once a bit is programmed to 0, it cannot be programmed back to 1 unless an erase command is used. In some aspects, a write command may be a bit-wide operation to program a 1 to 0, while an erase command must operate on an entire page or bank to erase all bits programmed with a value of 0 to 1. Alternatively or additionally, write operations may be performed at any suitable granularity, such as write operations implemented as one or more of a bit-wide operation, a nibble-wide operation, a byte-wide operation, a word-wide operation, etc. In some cases, the data partition may be directly read by software and other hardware hosts, while the information partition may only be read by a flash controller (e.g., flash physical controller 204).

[0022] In one implementation, information partition 302 and information partition 304 hold secret seeds for implementing a secure boot process. Pages embedded within the information partition may be read upon initialization of the flash controller. Values ​​read from the pages may then be supplied for use as part of the secure boot process of the electronic system. In some implementations, the secure boot process may involve a creator secret (from the manufacturer or designer of the silicon device) and an owner secret (from the purchaser or entity authorized by the creator (or previous owner) to execute code on the device). Thus, information partition 302 or information partition 304 may include a creator page and an owner page.

[0023] In aspects, entries may be implemented as shown in Example Data Structure 1 with one or more fields for a digest, an identifier, a counter, a security version value, etc. Entries may be a fixed size (e.g., a multiple of the word size) or may be integrity protected.

[0024] Data structure example 1 typedef struct boot_data { hmac_digest_t digest; uint32_t identifier; uint32_t counter; uint32_t min_security_version_rom_ext; / / Other data (or padding) / / ... } FIG. 4 illustrates an example of a flash memory 400 including multiple pages according to one or more aspects of reliable flash storage. For example, page 402 and page 404 are used as append-only logs to enable recovery from interrupted write and erase operations. Data can be packed into a single data structure, and each page can store an integer number N of entries, determined by the size of this data structure and the page size. At any given time, one of pages 402 and 404 is the primary (or active) page, and the other is the secondary (or inactive) page. The primary page is available for reads and writes until it is full. If a new entry needs to be stored when the primary page is full, the secondary page can be erased, and the new entry can be written to the newly erased page. Once the new entry is verified, the primary and secondary pages can be switched. In other words, if the primary page is full (e.g., all entries are filled), the secondary page is erased, and the new entry is written to the newly erased page. Verifying the new entry switches the roles or states of the primary and secondary pages (e.g., a previously erased page becomes the primary page). It should be noted that verifying the new entry can be performed in a variety of ways, for example, by reading back the newly written entry and comparing its contents with expected values, or by monitoring the flash controller for error conditions.

[0025] To allow the integrity of an entry to be verified, the stored data structure may have a digest (or checksum) field. In some implementations, the digest may be used to determine the validity of an entry. For example, the digest may be verified to determine that the entry is valid. However, if the digest does not verify, the entry may be considered invalid. In aspects, an identifier field with a non-trivial value may be used to allow for quick determination of invalid or empty entries before a full integrity and emptiness check as an optimization. In aspects, the identifier field may be a predetermined constant value across each entry. Alternatively, the identifier field may be unique per entry or may vary based on the type of entry.

[0026] FIG. 5 illustrates an exemplary counter scheme 500 for determining a primary page in accordance with one or more aspects of reliable flash storage. As previously described, the counter scheme may utilize at least two pages (e.g., pages shown as page 402 and page 404) in an append-only manner. Each of page 402 and page 404 is writable and may contain a set number of entries that can be set to valid or invalid. Each entry may have a counter field that is incremented with each write. With each write, the entry may be filled and set to valid. Additionally, each other entry, or previous entries, may be set to invalid. To determine the primary page, valid entries for each page may be found and compared based on the value of their counter field, and the page with the higher counter value may be determined as the primary page. Alternatively, the last valid entry in each page may be found and compared based on the value of the counter.

[0027] For example, page 402 contains no empty entries and similarly no valid entries. However, page 404 contains a valid entry with a counter value of 56. As a result, page 404 may be determined as the primary page. In an implementation in which a previous entry is set invalid as part of a write command, flash memory may be corrupted while setting the validity field of the previous entry. As a result, the previous entry may not be marked as invalid. In this case, each valid entry may be compared based on its counter value, and the primary page is determined. In another implementation, the previous entry is not set as invalid. In this implementation, both page 402 and page 404 may contain valid entries. The valid entries are compared, and the valid entry with the highest counter value determines the primary page. Specifically, the primary page is the page containing the entry with the highest counter value. If there are no valid entries, it may be determined that the page needs to be initialized, e.g., erased. If a read request is received before initialization, a default value may be returned. This behavior may be further controlled, allowed, or prohibited based on the device's lifecycle state, one-time programmable (OTP) memory configuration, or other configuration. Initialization may include a default main page, such as page 402 or page 404. The counter method may be advantageous for reliable flash storage due to its simplicity, as it uses only a simple counter field in each entry. Alternatively, reliable flash storage may be performed via a state method.

[0028] FIG. 6 illustrates at 600 an example of a state scheme for determining a primary page in accordance with one or more aspects of reliable flash storage. Similar to the counter scheme, the state scheme can utilize two append-only pages. As shown, the state scheme includes page 402 and page 404. Each page can have a reserved area for storing the state of the page. As shown in FIG. 6, redundancy encoding can be used that utilizes two constants, X and Y. Each of the constants, X and Y, can be used to represent the state of the page in which it is stored.

[0029] The first four rows shown in FIG. 6 list the states of a page in the order in which it can transition. Additionally, the state that will be updated in the next row is highlighted. For example, assuming that a page's status field has values ​​X and Y (first row) and page 402 (the primary page) is full, page 404 is erased, its status field is set to X, and it becomes the primary page (second row). If this operation is interrupted, the current primary page is not changed during this operation, so the state of the pages can still be reliably determined. If both pages are in the X state (second row), page 404 can be written as the primary page. Once page 404 is full, page 402 can be erased, its state can be changed to Y, and page 402 becomes the primary page (third row). Similarly, page 402 can be written as the primary page until it is full. Once page 402 is full, page 404 can be erased, its state can be changed to Y, and page 404 becomes the primary page (fourth row). Page 404 can be written to as the primary page until it is full, at which point page 402 can be erased and its state can be set to X. This can determine page 402 as the primary page and the cycle starts over.

[0030] Once a primary page is determined, existing entries can be written to the primary page without modifying it. If the primary page is full, a secondary page can be erased and written as the primary page. Thus, reliable flash storage is provided because previous entries cannot be cleared or invalidated until a new entry is written. It should be noted that the determination of the primary page and the erasure of the page can be performed in any order. For example, a primary page may be determined to be full. A secondary page may be determined as the primary page and deleted. Alternatively, a secondary page can be deleted and then determined as the primary page. It should be noted that the state scheme may not require any additional fields in the entry, and there is no need to scan a second page to determine the primary page. For ease of explanation, the various operations (read, write, and erase) are described in the context of a counter scheme. However, it should be understood that each of the read, write, and erase operations can be performed according to the state scheme by implementing a state for each page instead of or in addition to the counter field.

[0031] FIG. 7 illustrates at 700 an example implementation of a write operation according to one or more aspects of reliable flash storage. Page 402 is shown before (e.g., page 402-1) and after (e.g., page 402-2) the write operation occurs. The write operation may write a new data structure to the first empty entry in the primary page (e.g., the first entry with all 1's bits). In some aspects, this may be implemented as a simple linear search, since the number of non-empty entries is expected to be small. Alternatively, a binary search or any other suitable search algorithm may be used to determine the first empty entry in the primary page. Note that entries do not need to be unique; the same entry may be written multiple times for redundancy. If no empty entries remain in the primary page, the secondary page may be erased before the new data structure can be written. Once the new entry is verified, the primary and secondary pages may be switched. Once the new entry is written, the previous entry may be invalidated (e.g., by writing all 0's to the structure's fields) to avoid reverting to old information. In some implementations, the identifier field may be written to 0. If a write operation is interrupted, the previous entry may still be valid because it becomes invalid only after the new entry is successfully written. In an example write operation, a search may determine the first empty entry in page 402-1, and a write command may write a new data structure containing an incremented counter to the empty entry, resulting in page 402-2. In a state scheme, the write operation may include updating the state of each page as needed.

[0032] FIG. 8 illustrates at 800 an example implementation of a read operation according to one or more aspects of reliable flash storage. In FIG. 8, page 402 is the primary page and contains at least one valid entry. The read operation can return the last valid entry in the primary page. Similar to a write operation, the read operation must first search for the first empty entry in the page and can perform a backward search to find the last valid entry. If there are no empty entries in the page, the backward search can start from the last entry in the page. As a result, the read operation can find the last valid entry even if previous entries have not been updated to invalid. A page may not contain valid entries, for example, before the page is written to. If valid data is not available, a default value can be used based on the lifecycle state of the electronic device or another configuration, such as OTP fuses. For example, in a manufacturing state, the lifecycle state can determine a corresponding default value to enable manufacturing use cases. In another implementation, a single default configuration can be used.

[0033] In general, any of the components, modules, methods, and operations described herein may be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of example methods may be described in the general context of executable instructions stored in a computer-readable storage memory that is local and / or remote to a computer processing system, and the implementation may include a software application, program, function, etc. Alternatively or additionally, any of the functions described herein may be performed at least in part by one or more hardware logic components, including, but not limited to, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), etc.

[0034] FIG. 9 illustrates an example method 900 for a write operation according to one or more aspects of reliable flash storage. At 902, a primary page of two or more pages of a flash memory is determined. In aspects, the primary page is determined using the counter or state method detailed above. In some implementations, storing data in one of the two or more pages of a flash memory includes determining whether the primary page is full after determining the primary page. In response to determining that the primary page is full, another page of the two or more pages may be erased. The other page may then be used to store data in its first empty entry and determined as the primary page. In some cases, this prevents the data from being erased until new or updated data for the entry is written to a different page of the flash memory, ensuring that the data is available even if an erase or write fails when storing the data in the new primary page of the flash memory.

[0035] In some implementations, a counter scheme can be used to direct and enable determination of a primary page from multiple pages of a flash memory. For example, data may be written or formatted as a data structure including a counter field, and storing a data structure (e.g., a valid data structure or a valid structure) may include setting the counter field of the valid data structure by incrementing a counter field of the data structure stored in a previous entry (e.g., a monotonically increasing counter for indicating a valid entry). In some implementations, there may be no previous entry. Thus, a default value may be written to the counter field. In the counter scheme, a primary page may be identified by determining a first valid entry in a first page of two or more pages and at least one second valid entry in at least one second page of the two or more pages. To determine the primary page, the first valid entry and the at least one second valid entry may be compared based on counter fields of data structures stored in each of the first valid entry and the at least one second valid entry. In some implementations, multiple valid entries may exist on a page. Thus, the last valid entry of each page may be used to determine the primary page.

[0036] In some implementations, a status scheme is utilized to determine a primary page of a flash memory. For example, each of two or more pages of a flash memory may include a status field used to store the status of each page. The primary page may be determined based on the respective status fields of the two or more pages. In one aspect, an initial primary page is determined based on the respective status fields of the two or more pages, and the primary page is searched to determine whether the page includes an empty entry. If it is determined that the primary page does not include an empty entry (e.g., is full), another page of the two or more pages, different from the initial primary page, is determined as the primary page. In some implementations, in response to determining that the initial primary page is full, the other page is erased. In one aspect, in response to erasing the other page, the status field of the other page is changed. In some implementations, valid data is stored in the first empty entry of the other page, using the other page as the primary page.

[0037] At 904, a first empty entry in the main page is determined. At 906, a valid data structure is stored in the first empty entry. In some implementations, the valid data structure may include a digest, an identifier field, or a counter field. At 908, in response to a valid data structure being stored in the first empty entry, the previous entry may be set to invalid. The previous entry may be set to invalid by modifying a field in the data structure stored in the previous entry. In a particular example, the field, or a portion thereof, may be changed to zero. In one aspect, the identifier field may be known to be non-zero, and therefore the identifier field may be adjusted to set the previous entry to invalid.

[0038] 10 illustrates an example method 1000 for a read operation in accordance with one or more aspects of reliable flash storage. At 1002, a primary page of two or more pages of a flash memory is determined. In general, this determination may be similar to the primary page determination made at 902 in FIG. 9.

[0039] At 1004, a last valid entry in a main page of the two or more pages may be determined. The last valid entry may be determined based on any of the data stored in the flash memory. For example, a counter, a digest, or an identifier field may be used to determine the last valid entry. At 1006, the data structure stored in the last valid entry may be output. Generally, the output may include the entire data structure or a portion of the data structure. However, generally, a read operation may retrieve the data from the flash storage.

[0040] In general, the methods described above may be implemented in whole or in part by a flash reliability manager. In doing so, the methods and / or aspects described herein may provide trusted flash storage that may be used to improve data reliability for secure boot operations or other types of flash memory access.

[0041] An example of trusted flash storage is provided below. Example 1: A method including storing data in one page of two or more pages in a flash memory, the storing including determining a main page of the two or more pages of the flash memory, determining a first empty entry in the main page, and storing a data structure in the first empty entry of the main page.

[0042] Example 2: The method of any one of the previous examples, wherein storing data in one page of the two or more pages in the flash memory includes, after determining a primary page of the two or more pages of the flash memory, determining whether the primary page is full, erasing another page of the two or more pages in response to determining that the primary page is full, storing the data structure in a first empty entry in the other page, and selecting the other page as the primary page.

[0043] The method may include, after determining a main page of the two or more pages of the flash memory, determining whether the main page is full, and, in response to determining that the main page is not full, storing the data structure in a first empty entry of the main page.

[0044] Example 3: The method of any one of the previous examples, wherein storing the data structure in an initial empty entry in the main page includes setting one or more fields of the data structure that include a digest or identifier of the data structure to indicate the validity of the data structure, and setting the previous data entry to an invalid state by modifying the fields of the data structure stored in the previous entry.

[0045] Example 4: The method of any one of the previous examples, wherein setting the previous entry to an invalid state includes changing an identifier field of a data structure stored in the previous entry to a zero value or other non-zero predetermined value configured to indicate the invalid state.

[0046] Example 5: The method of any one of the previous examples, wherein the data structure includes a counter field, and storing the data structure includes setting the counter field of the data structure as an incremental value from the value of the counter field of the other data structure stored in a previous entry, or, in response to determining that no previous entry exists, setting the counter field of the data structure as a default value.

[0047] Example 6: The method of any one of the previous examples, wherein determining the main page includes determining a first valid entry in a first page of the two or more pages of the flash memory; determining at least one second valid entry in at least one second page of the two or more pages of the flash memory; and determining the main page of the flash memory based on a comparison of respective counter fields of the data structure stored in the first valid entry and the at least one data structure stored in the at least one second valid entry.

[0048] Example 7: The method of any one of the previous examples, wherein each page of the two or more pages of the flash memory includes a respective status field used to store a status of each page, and determining a primary page within the two or more pages includes: determining a first primary page as the primary page based on the respective status field of each of the two or more pages; determining whether the first primary page includes an empty entry; and, in response to determining that the first primary page does not include an empty entry, determining another page of the two or more pages, different from the first primary page, as the primary page.

[0049] Example 8: The method of any one of the previous examples, wherein the state field stores either a first value or a second value different from the first value.

[0050] Example 9: The method of any one of the previous examples, further including, in response to determining the other page as the primary page, modifying a status field of the other page to indicate the other page as the primary page of two or more pages of the flash memory.

[0051] Example 10: The method of any one of the previous examples, further comprising erasing the other page in response to determining the other page as the primary page and storing the data structure in a first empty entry in the primary page.

[0052] Example 11: The method of any one of the previous examples, further including reading data from a main page of the two or more pages of the flash memory, wherein the reading includes determining a last valid entry in the main page of the two or more pages, and outputting a representation of the data structure stored in the last valid entry in the main page.

[0053] Example 12: The method of any one of the previous examples, wherein storing the data in one of the two or more pages of the flash memory is performed as part of a secure boot process.

[0054] Example 13: The method of any one of the previous examples, wherein storing data in one of the two or more pages of the flash memory utilizes the page as an append-only page.

[0055] Example 14: A system comprising a flash memory including two or more pages and a flash reliability manager configured to perform the method of any one of the previous examples.

[0056] Example 15: An apparatus comprising at least one computer-readable storage medium storing processor-executable instructions that, when executed by at least one processor, direct the at least one processor to perform a method as described in any one of the previous examples. The apparatus may further comprise a flash memory and the at least one processor.

[0057] Although aspects of trusted flash storage have been described in feature- and / or method-specific language, the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the specific features and methods are disclosed as example implementations of the claimed trusted flash storage, and other equivalent features and methods are intended to be within the scope of the appended claims. Furthermore, various aspects have been described, and it should be understood that each described aspect can be implemented independently or in conjunction with one or more of the other described aspects.

[0058] Unless the context dictates otherwise, use of the word "or" herein may be considered "inclusive or," or use of a term permitting the inclusion or application of one or more items associated by the word "or" (e.g., the phrase "A or B" may be interpreted as permitting only "A," permitting only "B," or permitting both "A" and "B"). Also, as used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including single members. For example, "at least one of a, b, or c" may cover not only a, b, c, ab, ac, bc, and abc, but also any combination with multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other order of a, b, and c). Additionally, items depicted in the accompanying figures and terms discussed herein may refer to one or more items or terms, and thus, the written specification may refer to the single or plural forms of items and terms interchangeably. Although implementations of trusted flash storage have been described in language specific to particular features and / or methods, the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the particular features and methods are disclosed as example implementations of trusted flash storage.

Claims

1. Storing data in one of two or more pages in a flash memory, said storing comprising: determining a primary page of the two or more pages of the flash memory; determining a first empty entry on the main page; storing a data structure in the first empty entry of the main page; Including, the data structure includes a counter field; Storing the data structure comprises: setting the counter field of the data structure as an incremental value from the value of the counter field of another data structure stored in a previous entry; or responsive to determining that the previous entry does not exist, setting the counter field of the data structure to a default value; A method comprising:

2. Storing the data in the one page of the two or more pages in flash memory includes: After determining a main page of the two or more pages of the flash memory, determining whether the main page is full; responsive to determining that the main page is full, erasing other pages of the two or more pages; storing said data structure in the first empty entry in said other page; selecting the other page as the primary page; The method of claim 1 , comprising:

3. Storing the data structure in the first empty entry in the main page comprises: setting one or more fields of the data structure to include a digest or identifier of the data structure to indicate the validity of the data structure; setting a previous entry to an invalid state by modifying a field of a data structure stored within said previous entry; 2. The method of claim 1, comprising:

4. Setting the previous entry to the invalid state includes: changing an identifier field of the data structure stored in the previous entry to a zero value or other non-zero predetermined value configured to indicate the invalid state; The method of claim 3, comprising:

5. Determining the primary page comprises: determining a first valid entry in a first page of the two or more pages of a flash memory; determining at least one second valid entry in at least one second page of the two or more pages of the flash memory; determining the main page of the flash memory based on a comparison of respective counter fields of a data structure stored in the first valid entry and at least one data structure stored in the at least one second valid entry; The method of claim 1 , comprising:

6. each of said two or more pages of flash memory including a respective state field used to store a state of each page; Determining the primary page within the two or more pages includes: determining an initial primary page as the primary page based on the respective status fields of each of the two or more pages; determining whether the first main page contains an empty entry; determining, in response to determining that the first main page does not include an empty entry, another page of the two or more pages different from the first main page as the main page; 2. The method of claim 1, comprising:

7. The method of claim 6 , wherein the state field stores either a first value or a second value that is different from the first value.

8. 7. The method of claim 6, further comprising, in response to determining the other page as the main page, modifying the status field of the other page to indicate the other page as the main page of the two or more pages of the flash memory.

9. 9. The method of claim 8, further comprising erasing the other page in response to determining the other page as the primary page, and storing the data structure in the first empty entry in the primary page.

10. The method further includes reading data from the main page of the two or more pages of the flash memory, wherein the reading includes: determining a last valid entry in the primary page of the two or more pages; outputting a representation of the data structure stored in the last valid entry in the main page; 2. The method of claim 1, comprising:

11. A method for implementing a method of storing data in one of two or more pages in a flash memory, the storing comprising: determining a primary page of the two or more pages of the flash memory; determining a first empty entry on the main page; storing a data structure in the first empty entry of the main page; Including, 10. The method of claim 1, wherein storing the data in the one page of the two or more pages of the flash memory is performed as part of a secure boot process.

12. A method for implementing a method of accessing a flash memory, comprising: storing data in one of two or more pages in a flash memory, said storing comprising: determining a primary page of the two or more pages of the flash memory; determining a first empty entry on the main page; storing a data structure in the first empty entry of the main page; Including, Storing the data in the one of the two or more pages of the flash memory utilizes the two or more pages as append-only pages.

13. a flash memory containing two or more pages; a flash reliability manager operatively coupled to said flash memory and configured to perform the method of any one of claims 1 to 12; A system comprising:

14. A flash memory; at least one processor; at least one computer-readable storage medium storing processor-executable instructions that, when executed by said at least one processor, direct said at least one processor to perform the method of any one of claims 1 to 12; and An apparatus comprising:

Images