Inline hashing for data write scenarios

Abstract

In some implementations, a host controller may obtain data based on a transfer request. The host controller may generate a hash value based on the data. The host controller may write, to the volatile memory, the hash value. The host controller may provide, to a universal flash storage (UFS) device, the data.

Description

INLINE HASHING FOR DATA WRITE SCENARIOSFIELD OF THE DISCLOSURE

[0001] Aspects of the present disclosure generally relate to data write operations and specifically relate to techniques, apparatuses, and methods associated with inline hashing for data write scenarios. DESCRIPTION OF THE RELATED TECHNOLOGY

[0002] An electronic device, such as a mobile communication device, a wearable computing device (such as a smartwatch) , or a computer (such as a laptop computer, a tablet computer, or another type of computer) , may include one or more memory systems to store data. Various types of memory devices exist, including random access memory (RAM) , read only memory (ROM) , dynamic RAM (DRAM) , static RAM (SRAM) , synchronous dynamic RAM (SDRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , holographic RAM (HRAM) , flash memory (e.g., NAND memory and NOR memory) , and others. A memory device may be volatile or non-volatile. Non-volatile memory (e.g., flash memory) can store data for extended periods of time even in the absence of an external power source. Volatile memory (e.g., DRAM) may lose stored data over time unless the volatile memory is refreshed by a power source.

[0003] As an example, a memory device may be a universal flash storage (UFS) device. A UFS device may include non-volatile memory for storing data in accordance with one or more UFS specifications promulgated by the Joint Electron Device Engineering Council (JEDEC) solid state technology association. An electronic device may include, or communicate with, a UFS device for storing data in the non-volatile memory of the UFS device. For example, the UFS device may be a flash memory device that uses a serial interface (e.g., a UFS host controller interface) to store data in non-volatile memory for a host system of the electronic device.SUMMARY

[0004] The systems, methods, and devices of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0005] In some implementations, a method of wireless communication performed by a host controller includes obtaining, from volatile memory, data based on a transfer request associated with a universal flash storage (UFS) device; generating, based on the transfer request, a hash value based on the data; writing, to the volatile memory, the hash value; and providing, to the UFS device, the data.

[0006] In some implementations, an electronic device includes a host controller configured to: obtain, from volatile memory, data based on a transfer request associated with a UFS device; generate, based on the transfer request, a hash value based on the data; write, to the volatile memory, the hash value; and provide, to the UFS device, the data.

[0007] In some implementations, a system includes volatile memory; a UFS device; a processing system; and a UFS host controller configured to: obtain, from the volatile memory, data based on a transfer request associated with the UFS device; generate, based on the transfer request, a hash value based on the data; write, to the volatile memory, the hash value; and provide, to the UFS device, the data.

[0008] Aspects of the present disclosure may generally be implemented by or as a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, electronic device, or processing system as substantially described in the Detailed Description with reference to, and as illustrated by, the accompanying drawings. Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. Note that the relative dimensions of the following figures may not be drawn to scale.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Fig. 1 is a diagram of an example of an electronic device that can support inline hashing for data write scenarios.

[0010] Figs. 2A and 2B are diagrams of an example of data verification using cryptographic techniques.

[0011] Fig. 3 is a diagram of an example associated with inline hashing for data write scenarios.

[0012] Fig. 4 is a diagram of an example associated with inline hashing for data write scenarios.

[0013] Fig. 5 is a flowchart of an example process associated with inline hashing for data write scenarios.DETAILED DESCRIPTION

[0014] Several aspects of data transfer systems will now be presented with reference to various apparatus and methods. These apparatuses and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, or algorithms (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. By way of example, an element, or any portion of an element or combination of elements may be implemented in a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs) , field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , application specific integrated circuits (ASICs) , a system-on-chip (SoC) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure.

[0015] Universal flash storage (UFS) may refer to one or more specifications for non-volatile memory. The UFS specifications were promulgated by the Joint Electron Device Engineering Council (JEDEC) solid state technology association. UFS may be utilized in a variety of electronic devices, such as smart phones, tablets, or digital cameras, among other examples. UFS may offer a high-performance and efficient storage solution. UFS may provide high-speed data transfer capabilities, which may be useful for high-resolution video recording, fast application loading, or quick data transfers, among other examples.

[0016] In some examples, an electronic device may verify data read from memory (e.g., non-volatile memory) using one or more cryptographic functions. As an example, an electronic device (e.g., a processing system of the electronic device) may verify data read from non-volatile memory of a UFS device. The processing system may include one or more central processing units (CPUs) , among other examples. The processing system may verify the data by generating one or more hash values based on the data read from the UFS device and comparing the generated hash value (s) to one or more pre-generated hash values. As used herein, “hash” value refer to a unique (e.g., unique to data being represented by the hash value) fixed-length string of characters generated via a hashing algorithm (such as a secure hash algorithm (SHA) ) to represent a piece of data. A hash value may serve as a cryptographic fingerprint for the piece of data. A hash value may also be referred to as a hash function. The hashing algorithm may be a deterministic algorithm in that different inputs (e.g., different data provided as inputs) will result in different hash values. Additionally, the hashing algorithm may be a one-way function in that it may be computationally difficult to obtain the original data from the hash value. The one or more pre-generated hash values may be generated by the processing system prior to the data being stored on the UFS device. The verification enables the processing system to detect whether the data read from the UFS device is authentic, if the data has been tampered with, or if the data has any security flaws, among other examples. This improves the security and reliability of data read from non-volatile memory, such as from a UFS device.

[0017] In some examples, such as for a read operation, a UFS host controller may generate the one or more hash values based on the data read from the UFS device during the read operation. For example, the UFS host controller may obtain the data from the UFS device based on a transfer request generated by the processing system. The UFS host controller may generate one or more hash values based on the data. The UFS host controller may write the one or more hash values to host memory, such as volatile memory in the electronic device. The UFS host controller generating or storing the one or more hash values during a read operation may be referred to as “inline” hashing for the read operation. For example, a physical region description table (PRDT) may indicate an area in volatile memory in which the one or more hash values are to be stored by the UFS host controller. The processing system may obtain the one or more hash values from the host memory (e.g., from the area in volatile memory indicated by the PRDT) and use the one or more hash values for verification, in a similar manner as described above. This conserves processing resources or reduces latency, among other examples, that would have otherwise been associated with the processing system generating the one or more hash values.

[0018] However, there may be no mechanisms for the UFS host controller to generate the one or more hash values in an inline manner during a write operation. For example, the UFS host controller may not obtain an indication of a memory location in which hash values of data being written to the UFS device are to be stored. Therefore, inline hashing may be unavailable during the write operation. Additionally, the processing system may still generate the one or more pre-generated hash values for data being stored in the UFS device. The generation of the one or more pre-generated hash values may consume processing resources of the processing system or the electronic device.

[0019] Various aspects relate generally to inline hashing for data write scenarios. Some aspects more specifically relate to a host controller (e.g., a UFS host controller) generating hash values for data being written as part of a write operation (e.g., data being written to memory of a UFS device) for a memory device (e.g., a UFS device) that the host controller is configured to communicate with. In some aspects, the host controller may obtain (e.g., from a processing system) a transfer request that indicates data to be written to a memory device (e.g., a UFS device) . The host controller may obtain, from volatile memory or other memory, the data based on obtaining the transfer request. The host controller may generate, based on the transfer request, one or more hash values based on the data. The host controller may write, to the volatile memory or other memory, the one or more hash values. The host controller may provide, to the memory device (e.g., the UFS device) , the data as part of the write operation.

[0020] For example, the host controller may generate and store hash values for data during a write operation associated with the data. In other words, the host controller may generate the hash values “on-the-fly” during the write operation. For example, the host controller may identify a memory location in which the hash values are to be stored using a hash data PRDT (e.g., such as the hash data PRDT used to identify where hash values are stored during a read operation, as described above) . The hash values generated by the host controller can be later used for verification when the data is read from the memory device (e.g., from the UFS device) .

[0021] Particular aspects of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. In some examples, the described techniques can be used to enable an inline hashing operation to be performed by the host controller during write operations. By the host controller generating the one or more hash values during the write operation, processing resources or power resources, among other examples, may be conserved that would have otherwise been used by the processing system pre-generating hash values for the data. For example, the generation of the hash values used to verify data stored on a memory device (e.g., a UFS device) may be performed used a hardware-based operation (e.g., by the host controller) , rather than a software-based operation (e.g., by software executing on the processing system) . This hardware-based operation may be associated with reduced latency, reduced power consumption, or reduced processing resource consumption, among other examples, as compared to the software-based operation. Additionally, by the host controller using the hash data PRDT (e.g., the hash data PRDT used to identify where hash values are stored during a read operation) to identify a memory location in which the hash value (s) are to be stored, the inline hashing operation for write scenarios may be associated with reduced complexity because the host controller can reuse the format and structure of the existing hash data PRDT.

[0022] Fig. 1 is a diagram of an example 100 of an electronic device 105 that can support inline hashing for data write scenarios. For example, techniques described herein to provide inline hashing for data write scenarios may be provided in or integrated into the electronic device 105. The electronic device 105 may be a set top box, an entertainment unit, a navigation device, a communications device, a fixed location data unit, a mobile location data unit, a global positioning system (GPS) device, a mobile phone, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a tablet, a phablet, a server, a computer, a portable computer, a mobile computing device, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, or augmented reality glasses or a virtual reality headset, among other examples) , a desktop computer, a personal digital assistant (PDA) , a monitor, a computer monitor, a television, a tuner, a radio, a satellite radio, a music player, a digital video player, a portable digital video player, an automobile, a vehicle component, an Internet-of-things (IoT) device, avionics systems, or a foldable device, among other examples.

[0023] Accordingly, Fig. 1 illustrates an exemplary electronic device 105 that can support the techniques described herein for inline hashing for data write scenarios. For example, as shown in Fig. 1, the electronic device 105 may include a host system 110, a memory system 115, and a UFS device 120.

[0024] The memory system 115 may be any electronic device configured to store data in memory. In some aspects, the memory system 115 may be an electronic device configured to store data temporarily in volatile memory. For example, memory system 115 may be a random-access memory (RAM) device, such as a dynamic RAM (DRAM) device or a static RAM (SRAM) device. In this case, the memory system 115 may include volatile memory that requires power to maintain stored data and that loses stored data after the memory system 115 is powered off. For example, the memory system 115 may include one or more latches or RAM, such as DRAM or SRAM. In some aspects, the memory system 115 may include non-volatile memory configured to maintain stored data after the memory system 115 is powered off, such as NAND memory or NOR memory. For example, the non-volatile memory may store persistent firmware or other instructions for execution by the memory system 115. In some aspects, the memory system 115 may include host memory configured to store data for the host system 110.

[0025] The host system 110 may include a system-on-chip (SoC) 125. The SoC 125 may include a processing system 130. The processing system 130 may include processor (or “processing” ) circuitry in the form of one or multiple processors, microprocessors, processing units (such as central processing units (CPUs) , graphics processing units (GPUs) , neural processing units (NPUs) (also referred to as neural network processors or deep learning processors (DLPs) ) , or digital signal processors (DSPs) ) , processing blocks, application-specific integrated circuits (ASICs) , programmable logic devices (PLDs) , or other discrete gate or transistor logic or circuitry (any one or more of which may be generally referred to herein individually as a “processor” or collectively as “the processor” or “the processor circuitry” ) . Such processors may be individually or collectively configurable or configured to perform various functions or operations described herein. A group of processors collectively configurable or configured to perform a set of functions may include a first processor configurable or configured to perform a first function of the set and a second processor configurable or configured to perform a second function of the set. In some other examples, each of a group of processors may be configurable or configured to perform a same set of functions.

[0026] The host system 110 may communicate with the memory system 115 via a memory controller 135. The memory controller 135 may be included in the SoC 125. The memory controller 135 may be configured to communicate with the memory system 115 via a memory interface 145 (sometimes referred to as a “host interface” ) . The memory interface 145 may include, for example, DDR, LPDDR, GDDR, a small computer system interface (SCSI) , a serial-attached SCSI (SAS) , a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, a non-volatile memory express (NVMe) interface, a universal serial bus (USB) interface, or an embedded multimedia card (eMMC) interface, among other examples. The memory controller 135 may be any device configured to communicate with the memory system 115. For example, the memory controller 135 may include control logic, a memory controller, a system controller, an ASIC, an FPGA, a processor, a microcontroller, or one or more processing components, among other examples. In some aspects, a set of operations described herein as being performed by the memory controller 135 may be performed by a single controller (e.g., the entire set of operations may be performed by a single high-level or low-level controller) . Alternatively, a set of operations described herein as being performed by the memory controller 135 may be performed by more than one controller (e.g., a first subset of the operations may be performed by a high-level controller and a second subset of the operations may be performed by a low-level controller) . As an example, a high-level controller may be, a DDR / LPDDR memory controller, a solid state drive (SSD) controller, and a low-level controller may be a non-volatile memory controller (e.g., a NAND controller) or a volatile memory controller (e.g., a DRAM controller) .

[0027] The host system 110 may communicate with the UFS device 120 via a UFS host controller 140. The UFS host controller 140 may be included in the SoC 125. The UFS host controller 140 may be configured to communicate with the UFS device 120 via a UFS interface 150. The UFS interface 150 may be a UFS host controller interface (UFSHCI) . The UFS host controller 140 may be any device configured to communicate with the UFS device 120. For example, the UFS host controller 140 may include control logic, a memory controller, a system controller, an ASIC, an FPGA, a processor, a microcontroller, or one or more processing components, among other examples. In some aspects, a set of operations described herein as being performed by the UFS host controller 140 may be performed by a single controller. Alternatively, a set of operations described herein as being performed by the UFS host controller 140 may be performed by more than one controller.

[0028] The UFS device 120 may include one or more flash memory arrays, such as one or more UFS memory arrays, one or more NAND flash memory array, or other non-volatile memory array (s) . For example, UFS may be a type of flash memory that is commonly used in smartphones, vehicles, tablets, cameras, or other portable electronic devices. UFS memory is designed to offer faster data transfer speeds, lower power consumption, or improved reliability compared to other types of memory. UFS uses a layered architecture, consisting of a UFS host / device application layer (e.g., a UFS command set layer (UCS) ) , a transport layer (e.g., a UFS transport layer (UTP) ) , and a physical layer (e.g., a UFS interconnect layer (UIC) ) . A host interface layer is an interface (e.g., the UFS interface 150, described elsewhere herein) between the UFS host controller 140 and the UFS device 120 that supports UFS storage. In some aspects, the UFS host controller 140 may be configured to handle data transfer from the processing system 130 of the host system 110 to the UFS device 120.

[0029] The UFS application layer may be a layer in a UFS protocol stack associated with an interface between a file system of the host system 110 and the UFS device 120, allowing an operating system and one or more applications of the host system 110 (e.g., executing on the processing system 130) to interact with the UFS device 120. The UFS application layer (e.g., via an application driver, such as a SCSI driver) may abstract the complexities of flash memory management, wear-leveling, or error correction, reducing the complexity associated with applications to work with UFS storage.

[0030] The UFS protocol stack may include a UFS transport layer (UTP) . The UFS transport layer may be associated with managing physical and data link aspects of communication between the host system 110 and the UFS device 120 (e.g., via a UFS driver) . The UFS transport layer may abstract the physical and low-level communication complexities, allowing the upper layers of the UFS protocol stack, such as the UFS application layer, to interact with the UFS device 120. The UFS transport layer may be associated with performing operation (s) for physical layer management and data link layer management (e.g., UFS interconnect layer management) , initialization and link configuration, or command queuing and transport layer protocols, among other examples. Transactions for the UFS transport layer may include packets referred to as UFS protocol information units (UPIUs) . There may be different types of UPIUs for handling application commands, data operations, task management operations, read operations, write operations, or query operations, among other examples. Each transaction may include a command UPIU, zero or more data in or data out UPIUs, and a response UPIU.

[0031] The UFS protocol stack may include a UFS interconnect layer. The UFS interconnect layer may be the lowest layer of the UFS protocol stack. The UFS interconnect layer may handle the connection between the host system 110 and the UFS device 120 (e.g., between the UFS host controller 140 and the UFS device 120) . The UFS interconnect layer may include a universal protocol (UniPro) component that is configured to perform UniPro operations defined, or otherwise fixed, by the mobile industry processor interface (MIPI) alliance. The UniPro component may have four layers. Layer 1 may be a physical layer, layer 2 may be a data link layer, layer 3 may be a network layer, and layer 4 may be a transport layer. Layer 1 and layer 2 may ensure the data integrity and reliability of the communication link between the host system 110 and the UFS device 120 (e.g., between the UFS host controller 140 and the UFS device 120) . Layer 3 and layer 4 may ensure that the data is routed to the intended UFS host or device (e.g., the UFS host controller 140) . The UFS interconnect layer may include an MIPI physical (M-PHY) component (e.g., that uses a physical layer protocol defined, or otherwise fixed, by the MIPI Alliance) . The UFS device 120 and the UFS host controller 140 may use the M-PHY component for physical layer operations and the UniPro component for data link layer operations.

[0032] In some aspects, the electronic device 105 may include one or more input devices (e.g., one or more microphones) , one or more output devices (e.g., one or more speakers) , one or more network interface devices, or one or more display controllers, among other examples. The input device (s) can include any type of input device, including input keys, switches, or voice processors, among other examples. The output device (s) can include any type of output device, including audio, video, or other visual indicators, among other examples. In some aspects, the network interface device (s) can be any device configured to allow exchange of data to and from a network. The network can be any type of network, including, but not limited to, a wired or wireless network, a private or public network, a local area network (LAN) , a wireless local area network (WLAN) , a wide area network (WAN) , a personal area network (PAN) , or the Internet. The network interface device (s) can be configured to support any type of communications protocol desired.

[0033] In some aspects, the electronic device 105 may implement one or more techniques or perform one or more operations associated with inline hashing for data write scenarios, as described in more detail elsewhere herein. For example, the host system 110, the SoC 125, the processing system 130, the memory controller 135, the UFS host controller 140, the memory system 115, or the UFS device 120, or any other component (s) of Fig. 3 or Fig. 4 may perform or direct operations of, for example, process 500 of Fig. 5 or other processes as described herein (alone or in conjunction with one or more other components) . In some examples, the memory system 115 may store data and program codes for the electronic device 105. In some examples, the memory system 115 may include a non-transitory computer-readable medium storing a set of instructions (for example, code or program code) for implementing one or more techniques or performing one or more operations associated with inline hashing for data write scenarios. The memory system 115 may include one or more memories, such as a single memory or multiple different memories (of the same type or of different types) . For example, the set of instructions, when executed (for example, directly, or after compiling, converting, or interpreting) by one or more processors of the electronic device 105, may cause the electronic device 105 to perform process 500 of Fig. 5 or other processes as described herein. In some examples, executing instructions may include running the instructions, converting the instructions, compiling the instructions, or interpreting the instructions, among other examples.

[0034] In some aspects, the electronic device 105 includes means for obtaining, from volatile memory (e.g., DRAM or host memory) , data based on a transfer request associated with a UFS device; means for generating, based on the transfer request, a hash value based on the data; means for writing, to the volatile memory, the hash value; or means for providing, to the UFS device, the data. In some aspects, the means for the electronic device to perform operations described herein may include, for example, the host system 110, the SoC 125, the processing system 130, the memory controller 135, the UFS host controller 140, the memory system 115, or the UFS device 120, or any other component (s) of Fig. 3 or Fig. 4, among other examples.

[0035] As indicated above, Fig. 1 is provided as an example. Other examples may differ from what is described with regard to Fig. 1. For example, some aspects described herein are broadly applicable to other circuits, including circuits that are fully contained on-die (e.g., within an SoC, such as the SoC 125) or circuits associated with non-memory external interfaces (e.g., a serializer / deserializer (SerDes) ) .

[0036] Figs. 2A and 2B are diagrams of an example 200 of data verification using cryptographic techniques. For example, the electronic device 105 may verify data that is read from memory (such as from the memory system 115 or the UFS device 120) . In some aspects, the processing system 130 (e.g., one or more CPUs) may verify the data as described herein in connection with Figs. 2A and 2B.

[0037] Fig. 2A depicts a hash tree that is generated based on hash values of data 205. The data 205 may be any data to be verified. In some examples, the data 205 may be boot data, an operating system file, firmware, an application file, user data, or log data, among other examples.

[0038] The hash values of the data 205 may be pre-generated hash values (e.g., generated by the electronic device 105 or the process system 130 prior to performing verification of the data 205) . The hash tree may be a Merkle tree. The hash tree may include multiple layers, shown as four layers in Fig. 2A as an example. The multiple layers may include a first layer 210 (shown as “Layer 0” ) , a second layer 215 (shown as “Layer 1” ) , a third layer 220 (shown as “Layer 2” ) , and a fourth layer 225 (shown as “Layer 3” ) . The data 205 may be trusted data (e.g., data that the electronic device 105 or the host system 110 determines is trusted or verified) . The electronic device 105 or the host system 110 may generate the hash tree for later verification of the data 205 when the data 205 is read from memory, such as from the memory system 115 or the UFS device 120.

[0039] As an example, the electronic device 105 or the host system 110 may generate the hash tree using portions or chunks of the data 205, such as N kilobyte (KB) portions or chunks of data (e.g., where N is one, two, four, eight, sixteen, thirty-two, sixty-four, or another value) . The portions or chunks of the data 205 are shown as data A through data H in Fig. 2A. For example, the first layer 210 may include hash values that are based on respective portions of the data 205. For example, a hash A may be a hash value based on the data A portion of the data 205, the hash B may be a hash value based on the data B portion of the data 205, and so on.

[0040] The electronic device 105 or the host system 110 may generate a hash value using a hashing algorithm, such as an SHA (such as SHA-256) , or another cryptographic hashing algorithm. For example, the electronic device 105 or the host system 110 may generate the hash A using the data A, such as by preparing the data A (e.g., passing the data A to fit a block size of the hashing algorithm) , initializing hash values, processing data A in blocks, performing hash computation for the blocks using the hashing algorithm to obtain the hash A. The hashing algorithm may be deterministic in that the same input always produced the same hash value.

[0041] Other layers of the hash tree may include one or more hash values that are based on hash values from lower layers. For example, the second layer 215 may include one or more hash values that are based on hash values from the first layer 210 (e.g., the hash AB may be a hash value that is based on the hash A and hash B as inputs, the hash CD may be a hash value that is based on the hash C and hash D as inputs, and so on) . As another example, the third layer 220 may include one or more hash values that are based on hash values from the second layer 215 (e.g., the hash ABCD may be a hash value that is based on the hash AB and hash CD as inputs, the hash EFGH may be a hash value that is based on the hash EF and hash GH as inputs) . The fourth layer 225 may include a root hash value for the data 205. The root hash value may be a single hash value that is based on the hash values from the third layer 220.

[0042] As shown in Fig. 2B, the data 205 and the hash tree may be stored in memory, such as non-volatile memory (e.g., in the memory system 115) or in flash memory (e.g., in the UFS device 120) . As an example, the data 205 may be stored in a first memory location and the hash tree may be stored in a second memory location. In some examples, a PRDT may indicate the locations in which the data 205 or the hash tree are stored. For example, a data PRDT may indicate the first memory location in which the data 205 is stored. A hash data PRDT may indicate the second memory location in which the hash tree is stored.

[0043] The host system 110 (e.g., the processing system 130) may perform a verification operation for the data 205 (e.g., after reading the data, such as from the memory system 115 or from the UFS device 120) using the hash tree (e.g., using pre-generated hash values for the data 205) . For example, host system 110 (e.g., the processing system 130) may read or load data or hash values to a temporary storage location 230 (e.g., a cache, double-data-rate (DDR) memory, or volatile memory) for the verification operation. As shown by reference number 235, a portion of data (such as the data A shown in Fig. 2A) may be read from the first memory location and loaded in the temporary storage location 230. For example, the data 205 may be read and loaded from the first memory location to the temporary storage location 230. For each N KB portion of the data 205, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may calculate a hash value for the data read from the first memory location. For example, as shown by reference number 240, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may calculate a hash value for the data A read from the first memory location and may store the calculated hash value in the temporary storage location 230. The processing system 130 or the UFS host controller 140 may similarly generate or calculate hash values for each N KB portion of the data 205.

[0044] The host system 110 (e.g., the processing system 130 or the UFS host controller 140) may perform a lookup operation to identify where a first pre-generated (or pre-calculated) hash value (e.g., from the first layer 210) for the data A from the hash tree is stored in the second memory location. The first pre-generated hash value may be the hash A shown in Fig. 2A. As shown by reference number 245, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may read the pre-generated (or pre-calculated) hash value for the data A from the second memory location and load the first pre-generated hash value in the temporary storage location 230. As shown by reference number 250, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may calculate a hash value for the first pre-generated (or pre-calculated) hash value (and one or more other hash value values) read from the second memory location and may store the calculated hash value in the temporary storage location 230. The host system 110 (e.g., the processing system 130 or the UFS host controller 140) may perform a lookup operation to identify where a second pre-generated (or pre-calculated) hash value (e.g., from the second layer 215) for the first pre-generated hash value is stored in the second memory location. The second pre-generated hash value may be the hash AB shown in Fig. 2A. As shown by reference number 255, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may read the second pre-generated (or pre-calculated) hash value from the second memory location and load the second pre-generated hash value in the temporary storage location 230. As shown by reference number 260, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may calculate a hash value for the second pre-generated (or pre-calculated) hash value that was read from the second memory location and may store the calculated hash value in the temporary storage location 230.

[0045] The host system 110 (e.g., the processing system 130 or the UFS host controller 140) may perform a lookup operation to identify where a third pre-generated (or pre-calculated) hash value (e.g., from the third layer 220) for the second pre-generated hash value is stored in the second memory location. The third pre-generated hash value may be the hash ABCD shown in Fig. 2A. As shown by reference number 265, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may read the third pre-generated hash value from the second memory location and load the third pre-generated hash value in the temporary storage location 230. As shown by reference number 270, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may calculate a hash value for the third pre-generated (or pre-calculated) hash value that was read from the second memory location and may store the calculated hash value in the temporary storage location 230. As shown by reference number 275, the host system 110 (e.g., the processing system 130 or the UFS host controller 140) may read the root hash (e.g., from the fourth layer 225) from the second memory location and may store the root hash in the temporary storage location 230.

[0046] The verification operation may include a comparison of hash values that were generated or calculated by the host system 110 (e.g., the processing system 130 or the UFS host controller 140) based on data or hash values read from the first memory location and the second memory location. For example, as shown by reference number 280, the processing system 130 may compare the hash value generated as described above in connection with reference number 240 to the hash value generated as described above in connection with reference number 250. If the hash values match, then the processing system 130 may determine that the data A (read as described in connection with reference number 235) is verified. The processing system 130 may similarly verify hash values read from the second memory location to ensure that the hash values were not modified or tampered with while stored in the second memory location. For example, as shown by reference number 285, the processing system 130 may compare the hash value generated as described above in connection with reference number 250 to the ash value generated as described above in connection with reference number 260. Additionally, as shown by reference number 290, the processing system 130 may compare the hash value generated as described above in connection with reference number 260 to the ash value generated as described above in connection with reference number 270. Finally, as shown by reference number 295, the processing system 130 may compare the hash value generated as described above in connection with reference number 270 to the root hash read from the second memory location, as described above in connection with reference number 275. If the comparisons indicate matching hash values, then the processing system 130 may verify the data A from the data 205. The processing system 130 may similarly verify other portions of the data 205.

[0047] As a result, the processing system 130 may verify that the data 205 read from the first memory location is authentic or has not been tampered with. Additionally, the processing system 130 may verify that the hash tree stored in the second memory location is authentic or has not been tampered with. This improves the security and reliability of the data 205. However, the processing system 130 may consume processing resources or time associated with generating the one or more pre-generated hash values in the hash tree (e.g., as described in connection with Fig. 2A) .

[0048] As indicated above, Figs. 2A and 2B are provided as examples. Other examples may differ from what is described with regard to Figs. 2A and 2B.

[0049] Fig. 3 is a diagram of an example 300 associated with inline hashing for data write scenarios. As shown in Fig. 3, a processing system 305 (e.g., the processing system 130) , a host controller 310 (e.g., the UFS host controller 140) , and a UFS device 315 (e.g., the UFS device 120) may communicate with each other. The operations depicted and described in connection with Fig. 3 may be associated with a write operation for data to be written to memory (e.g., flash memory or non-volatile memory) of the UFS device 315.

[0050] Some examples are described herein using the UFS device 315 as an example target device to which data is to be written. However, the aspects and techniques described herein may be similarly applied to other types of target devices or memory devices, such as an SSD device, an NVMe device, or a hard disk drive (HDD) device, among other examples. The aspects and techniques described herein are not limited to UFS devices as the target device.

[0051] As shown by reference number 320, the processing system 305 may generate a transfer request for a write operation. For example, the processing system 305 may determine that data stored in memory (e.g., host memory, a memory system (e.g., the memory system 115) , a cache, volatile memory, or non-volatile memory) is to be written to memory (e.g., flash memory or non-volatile memory) of the UFS device 315. The processing system 305 may generate a transfer request descriptor (e.g., a UTP transfer request descriptor) for the transfer request. The transfer request descriptor may indicate that the transfer request is for a write operation. For example, the transfer request descriptor may indicate a data direction indicating that the transfer is from system memory (e.g., host memory) to a target device (e.g., the UFS device 315) . Additionally, the transfer request descriptor may indicate a physical address in memory indicating where the data to be transferred to the UFS device 315 is stored.

[0052] In some aspects, the transfer request (e.g., the transfer request descriptor) may include an indication that the data to be transferred (e.g., written) is associated with cryptographic verification, such as the verification operation described in connection with Figs. 2A and 2B. For example, the transfer request (e.g., the transfer request descriptor) may include a flag that is set to a value that indicates that the data to be transferred (e.g., written) is associated with cryptographic verification. The indication associated with cryptographic verification may indicate to the host controller 310 that inline hashing is to be performed as part of the data transfer (e.g., as part of the write operation) , as described in more detail elsewhere herein.

[0053] As shown by reference number 330, the host controller 310 may parse the transfer request. For example, the host controller 310 may parse the transfer request descriptor. The host controller 310 may determine that the transfer request is for a data transfer to the UFS device 315 (e.g., a write operation for the UFS device 315) based on the transfer request descriptor. For example, the host controller 310 may determine that the an operation code indicates that the operation for the transfer request is a write operation. The host controller 310 may determine that the write operation is associated with inline hashing based on the transfer request (e.g., the transfer request descriptor) including the flag that is set to the value that indicates that the data to be transferred (e.g., written) is associated with cryptographic verification.

[0054] The host controller 310 may determine a data length for the transfer request (e.g., an amount of data to be transferred or written to the UFS device 315) . In some aspects, the host controller 310 may determine a memory location in the UFS device 315 in which the data is to be written or stored.

[0055] As shown by reference number 335, the host controller 310 may provide or transmit, and the UFS device 315 may obtain or receive, a write command associated with the transfer request. For example, the host controller 310 may provide or transmit, and the UFS device 315 may obtain or receive, a write command UPIU. The write command UPIU may include a header that indicate a data transfer direction (e.g., to indicate that data is to be written to the UFS device 315) , a task management indication, or a size of the data to be written to the UFS device 315. In some aspects, the write command UPIU may indicate command information, such as an operation code indicating that the transfer is a write operation, a logical unit number (LUN) indicating a target logical unit (or partition) within the UFS device 315 associated with the data to be written, a block address (or address pointer) to indicate the address or location where the data is to be written in memory of the UFS device 315, or a data length, among other examples. The write command UPIU may enable the UFS device 315 to prepare to perform the write operation.

[0056] As shown by reference number 340, the UFS device 315 may provide or transmit, and the host controller 310 may obtain or receive, a ready to transfer indication. For example, the UFS device 315 may provide or transmit, and the host controller 310 may obtain or receive, a ready to transfer UPIU. The ready to transfer UPIU may indicate that the UFS device 315 is ready to begin the write operation. For example, the ready to transfer UPIU may indicate that the UFS device 315 successfully received and processed the write command UPIU, performed any necessary preparations for the write operation, and is now ready to begin the data transfer from the host system (e.g., from the host controller 310) to the UFS device 315.

[0057] As shown by reference number 345, the host controller 310 may obtain data to be written to the UFS device 315. For example, the transfer request descriptor may include, indicate, or point to, a PRDT. In some aspects, the transfer request descriptor may indicate an entry in the PRDT corresponding to the data to be transferred to the UFS device 315.

[0058] The host controller 310 may identify based on the transfer request, an entry in a PRDT that indicates a memory location in which the data is stored. For example, the PRDT may indicate or describe one or more physical regions (e.g., memory buffers) in which data to be transferred is stored. Each entry in a PRDT may refer to a contiguous memory region (or segment) that can store a block of data to be transferred. For example, a data PRDT may indicate a memory location in volatile memory (e.g., DRAM memory) in which the data to be transferred to the UFS device 315 is stored. The host controller 310 may use the memory address and data size indicated by the PRDT to obtain (e.g., read or fetch) the data. For example, the host controller 310 may communicate with a memory controller (e.g., the memory controller 135) to cause the memory controller to obtain the data from the memory address (e.g., in DRAM or other memory) and provide the data to the host controller 310.

[0059] In some aspects, the host controller 310 may identify, based on the transfer request, an entry in the PRDT (or another PRDT) that indicates a memory location, in the volatile memory or other host memory, in which one or more hash values for the data (e.g., the data that is being written to the UFS device 315) are to be stored. For example, the PRDT may be a hash data PRDT that describe one or more physical regions in which hash data is to be stored. The hash data may include one or more hash values or a hash tree for a data block. The hash data PRDT may be included in a PRDT having the structure of the data PRDT, thereby reducing complexity associated with the host controller 310 identifying where the hash value (s) are to be written during the write operation (e.g., because the host controller 310 can reuse the existing structure and format of the data PRDT) .

[0060] The host controller 310 may identify an entry in the hash data PRDT corresponding to the data being written to the UFS device 315. For example, the host controller 310 may identify the entry corresponding to the data identified by the transfer request (e.g., identified by the UTP transfer request descriptor obtained from the processing system 305) . The entry may indicate or describe a memory location (e.g., in DRAM or other host memory) in which one or more hash values for the data is to be stored.

[0061] As shown by reference number 350, the host controller 310 may generate (or calculate) one or more hash values of the data. For example, the host controller 310 may use a hashing algorithm (such as an SHA or other deterministic hashing algorithm) to generate a hash value based on the data that is being written to the UFS device 315. For example, the host controller 310 may use the data as an input to the hashing algorithm. An output of the hashing algorithm may include the hash value. The host controller 310 may generate the one or more hash values in a similar manner as described in connection with Figs. 2A and 2B. In some aspects, as shown in Fig. 3, the one or more hash values may be generated by the host controller 310 after obtaining the indication that the UFS device 315 is ready for data transfer (e.g., as shown by reference number 340) . This ensures that the host controller 310 generates the one or more hash values only after the UFS device 315 confirms that the data can be transferred to (e.g., written to) the UFS device 315. This conserves processing resources that would have otherwise been associated with the host controller 310 generating the one or more hash values in a scenario where the UFS device 315 cannot accept or begin the data transfer or write operation.

[0062] As shown by reference number 355, the host controller 310 may write the one or more hash values to memory (e.g., DRAM or other host memory) . For example, the host controller 310 may write the one or more hash values to the memory location indicated by the entry in the hash data PRDT. For example, the host controller 310 may write the one or more hash values to a hash data base address indicated by the entry in the hash data PRDT. For example, the host controller 310 may communicate with a memory controller (e.g., the memory controller 135) to cause the memory controller to write the one or more hash values to the memory location indicated by the entry in the hash data PRDT.

[0063] As a result, the host controller 310 may generate or compile hash values for data being written to the UFS device 315 during runtime (e.g., “on-the-fly” during a write operation for the data) . This conserves processing resources, or reduces latency, among other examples, that would have otherwise been associated with the processing system 305 (e.g., by software executing on the processing system 305) generating or compiling the hash values. Additionally, by the host controller 310 generating the hash values for the data during runtime as the data is being written to the UFS device 315, the need for the processing system 305 to generate the hash values for the data prior to data transfer is eliminated. For example, the processing system 305 (e.g., software executing on the processing system 305) may no longer pre-generate hash values for the data prior to transferring the data to the UFS device 315. Rather, the host controller 310 may generate or compile hash values as part of a write operation for the data, thereby enabling the processing system 305 to conserve processing resources that would have otherwise been associated with the processing system 305 pre-generating hash values for the data prior to causing the data to be transferred to the UFS device 315. This improves the efficiency of the hash generation operation.

[0064] In some aspects, the host controller 310 may generate the hash value (s) (e.g., as shown by reference number 350) or write the hash values to memory (e.g., as shown by reference number 355) prior to providing or transferring the data to the UFS device 315 (e.g., as shown in Fig. 3) . In other examples, these operations may be performed in a different order. For example, the host controller 310 may generate the hash value (s) (e.g., as shown by reference number 350) or write the hash values to memory (e.g., as shown by reference number 355) after providing or transferring the data to the UFS device 315. As another example, the host controller 310 may generate the hash value (s) (e.g., as shown by reference number 350) prior to providing or transferring the data to the UFS device 315 and may write the hash values to memory (e.g., as shown by reference number 355) after providing or transferring the data to the UFS device 315.

[0065] As shown by reference number 360, the host controller 310 may provide or transmit, and the UFS device 315 may obtain or receive, the data. For example, the host controller 310 may provide or transmit, and the UFS device 315 may obtain or receive, a data-out UPIU. The data-out UPIU may contain the actual data to be written to the UFS device 315. In some examples, the data may be included in multiple data-out UPIUs. The data-out UPIU may indicate an operational code (e.g., indicating that the operation is a write operation) , a data length, a LUN, an address, or one or more data transfer attributes (such as cache management or other data transfer attributes) , among other examples. As shown by reference number 365, the UFS device 315 may write the data to memory (e.g., flash memory or non-volatile memory) . For example, the UFS device 315 may write the data to an address indicated by the write command UPIU or the data-out UPIU.

[0066] As shown by reference number 370, the UFS device 315 may provide or transmit, and the host controller 310 may obtain or receive, a response indicating whether the data was successfully written to memory in the UFS device 315. For example, the UFS device 315 may provide or transmit, and the host controller 310 may obtain or receive, a response UPIU that indicates whether the data was successfully written to memory in the UFS device 315. As shown by reference number 375, the UFS device may provide or transmit, and the processing system 305 may obtain or receive, an interrupt communication (e.g., a completion interrupt) indicating that the transfer request indicated by the process system 305 (e.g., as described in connection with reference number 325) is completed. The completion interrupt may indicate that the write operation has been completed. In some aspects, the completion interrupt may indicate whether the data was successfully written to memory in the UFS device 315 (e.g., as indicated by the response UPIU from the UFS device 315) . Additionally, or alternatively, the completion interrupt may indicate that the one or more hash values for the data have been generated or stored in host memory by the host controller 310.

[0067] In some aspects, the processing system 305 or the host controller 310 may cause the one or more hash values to be written to, or transferred to, the UFS device 315. For example, the host controller 310 may continue to generate a hash tree for a data block (e.g., as described in connection with Fig. 2A) as portions of a data block (or image) are written to the UFS device 315. For example, the host controller 310 may generate hash values for a first layer (e.g., a layer 0) of the hash treen as the portions of the data are written to the UFS device 315, as described herein. After the host controller 310 has generated and stored enough hash values to generate a hash value in an upper layer of the hash tree (e.g., a layer 1 or a layer 2) , the host controller 310 may generate the hash value in the upper layer based on hash values generated and stored by the host controller 310 for the lower layer (s) of the hash tree. After the entire data block is written to the UFS device 315, the host controller 310 may generate all hash values (e.g., including the root hash) for the hash tree associated with the data block. In some aspects, after the entire data block is written to the UFS device 315, the processing system 305 may cause the hash values (e.g., included in the hash tree) to be transferred to (e.g., written to) the UFS device 315.

[0068] The processing system 305 may use the hash values (e.g., included in the hash tree) to verify the data after the data is read from the UFS device 315 (e.g., in a similar manner as described in connection with Fig. 2B) . For example, the processing system 305 may cause the host controller 310 to read the data from the UFS device 315. The host controller 310 may read the data and the hash values stored by the UFS device 315 (e.g., where the hash values were generated by the host controller 310 during one or more write operations in which the data was written to, or transferred to, the UFS device 315) . The host controller 310 may generate and store (e.g., in host memory) hash value (s) based on the data that is read from the UFS device 315. The processing system 305 may use these generated hash value (s) and the hash values read from the UFS device 315 to verify the data that is read from the UFS device 315 (e.g., in a similar manner as described in connection with Fig. 2B) .

[0069] As indicated above, Fig. 3 is provided as an example. Other examples may differ from what is described with regard to Fig. 3.

[0070] Fig. 4 is a diagram of an example 400 associated with inline hashing for data write scenarios. As shown in Fig. 4, an SoC 405 may include a processing system 410 (e.g., the processing system 130 or the processing system 305) , a memory controller 415 (e.g., the memory controller 135) , and a UFS host controller 420 (e.g., the UFS host controller 140 or the host controller 310) . The SoC 405 may communicate with a memory system 425 (e.g., via the memory controller 415) and a UFS device 430 (e.g., via the UFS host controller 420) . The UFS device 430 may be similar to the UFS device 120 or the UFS device 315. The memory system 425 may be similar to the memory system 115. In some aspects, the memory system 425 may include host memory (e.g., memory used by a host system in which the SoC 405 is included) . The host memory may be volatile memory or non-volatile memory. In some aspects, the memory system 425 may include temporary storage (e.g., DRAM or other volatile memory) used by the host system to temporary store data associated with data transfers, such as a write operation for writing data to the UFS device 430.

[0071] In some aspects, the UFS host controller 420 may include a hash generation component 435. The hash generation component 435 may be configured to generate (e.g., calculate) hash values based on input data, in a similar manner as described in more detail elsewhere herein. For example, the hash generation component 435 may be configured to generate hash values in accordance with a hashing algorithm, such as an SHA. The UFS host controller 420 may generate one or more hash values using the hash generation component 435, such as described in connection with reference number 350 and Fig. 3.

[0072] In some aspects, the processing system 410 may initiate a data transfer to cause data to be written to the UFS device 430. For example, the processing system 410 may provide a transfer request to the UFS host controller 420, such as described in connection with reference number 325 and Fig. 3. As shown by reference number 440, the UFS host controller 420 may obtain data 445 from the memory system 425. For example, an entry in a data PRDT may indicate a physical location in the memory system 425 in which the data 445 is stored. The UFS host controller 420 may communicate with the memory controller 415 to cause the memory controller 415 to obtain the data 445 (e.g., from the physical location) and provide the data 445 to the UFS host controller 420. As shown by reference number 450, the UFS host controller 420 may provide the data 445 to the UFS device 430. The UFS device 430 may write data 445 to memory (e.g., flash memory or non-volatile memory) in the UFS device 430 based on the data 445 provided by the UFS host controller 420.

[0073] Additionally, as part of the write operation, the UFS host controller 420 may generate one or more hash values based on the data 445 (e.g., using the hash generation component 435) . The UFS host controller 420 may generate the one or more hash values in a similar manner as described in connection with reference number 350 and Fig. 3. As shown by reference number 460, the UFS host controller 420 may write the one or more hash values to the memory system 425. For example, a hash data PRDT may indicate a physical location in the memory system 425 in which hash values for the data 445 are to be stored. The UFS host controller 420 may identify an entry in the hash data PRDT corresponding to the data 445. The entry may indicate an address (e.g., a physical location) in the memory system 425 (e.g., in host memory, such as DRAM or other non-volatile memory) in which the one or more hash values are to be stored. The UFS host controller 420 may communicate with the memory controller 415 to cause the memory controller 415 to write the one or more hash values to the address (e.g., the physical location) in memory of the memory system 425, shown as hash values 465 in Fig. 4. The UFS host controller 420 may write the one or more hash values to the memory system 425 (e.g., to volatile memory) to enable the processing system 410 to perform one or more actions using the one or more hash values. For example, the UFS host controller 420 store the one or more hash values to the memory system 425 (e.g., to volatile memory) so that the processing system 410 can access, read, or write, among other examples, the hash values. In some aspects, the UFS host controller 420 may write the one or more hash values to non-volatile memory. In some other aspects, the UFS host controller 420 may write the one or more hash values directly to the UFS device 430.

[0074] In some aspects, as data for a data block (such as the data 205) is written to the UFS device 430, the UFS host controller 420 may generate and write hash values 465 to the memory system 425. After the data block is written to the UFS device 430, the UFS host controller 420 may have generated and written hash values (e.g., to the hash values 465) for a hash tree corresponding to the data block (e.g., in a similar manner as depicted and described in connection with Fig. 2A) .

[0075] In some aspects, after the one or more hash values 465 are written to the memory of the memory system 425, the processing system 410 may cause the one or more hash values 465 to be written to the UFS device 430 (e.g., in flash memory or non-volatile memory of the UFS device 430) . For example, one or more hash values 470 may be written to the UFS device 430 (e.g., via the UFS host controller 420) . The one or more hash values 470 may be used to verify the data 455 stored by the UFS device 430.

[0076] For example, the processing system 410 may include a verification component 475. The verification component 475 may be configured to verify data that is read from a target device, such as the UFS device 430. As an example, the UFS host controller 420 may read the data 455 (e.g., a data block) from the UFS device 430. In some aspects, the UFS host controller 420 may read the one or more hash values 470 from the UFS device 430 (e.g., hash value (s) corresponding to the data 455) . In other aspects, the UFS host controller 420 or the memory controller 415 may read or obtain the one or more hash values (e.g., hash values generated by the UFS host controller 420 during write operation as described herein) from another memory location, such as from the memory system 425 or other memory. The UFS host controller 420 may generate one or more hash values (e.g., via the hash generation component 435) based on the data 455 read from the UFS device 430. In other aspects, the processing system 410 may generate one or more hash values based on the data 455 read from the UFS device 430.

[0077] The verification component 475 may compare the hash value (s) generated based on the data 455 to the one or more hash values generated by the UFS host controller 420 during write operation as described herein (e.g., read from the hash values 470 stored by the UFS device 430 or from another memory location) . The comparisons are described in more detail in connection with Fig. 2B. If the comparisons match, then the verification component 475 may verify the data 455 that is read from the UFS device 430. If the comparisons do not match, then the verification component 475 may determine that the data 455 is not verified. In such examples, the processing system 410 may refrain from using the data 455 for one or more operations.

[0078] As indicated above, Fig. 4 is provided as an example. Other examples may differ from what is described with regard to Fig. 4.

[0079] Fig. 5 is a flowchart of an example process 500 associated with inline hashing for data write scenarios. One or more process blocks of Fig. 5 are performed by a host controller (e.g., the host controller 310, the UFS host controller 420, or the UFS host controller 140) or by another device or a group of devices separate from or including the host controller, such as the electronic device 105, one or more devices or components included in the electronic device 105 (e.g., the SoC 125, the processing system 130, the memory controller 135, the memory system 115, or the UFS device 120) , the processing system 305, the UFS device 315, the SoC 405, the processing system 410, the memory controller 415, the hash generation component 435, the memory system 425, or the UFS device 430, among other examples.

[0080] As shown in Fig. 5, process 500 optionally includes obtaining a transfer request that indicates data to be written to a UFS device (block 510) . For example, the host controller may obtain a transfer request that indicates data to be written to a UFS device, as described above. As further shown in Fig. 5, process 500 includes obtaining the data based on the transfer request (block 520) . For example, the host controller may obtain the data based on the transfer request, as described above.

[0081] As further shown in Fig. 5, process 500 includes generating a hash value based on the data (block 530) . For example, the host controller may generate a hash value based on the data, as described above. As further shown in Fig. 5, process 500 includes writing, to the volatile memory, the hash value (block 540) . For example, the host controller may write, to the volatile memory, the hash value, as described above. As further shown in Fig. 5, process 500 includes providing, to the UFS device, the data (block 550) . For example, the host controller may provide, to the UFS device, the data, as described above.

[0082] Process 500 may include additional aspects, such as any single aspect or any combination of aspects described below or in connection with one or more other processes described elsewhere herein.

[0083] In a first aspect, process 500 includes identifying, based on the transfer request, an entry in a PRDT that indicates a memory location, in the volatile memory, in which the hash value is to be stored, and writing the hash value includes writing the hash value to the memory location in the volatile memory.

[0084] In a second aspect, alone or in combination with the first aspect, the PRDT is associated with hash data stored in the volatile memory.

[0085] In a third aspect, alone or in combination with one or more of the first and second aspects, process 500 includes writing, to the UFS device, one or more hash values from one or more memory locations indicated by the PRDT, where the one or more hash values include the hash value, and where the one or more memory locations include the memory location.

[0086] In a fourth aspect, alone or in combination with one or more of the first through third aspects, the one or more hash values are included in a data verification hash tree associated with verification of a data block in which the data is included.

[0087] In a fifth aspect, alone or in combination with one or more of the first through fourth aspects, the transfer request includes an indication that the data is associated with cryptographic verification, and generating the hash value is based on the transfer request including the indication that the data is associated with cryptographic verification.

[0088] In a sixth aspect, alone or in combination with one or more of the first through fifth aspects, process 500 includes providing, to the UFS device, a write command based on the transfer request, and obtaining, from the UFS device, an indication that the UFS device is ready for data transfer, where the hash value is generated after obtaining the indication that the UFS device is ready for data transfer.

[0089] In a seventh aspect, alone or in combination with one or more of the first through sixth aspects, process 500 includes identifying, based on the transfer request, an entry in a PRDT that indicates a memory location in which the data is stored, and obtaining the data includes obtaining the data from the memory location in the volatile memory.

[0090] In an eighth aspect, alone or in combination with one or more of the first through seventh aspects, process 500 includes providing, after writing the hash value and providing the data, an interrupt indication that indicates that a write operation indicated by the transfer request is complete.

[0091] Although Fig. 5 shows example blocks of process 500, in some implementations, process 500 includes additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in Fig. 5. Additionally, or alternatively, two or more of the blocks of process 500 may be performed in parallel.

[0092] The following provides an overview of some Aspects of the present disclosure:

[0093] Aspect 1: A method performed by a host controller, comprising: obtaining, from volatile memory, data based on a transfer request associated with a UFS device; generating, based on the transfer request, a hash value based on the data; writing, to the volatile memory, the hash value; and providing, to the UFS device, the data.

[0094] Aspect 2: The method of Aspect 1, further comprising: identifying, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored; and wherein writing the hash value comprises: writing the hash value to the memory location in the volatile memory.

[0095] Aspect 3: The method of Aspect 2, wherein the PRDT is associated with hash data stored in the volatile memory.

[0096] Aspect 4: The method of any of Aspects 2-3, further comprising: writing, to the UFS device, one or more hash values from one or more memory locations indicated by the PRDT, wherein the one or more hash values include the hash value, and wherein the one or more memory locations include the memory location.

[0097] Aspect 5: The method of Aspect 4, wherein the one or more hash values are included in a data verification hash tree associated with verification of a data block in which the data is included.

[0098] Aspect 6: The method of any of Aspects 1-5, wherein the transfer request includes an indication that the data is associated with cryptographic verification, and wherein generating the hash value is based on the transfer request including the indication that the data is associated with cryptographic verification.

[0099] Aspect 7: The method of any of Aspects 1-6, further comprising: providing, to the UFS device, a write command based on the transfer request; and obtaining, from the UFS device, an indication that the UFS device is ready for data transfer, wherein the hash value is generated after obtaining the indication that the UFS device is ready for data transfer.

[0100] Aspect 8: The method of any of Aspects 1-7, further comprising: identifying, based on the transfer request, an entry in a PRDT that indicates a memory location in which the data is stored; and wherein obtaining the data comprises: obtaining the data from the memory location in the volatile memory.

[0101] Aspect 9: The method of any of Aspects 1-8, further comprising: providing, after writing the hash value and providing the data, an interrupt indication that indicates that a write operation indicated by the transfer request is complete.

[0102] Aspect 10: The method of any of Aspects 1-9, further comprising: obtaining the transfer request that indicates the data to be written to the UFS device.

[0103] Aspect 11: An electronic device, comprising: a host controller configured to: obtain a transfer request that indicates data to be written to a universal flash storage (UFS) device; obtain, from volatile memory, the data based on the transfer request; generate, based on the transfer request, a hash value based on the data; write, to the volatile memory, the hash value; and provide, to the UFS device, the data.

[0104] Aspect 12: The electronic device of Aspect 10, wherein the host controller is configured to: identify, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored; and wherein the host controller, to write the hash value, is configured to: write the hash value to the memory location in the volatile memory.

[0105] Aspect 13: The electronic device of Aspect 11, wherein the host controller is configured to: write, to the UFS device, one or more hash values from one or more memory locations indicated by the PRDT, wherein the one or more hash values include the hash value, and wherein the one or more memory locations include the memory location.

[0106] Aspect 14: The electronic device of any of Aspects 10-12, wherein the transfer request includes an indication that the data is associated with cryptographic verification, and wherein generation of the hash value is based on the transfer request including the indication that the data is associated with cryptographic verification.

[0107] Aspect 15: The electronic device of any of Aspects 10-13, wherein the host controller is configured to: provide, to the UFS device, a write command based on the transfer request; and obtain, from the UFS device, an indication that the UFS device is ready for data transfer, wherein the hash value is generated after obtaining the indication that the UFS device is ready for data transfer.

[0108] Aspect 16: A system, comprising: volatile memory; a universal flash storage (UFS) device; a processing system; and a UFS host controller configured to: obtain, from the processing system, a transfer request that indicates data to be written to the UFS device; obtain, from the volatile memory, the data based on the transfer request; generate, based on the transfer request, a hash value based on the data; write, to the volatile memory, the hash value; and provide, to the UFS device, the data.

[0109] Aspect 17: The system of Aspect 15, wherein the UFS host controller is configured to: identify, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored.

[0110] Aspect 18: The system of any of Aspects 15-16, wherein the processing system and the UFS host controller are included in a system-on-chip (SoC) of an electronic device.

[0111] Aspect 19: The system of any of Aspects 15-17, wherein the UFS host controller is configured to: provide, to the UFS device, one or more hash values from the volatile memory, wherein the one or more hash values include the hash value, wherein the one or more hash values are associated with a data block that includes the data.

[0112] Aspect 20: The system of Aspect 18, wherein the UFS host controller is configured to: read, from the UFS device, the data block; read, from the UFS device, the one or more hash values; and provide, to the processing system, the data block and the one or more hash values.

[0113] Aspect 21: The system of Aspect 19, wherein the processing system is configured to: verify the data block based on the one or more hash values.

[0114] Aspect 22: A system configured to perform one or more operations recited in one or more of Aspects 1-21.

[0115] Aspect 23: An apparatus comprising means for performing one or more operations recited in one or more of Aspects 1-21.

[0116] Aspect 24: A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising one or more instructions that, when executed by a device, cause the device to perform one or more operations recited in one or more of Aspects 1-21.

[0117] Aspect 25: A computer program product comprising instructions or code for executing one or more operations recited in one or more of Aspects 1-21.

[0118] Aspect 26: A system-on-chip (SoC) configured to perform one or more operations recited in one or more of Aspects 1-21.

[0119] It will be apparent that systems or methods described herein may be implemented in different forms of hardware or a combination of hardware and software. A component being configured to perform a function means that the component has a capability to perform the function, and does not require the function to be actually performed by the component, unless noted otherwise.

[0120] As used herein, the term “determine” or “determining” can encompass one or more of a wide variety of actions. For example, “determining” can include one or more of calculating, computing, processing, deriving, detecting, estimating, investigating, looking up, inferring, ascertaining, measuring, resolving, selecting, choosing, obtaining, identifying, interpreting, demodulating, decoding, reading, establishing, forming or generating, among other examples. In some such examples, determining can involve a processor performing some type of calculating, computing, deriving, estimating, inferring, ascertaining, resolving, predicting or other processing to obtain one or more numerical values, sets, elements or other information or results. In some other such examples, determining can involve a processor identifying, looking up, investigating or otherwise obtaining some type of value, set, element or other information or result from a table, a data structure, a database or other memory device or location. In some other such examples, determining can involve a processor identifying, interpreting, demodulating, decoding, detecting, reading or otherwise obtaining some type of value, set, element or other information or result signaled in, for example, a received wireless packet. In some other such examples, determining can involve a processor selecting or choosing one or more values, sets, elements or other information or results from a larger set of values, sets elements or other information or results. In some other such examples, determining can involve a processor performing a measurement, such as on a received signal.

[0121] As used herein, the articles “a” and “an” are intended to refer to one or more items and may be used interchangeably with “one or more” or “at least one. ” As used herein, a phrase referring to “at least one of” or “one or more of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c. Additionally, as used herein, a phrase referring to “a” or “an” element refers to one or more of such elements acting individually or collectively to perform the recited function (s) . Additionally, as used herein, a “set” can refer to one or more items, and a “subset” can refer to a whole set or less than the whole set, but not an empty set. “Set, ” “group, ” and similar terms are intended to include one or more items and may be used interchangeably with “one or more. ” Furthermore, as used herein, the term “or” is intended to be interpreted in the inclusive sense (such as when referring to a series) and may be used interchangeably with “and / or, ” unless otherwise explicitly indicated (for example, if used in conjunction with “either” or “only one of” ) . For example, “A or B” may include A only, B only, or a combination of A and B. Also, as used herein, the terms “has, ” “have, ” “having, ” “comprise, ” “comprising, ” “include” and “including, ” and derivatives thereof or similar terms are intended to be open-ended terms that do not limit an element that they modify (for example, an element “having” A also may have B) .

[0122] As used herein, the phrase “associated with” is intended to be interpreted in the inclusive sense, unless otherwise explicitly indicated. For example, the phrase “associated with” is not to be construed as a reference to a closed set of conditions, factors, criteria, elements, components, or actions, among other examples. Specifically, unless a phrase refers to “associated with only ‘a, ’ ” or the equivalent in context, whatever it is that is “associated with ‘a, ’ ” may be associated with “a” alone or associated with a combination of “a” and one or more other conditions, factors, criteria, elements, components, or actions, among other examples. In various examples, the phrase “associated with” may be interpreted to mean “in association with, ” “in accordance with, ” “based on, ” “based at least in part on, ” “as a function of, ” “in response to, ” “responsive to, ” or “using” as appropriate in the relevant context unless otherwise explicitly indicated. Furthermore, what follows the phrase “associated with, ” “in association with, ” “in accordance with, ” “based on, ” “based at least in part on, ” “as a function of, ” “in response to, ” “responsive to, ” or “using” is not necessarily the focal point or primary factor associated with the limitation preceding the phrase.

[0123] As used herein, “satisfying a threshold” may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, or not equal to the threshold, among other examples.

[0124] Even though particular combinations of features are recited in the claims or disclosed in the specification, these combinations are not intended to limit the scope of all aspects described herein. Many of these features may be combined in ways not specifically recited in the claims or disclosed in the specification. The disclosure of various aspects includes each dependent claim in combination with every other claim in the claim set.

Claims

1.A method of performed by a host controller, comprising:obtaining, from volatile memory, data based on a transfer request associated with a universal flash storage (UFS) device;generating, based on the transfer request, a hash value based on the data;writing, to the volatile memory, the hash value; andproviding, to the UFS device, the data.2.The method of claim 1, further comprising:identifying, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored; andwherein writing the hash value comprises:writing the hash value to the memory location in the volatile memory.3.The method of claim 2, wherein the PRDT is associated with hash data stored in the volatile memory.4.The method of claim 2, further comprising:writing, to the UFS device, one or more hash values from one or more memory locations indicated by the PRDT, wherein the one or more hash values include the hash value, and wherein the one or more memory locations include the memory location.5.The method of claim 4, wherein the one or more hash values are included in a data verification hash tree associated with verification of a data block in which the data is included.6.The method of claim 1, wherein the transfer request includes an indication that the data is associated with cryptographic verification, and wherein generating the hash value is based on the transfer request including the indication that the data is associated with cryptographic verification.7.The method of claim 1, further comprising:providing, to the UFS device, a write command based on the transfer request; andobtaining, from the UFS device, an indication that the UFS device is ready for data transfer, wherein the hash value is generated after obtaining the indication that the UFS device is ready for data transfer.8.The method of claim 1, further comprising:identifying, based on the transfer request, an entry in a PRDT that indicates a memory location in which the data is stored; andwherein obtaining the data comprises:obtaining the data from the memory location in the volatile memory.9.The method of claim 1, further comprising:providing, after writing the hash value and providing the data, an interrupt indication that indicates that a write operation indicated by the transfer request is complete.10.The method of claim 1, further comprising:obtaining the transfer request that indicates the data to be written to the UFS device.11.An electronic device, comprising:a host controller configured to:obtain, from volatile memory, data based on a transfer request;generate, based on the transfer request, a hash value based on the data;write, to the volatile memory, the hash value; andprovide, to a universal flash storage (UFS) device, the data.12.The electronic device of claim 11, wherein the host controller is configured to:identify, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored; andwherein the host controller, to write the hash value, is configured to:write the hash value to the memory location in the volatile memory.13.The electronic device of claim 12, wherein the host controller is configured to:write, to the UFS device, one or more hash values from one or more memory locations indicated by the PRDT, wherein the one or more hash values include the hash value, and wherein the one or more memory locations include the memory location.14.The electronic device of claim 11, wherein the transfer request includes an indication that the data is associated with cryptographic verification, and wherein generation of the hash value is based on the transfer request including the indication that the data is associated with cryptographic verification.15.The electronic device of claim 11, wherein the host controller is configured to:provide, to the UFS device, a write command based on the transfer request; andobtain, from the UFS device, an indication that the UFS device is ready for data transfer, wherein the hash value is generated after obtaining the indication that the UFS device is ready for data transfer.16.A system, comprising:volatile memory;a universal flash storage (UFS) device;a processing system; anda UFS host controller configured to:obtain, from volatile memory, data based on a transfer request;generate, based on the transfer request, a hash value based on the data;write, to the volatile memory, the hash value; andprovide, to the UFS device, the data.17.The system of claim 16, wherein the UFS host controller is configured to:identify, based on the transfer request, an entry in a physical region descriptor table (PRDT) that indicates a memory location, in the volatile memory, in which the hash value is to be stored.18.The system of claim 16, wherein the UFS host controller is configured to:provide, to the UFS device, one or more hash values from the volatile memory, wherein the one or more hash values include the hash value, wherein the one or more hash values are associated with a data block that includes the data.19.The system of claim 18, wherein the UFS host controller is configured to:read, from the UFS device, the data block;read, from the UFS device, the one or more hash values; andprovide, to the processing system, the data block and the one or more hash values.20.The system of claim 19, wherein the processing system is configured to:verify the data block based on the one or more hash values.

Images