Access control mechanism for virtual functions in universal flash storage I / O virtualization

Abstract

A Universal Flash Storage (UFS) host controller supporting input / output virtualization (IOV) is disclosed. The host controller comprises a programmable Function ID (FID) to Stream ID (SID) mapping unit configured to assign unique stream IDs to physical and virtual UFS Host Controller Interface (UFSHCI) functions. The mapping unit includes registers accessible only within the physical UFSHCI's address space, allowing exclusive control by the host operating system. When a data transfer request is received, the host controller maps it to an assigned stream ID based on the programmable mapping. A UFS device coupled to the host controller validates received stream IDs before executing data transfer requests. This mechanism enables isolation of data streams between virtual functions, enhancing security in virtualized storage environments and accommodating evolving system requirements.

Description

ACCESS CONTROL MECHANISM FOR VIRTUAL FUNCTIONS IN UNIVERSAL FLASH STORAGE I / O VIRTUALIZATIONTECHNICAL FIELD

[0001] This disclosure relates generally to data storage systems, and more specifically, to access control mechanisms for virtual functions in Universal Flash Storage (UFS) systems supporting I / O virtualization.BACKGROUND

[0002] One standard for organization and operation of electronic memory devices is the Universal Flash Storage (UFS) standard. The UFS standard was introduced as a successor to the eMMC (embedded MultiMediaCard) standard to offer higher performance and lower power consumption for mobile and other embedded devices. UFS provides support for a range of features such as multi-lane configurations, command queuing, and power-saving modes that enable high-speed data transfer rates, low latency, and long battery life. The UFS standard specifies many parameters for structuring, reading data from, and writing data to UFS-compliant memory devices. For example, UFS-compliant devices may include digital cameras, mobile phones, consumer electronic devices, and other devices with internal memory capacity. UFS-compliant memory may include memory embedded within electronic devices and removable memory cards, and UFS memory devices may implement NAND flash memory.

[0003] UFS has become increasingly prevalent in modern computing systems because they offer high-speed data transfer and efficient storage capabilities. As systems grow more complex, particularly in areas such as automotive applications, the need for I / O virtualization in UFS has increased. Virtualization allows multiple virtual functions to share a single physical UFS controller to improve resource utilization and flexibility.

[0004] However, implementation of UFS I / O virtualization (UFS-IOV) introduces significant challenges in terms of security and access control. Traditional UFS Host Controllers typically utilize a single, hard-wired Stream ID (SID) for data transfers. But this is problematic in virtualized environments where multiple virtual UFSHCI functions require  isolated data streams to maintain security boundaries between different components or subsystems.

[0005] Current solutions fail to provide adequate isolation between these virtual functions, which potentially allows unauthorized access across security domains. This issue is critical in scenarios like automotive systems where strict isolation between different subsystems is important for functionality and safety.

[0006] Further, the dynamic nature of modern computing environments, with frequently updating driver frameworks and changing security requirements, demands a more flexible and adaptable approach to access control. Static hardware-defined solutions fall short in meeting these needs. As systems continue to increase in complexity, there is an increasing need for a robust, flexible, and secure mechanisms for implementing access control in UFS-IOV scenarios. Such solutions should provide isolation between virtual functions and offer adaptability to changing system requirements and seamless integration with existing system architectures.SUMMARY

[0007] The following summarizes some aspects of the present disclosure to provide a basic understanding of the discussed technology. This summary is not an extensive overview of all contemplated features of the disclosure and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in summary form as a prelude to the more detailed description that is presented later. The systems and devices of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0008] One innovative aspect of the subject matter described in this disclosure can be implemented in a Universal Flash Storage (UFS) host controller. The UFS host controller includes a programmable Function ID (FID) to Stream ID (SID) mapping unit configured to receive a function ID associated with a virtual UFS Host Controller Interface (UFSHCI) function,  map the received function ID to an assigned stream ID based on a programmable mapping, and output the assigned stream ID for use in isolating data streams associated with the virtual UFSHCI function.

[0009] In some examples, the programmable FID to SID mapping unit comprises a set of registers accessible only within an address space of a physical UFSHCI function. The set of registers may be accessible and configurable through an interface that restricts access to the host operating system. The programmable mapping may associate each of a plurality of virtual UFSHCI functions with a unique assigned stream ID, which can be based on offsets from a stream ID of a physical UFSHCI function.

[0010] In certain implementations, the UFS host controller includes an interface configured to receive configuration data for the programmable mapping from a host operating system. The assigned stream ID can be used to differentiate data streams from different virtual UFSHCI functions for implementing access control between security domains. In some cases, the assigned stream ID is used as a device ID for enabling Message Signaled Interrupts (MSIs) with a Generic Interrupt Controller (GIC) Interrupt Translation Service (ITS) .

[0011] The programmable FID to SID mapping unit may be configured to receive configuration commands from a host operating system and deny attempts to modify the programmable mapping from non-host operating system sources. It can also enable dynamic reconfiguration of the programmable mapping in response to changes in system memory management unit (SMMU) driver frameworks and enable allocation of stream IDs by at least one of a UFS host driver or an SMMU driver.

[0012] In automotive applications, the UFS host controller can be configured to assign unique stream IDs to each of a plurality of virtual UFSHCI functions associated with automotive subsystems, enabling isolated data streams for each automotive subsystem.

[0013] Another innovative aspect of the subject matter described in this disclosure can be implemented in a Universal Flash Storage (UFS) system. The system includes a physical UFSHCI function, one or more virtual UFSHCI functions, a programmable FID to SID  mapping unit, and a host operating system configured to control the mapping unit. The mapping unit is configured to assign unique stream IDs to the physical UFSHCI function and each of the virtual UFSHCI functions, and segregate data streams associated with each function according to the assigned stream IDs.

[0014] In some examples, the system includes a memory management unit configured to use the unique stream IDs to enforce memory access restrictions. The host operating system may be configured to dynamically adjust the assignment of stream IDs in response to changes in system configuration or security requirements. The programmable FID to SID mapping unit can be implemented within the physical UFSHCI function and made inaccessible to the virtual UFSHCI functions, further enhancing security.

[0015] Yet another innovative aspect can be implemented in a Universal Flash Storage (UFS) device configured to interact with a UFS Host Controller Interface (UFSHCI) implementing a programmable Function ID (FID) to Stream ID (SID) mapping. The UFS device includes a controller configured to receive at least one data transfer request from the UFSHCI, process the request without utilizing any Stream ID information, and execute the request. The device also includes a memory array accessible by the controller in response to the data transfer request.

[0016] In some implementations, the UFS device controller maintains an internal mapping for managing access to sections of the memory array, independent of any Stream ID assignments in the UFSHCI. The controller processes data transfer requests according to the UFS protocol, irrespective of any Stream ID-based access control implemented in the UFSHCI. The controller may also be configured to update its internal configurations according to instructions received from a host operating system via the UFSHCI, where these instructions are independent of Stream ID assignments. In certain examples, the memory array includes at least one partition, with access managed by the controller independently of any Stream ID-based access control implemented in the UFSHCI.

[0017] A further innovative aspect can be implemented in a complete UFS system comprising both a UFSHCI with a programmable FID to SID mapping unit and a UFS device with a controller for validating stream IDs. This system implements end-to-end access control  across the UFS ecosystem. The programmable FID to SID mapping unit in this system is accessible via a secure interface restricted to the host operating system. The host operating system can adjust the assignment of stream IDs according to changes in system configuration or security requirements. The UFS device controller is configured to deny data transfer requests associated with stream IDs not authorized for the targeted section of the memory array. Additionally, the system may include a memory management unit that uses the unique stream IDs to enforce memory access restrictions for both the physical UFSHCI function and each of the virtual UFSHCI functions.

[0018] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows may be better understood. Additional features and advantages will be described hereinafter. The conception and specific examples disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. Characteristics of the concepts disclosed herein, both their organization and method of operation, together with associated advantages will be better understood from the following description when considered in connection with the accompanying figures. Each of the figures is provided for the purposes of illustration and description, and not as a definition of the limits of the claims.

[0019] While aspects and implementations are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, packaging arrangements. For example, aspects and / or uses may come about via integrated chip implementations and other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, artificial intelligence (AI) -enabled devices, etc. ) . While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range in spectrum from chip-level or modular  components to non-modular, non-chip-level implementations and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for implementation and practice of claimed and described aspects. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes (e.g., hardware components including antenna, radio frequency (RF) -chains, power amplifiers, modulators, buffer, processor (s) , interleaver, adders / summers, etc. ) . It is intended that innovations described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc. of varying sizes, shapes, and constitution.

[0020] BRIEF DESCRIPTION OF THE FIGURES

[0021] A further understanding of the nature and advantages of the present disclosure may be realized by reference to the following drawings. In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If just the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[0022] Figure 1 shows a block diagram of an example data processing system that includes a Universal Flash Storage (UFS) memory system.

[0023] Figure 2 shows a block diagram of an example electronic device including a UFS memory system.

[0024] Figure 3 shows a block diagram illustrating components for facilitating access to a flash memory system from a host device.

[0025] Figure 4 shows a block diagram of a UFS memory system that includes a programmable Function ID (FID) to Stream ID (SID) mapping unit and related architecture.

[0026] Figure 5 shows a flowchart illustrating an example process performable by or at a UFS host controller that implements access control for virtual functions with I / O virtualization.

[0027] Figure 6 shows a block diagram of an example UFS host controller that supports access control for virtual functions with I / O virtualization.

[0028] Figure 7 shows a flowchart illustrating an example process performable by or at a UFS system that implements access control for virtual functions with I / O virtualization.

[0029] Figure 8 shows a block diagram of an example UFS system that supports access control for virtual functions with I / O virtualization.

[0030] Figure 9 shows a flowchart illustrating an example process performable by or at a UFS device that implements access control for data transfers.

[0031] Figure 10 shows a block diagram of an example device that implements access control for data transfers in UFS.

[0032] Figure 11 shows a flowchart illustrating an example process performable by a UFS system that implements access control for data transfers between its UFS Host Controller Interface (UFSHCI) and UFS device components.

[0033] Figure 12 shows a block diagram of an example UFS system that supports access control for data transfers between its UFSHCI and UFS device components.

[0034] Like reference numbers and designations in the various drawings indicate like elements.DETAILED DESCRIPTION

[0035] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to limit the scope of the disclosure. Rather, the detailed description includes specific details for the purpose of providing a thorough understanding of the inventive subject matter. It will be apparent to those skilled in the art that these specific details are not required in every case and that, in  some instances, well-known structures and components are shown in block diagram form for clarity of presentation.

[0036] This disclosure provides an approach to implementing access control in UFS systems that support I / O virtualization (UFS-IOV) . A programmable Function ID (FID) to Stream ID (SID) mapping unit within the UFS Host Controller Interface (UFSHCI) enables flexible assignment of unique Stream IDs to both physical and virtual UFSHCI functions.

[0037] Operating under the control of the host operating system, the programmable FID-to-SID mapping unit ensures a high level of security. Distinct Stream IDs are assigned to each virtual UFSHCI function, allowing for effective isolation of data streams associated with different functions in the host system’s memory. Such functionality is valuable in scenarios involving multiple virtual UFSHCI functions, such as automotive applications where different subsystems require secure and isolated access to system memory.

[0038] A security feature involves the implementation of the mapping unit’s configuration registers within the physical UFSHCI’s address space. Only the host operating system can modify the Stream ID assignments, effectively preventing guest operating systems from altering security settings or bypassing access controls to system memory.

[0039] The UFS device is configured to interact with the UFSHCI, processing data transfer requests independently of the Stream ID assignments. Access control and data stream isolation are implemented within the host system, between the UFS host controller and the system’s main memory, thereby creating a robust security mechanism without requiring changes to the UFS device itself.

[0040] Adapting to evolving system requirements is addressed through the programmable nature of the mapping unit. Dynamic reconfiguration in response to changes in system memory management unit (SMMU) driver frameworks is supported. Flexibility extends to the allocation of Stream IDs, which can be performed by either the UFS host driver or the SMMU driver according to specific implementation needs.

[0041] Implementation of the programmable FID-to-SID mapping unit offers flexibility in Stream ID assignment. Systems can accommodate evolving SMMU driver frameworks and  changing security requirements without necessitating hardware modifications. Exclusive control of the mapping unit by the host operating system enhances security. Restricting configuration access to a specific address space prevents unauthorized modifications of Stream ID assignments by guest operating systems or other non-privileged entities, maintaining the integrity of access control mechanisms.

[0042] Some implementations enable fine access control through the assignment of unique Stream IDs to each virtual UFSHCI function. Different sections of the system’s main memory can be associated with specific Stream IDs, allowing for the creation of secure domains and the enforcement of strict access policies within the host system.

[0043] The access control mechanism implemented in the host system adds an extra layer of security, ensuring that access controls are enforced at the memory level for all interactions between the UFS host controller and system memory.

[0044] In automotive applications, the creation of isolated data streams for each subsystem becomes possible. Isolation within the host system’s memory helps maintain the integrity and security of critical systems, enhancing vehicle safety and reliability. A robust framework for separating different functional domains within a vehicle’s memory system addresses the growing complexity and interconnectedness of modern automotive electronics. Dynamic adjustment of Stream ID assignments in response to system changes offers a future-proof solution, easily adapting to new security requirements or system configurations.

[0045] The implementation of the programmable FID-to-SID mapping unit not only enhances security but also offers potential performance benefits. By efficiently managing access to system memory based on Stream IDs, the UFS host controller can potentially reduce memory access conflicts and optimize data flow. This leads to improved system responsiveness in scenarios with multiple virtual functions competing for memory resources. Further, the flexible nature of the Stream ID assignment allows for future extensions of the system’s capabilities, potentially enabling more sophisticated memory management techniques or integration with other system components as UFS-IOV technology evolves.

[0046] Figure 1 illustrates a data processing system 100, such as may be included in a mobile computing device, according to one or more aspects of the disclosure. Memory may be used in a computing system organized as illustrated in Figure 1. A memory system 110 may couple to a host device 102 through one or more channels. For example, the host device 102 and memory system 110 may be coupled through a serial interface including a single channel for the transport of data or a parallel interface including two or more channels for the transport of data. In some aspects, control data may be transferred through the same channel (s) as the data or the control data may be transferred through additional channels. The host device 102 may be, for example, a portable electronic device such as a mobile phone, an MP3 player, a laptop computer, or a non-portable electronic device such as a desktop computer, a game player, a television (TV) , a media player, or a projector. As another example, the host device 102 may be an automotive computer system. In some examples, the memory system 110 may be included in the host device 102. Thus, the data processing system 100 may be any of the example host devices described herein including the memory system 110. Additional example host devices are illustrated and described with reference to Figure 6.

[0047] The memory system 110 may execute operations in response to commands (e.g., a request) from the host device 102. For example, the memory system 110 may store data provided by the host device 102 and the memory system 110 may also provide stored data to the host device 102. The memory system 110 may be used as a main memory, short-term memory, or long-term memory by the host device 102. As one example of main memory, the host device 102 may use the memory system 110 to supplement or replace a system memory by using the memory system 110 to store temporary data such as data relating to operating systems and / or threads executing in the operation system. As one example of short-term memory, the host device 102 may use the memory system 110 to store a page file for an operating system. As one example of long-term memory, the host device 102 may use the memory system 110 to store user files (e.g., documents, videos, pictures) and / or application files (e.g., word processing executable, gaming application) .

[0048] The memory system 110 may be implemented with any one of various storage devices, according to the protocol of a host interface for the one or more channels coupling the  memory system 110 to the host device 102. The memory system 110 may be implemented with any one of various storage devices, such as a solid state drive (SSD) , a multimedia card (MMC) , an embedded MMC (eMMC) , a reduced size MMC (RS-MMC) , a micro-MMC, a secure digital (SD) card, a mini-SD, a micro-SD, a universal serial bus (USB) storage device, a universal flash storage (UFS) device, a compact flash (CF) card, a smart media (SM) card, or a memory stick.

[0049] The memory system 110 may include a memory module 150 and a controller 130 coupled to the memory module 150 through one or more channels. The memory module 150 may store and retrieve data in memory blocks 152, 154, and 156 under control of the controller 130, which may execute commands received from the host device 102. The controller 130 is configured to control data exchange between the memory module 150 and the host device 102. The storage components, such as blocks 152, 154, and 156 in the memory module 150 may be implemented as volatile memory device, such as, a dynamic random access memory (DRAM) and a static random access memory (SRAM) , or a non-volatile memory device, such as a read only memory (ROM) , a programmable ROM (PROM) , an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a ferroelectric random access memory (FRAM) , a phase-change RAM (PRAM) , a magnetoresistive RAM (MRAM) , a resistive RAM (SCRAM) , a NOR flash memory, or a NAND flash memory.

[0050] The controller 130 and the memory module 150 may be formed as integrated circuits on one or more semiconductor dies (or other substrate) . In some aspects, the controller 130 and the memory module 150 may be integrated into one chip. In some aspects, the memory module 150 may include one or more chips coupled in series or parallel with each other and coupled to the controller 130, which is on a separate chip. In some aspects, the memory module 150 and controller 130 chips are integrated in a single package, such as in a package on package (PoP) system. In some aspects, the memory system 110 is integrated on a single chip with one or more or all of the components (e.g., application processor, system memory, digital signal processor, modem, graphics processor unit, memory interface, input / output interface, network adaptor) of the host device 102, such as in a system on chip (SoC) . The controller 130 and the memory module 150 may be integrated into one  semiconductor device to form a memory card, such as, for example, a Personal Computer Memory Card International Association (PCMCIA) card, a compact flash (CF) card, a smart media card (SMC) , a memory stick, a multimedia card (MMC) , an RS-MMC, a micro-MMC, a secure digital (SD) card, a mini-SD, a micro-SD, an SDHC, and a universal flash storage (UFS) device.

[0051] The controller 130 of the memory system 110 may control the memory module 150 in response to commands from the host device 102. The controller 130 may execute read commands to provide the data from the memory module 150 to the host device 102. The controller 130 may execute write commands to store data provided from the host device 102 into the memory module 150. The controller 130 may execute other commands to manage data in the memory module 150, such as program and erase commands. The controller 130 may also execute other commands to manage control of the memory system 110, such as setting configuration registers of the memory system 110. By executing commands in accordance with the configuration specified in the configuration registers, the controller 130 may control operations of the memory module 150, such as read, write, program, and erase operations.

[0052] The controller 130 may include several components configured for performing the received commands. For example, the controller 130 may include a host interface (I / F) unit 132, a processor 134, an error correction code (ECC) unit 138, a power management unit (PMU) 140, a NAND flash controller (NFC) 142, and / or a memory 144. The power management unit (PMU) 140 may provide and manage power for components within the controller 130 and / or the memory module 150.

[0053] The host interface unit 132 may process commands and data provided from the host device 102, and may communicate with the host device 102, through at least one of various interface protocols such as universal serial bus (USB) , multimedia card (MMC) , peripheral component interconnect express (PCI-e) , serial attached SCSI (SAS) , serial advanced technology attachment (SATA) , parallel advanced technology attachment (PATA) , small computer system interface (SCSI) , enhanced small disk interface (ESDI) , and integrated drive electronics (IDE) . For example, the host interface 132 may be a parallel interface  such as an MMC interface, or a serial interface such as an ultra-high speed class 1 (UHS-I)  / UHS class 2 (UHS-II) or a universal flash storage (UFS) interface.

[0054] The ECC unit 138 may detect and correct errors in the data read from the memory module 150 during the read operation. The ECC unit 138 may not correct error bits when the number of the error bits is greater than a threshold number of correctable error bits, which may result in the ECC unit 138 outputting an error correction fail signal indicating failure in correcting the error bits. In some aspects, no ECC unit 138 may be provided or the ECC unit 138 may be configurable to be active for some or all of the memory module 150. The ECC unit 138 may perform an error correction operation using a coded modulation such as a low-density parity check (LDPC) code, a Bose-Chaudhuri-Hocquenghem (BCH) code, a turbo code, a Reed-Solomon (RS) code, a convolution code, a recursive systematic code (RSC) , a trellis-coded modulation (TCM) , or a Block coded modulation (BCM) .

[0055] The NFC 142 provides an interface between the controller 130 and the memory module 150 to allow the controller 130 to control the memory module 150 in response to a commands received from the host device 102. The NFC 142 may generate control signals for the memory module 150, such as signals for rowlines and bitlines, and process data under the control of the processor 134. Although NFC 142 is described as a NAND flash controller, other controllers may perform similar function for other memory types used as memory module 150.

[0056] The memory 144 may serve as a working memory of the memory system 110 and the controller 130. The memory 144 may store data for driving the memory system 110 and the controller 130. When the controller 130 controls an operation of the memory module 150 such as, for example, a read, write, program or erase operation, the memory 144 may store data which are used by the controller 130 and the memory module 150 for the operation. The memory 144 may be implemented with a volatile memory such as, for example, a static random access memory (SRAM) or a dynamic random access memory (DRAM) . In some aspects, the memory 144 may store address mappings, a program memory, a data memory, a write buffer, a read buffer, a map buffer, and the like.

[0057] The processor 134 may control the general operations of the memory system 110, and a write operation or a read operation for the memory module 150, in response to a write request or a read request received from the host device 102, respectively. For example, the processor 134 may execute firmware, which may be referred to as a flash translation layer (FTL) , to control the general operations of the memory system 110. The processor 134 may be implemented, for example, with a microprocessor or a central processing unit (CPU) , or an application-specific integrated circuit (ASIC) .

[0058] FIG. 2 is a block diagram illustrating an example electronic device including the memory system 100 according to one or more aspects of the disclosure. The electronic device 200 may include a user interface 210, a memory 220, an application processor 230, a network adaptor 240, and a storage system 250 (which may be one embodiment of the memory system 100 of FIG. 1) . The application processor 230 may be coupled to the other components through a bus, such as a peripheral component interface (PCI) bus, including a PCI express (PCIe) bus.

[0059] The application processor 230 may execute computer program code, including applications, drivers, and operating systems, to coordinate performing of tasks by components included in the electronic device 200. For example, the application processor 230 may execute a storage driver for accessing the storage system 250. The application processor 230 may be part of a system-on-chip (SoC) that includes one or more other components shown in electronic device 200.

[0060] The memory 220 may operate as a main memory, a working memory, a buffer memory or a cache memory of the electronic device 200. The memory 220 may include a volatile random access memory such as a dynamic random access memory (DRAM) , a synchronous dynamic random access memory (SDRAM) , a double data rate (DDR) SDRAM, a DDR2 SDRAM, a DDR3 SDRAM, a low power double data rate (LPDDR) SDRAM, an LPDDR2 SDRAM, an LPDDR3 SDRAM, an LPDDR4 SDRAM, an LPDDR5 SDRAM, or an LPDDR6 SDRAM, or a nonvolatile random access memory such as a phase change random access memory (PRAM) , a resistive random access memory (ReRAM) , a magnetic random access memory (MRAM) and a ferroelectric random access  memory (FRAM) . In some aspects, the application processor 230 and the memory 220 may be combined using a package-on-package (POP) .

[0061] The network adaptor 240 may communicate with external devices. For example, the network adaptor 240 may support wired communications and / or various wireless communications such as code division multiple access (CDMA) , global system for mobile communication (GSM) , wideband CDMA (WCDMA) , CDMA-2000, time division multiple access (TDMA) , long term evolution (LTE) , worldwide interoperability for microwave access (WiMAX) , wireless local area network (WLAN) , ultra-wideband (UWB) , Bluetooth, wireless display (Wi-Di) , and so on, and may thereby communicate with wired and / or wireless electronic appliances, for example, a mobile electronic appliance.

[0062] The storage system 250 may store data, for example, data received from the application processor 230, and transmit data stored therein, to the application processor 230. The storage system 250 may be a non-volatile semiconductor memory device, such as a phase-change RAM (PRAM) , a magnetic RAM (MRAM) , a resistive RAM (ReRAM) , a NAND flash memory, a NOR flash memory, or a 3-dimensional (3-D) NAND flash memory. The storage system 250 may be a removable storage medium, such as a memory card or an external drive. For example, the storage system 250 may correspond to the memory system 110 described above with reference to FIG. 1 and may be a SSD, eMMC, UFS, or other flash memory system.

[0063] The user interface 210 provide one or more graphical user interfaces (GUIs) for inputting data or commands to the application processor 230 or for outputting data to an external device. For example, the user interface 210 may include user input interfaces, such as a touch screen, a camera, a microphone, a gyroscope sensor, or a vibration sensor, and user output interfaces, such as a liquid crystal display (LCD) , an organic light emitting diode (OLED) display device, an active matrix OLED (AMOLED) display device, a light emitting diode (LED) , a speaker, or a haptic motor.

[0064] FIG. 3 is a block diagram illustrating components for facilitating access to a flash memory system from a host device according to some embodiments of the disclosure. The host  device 102 accesses the memory system 110 through a first interface 310. The first interface may, for example, be a memory interface such as a physical interface (PHY) connecting the host device 102 to the memory system 110. The host device 102 may include physical layer access block 312, which is configured to generate signals for output to the memory interface 310 and process signals received through the memory interface 310. The memory system 110 includes a similarly-configured physical layer access block 322 for communicating on the memory interface 310. One example physical layer specification for communicating on the memory interface 310 is the MIPI M-PHYTM physical layer specification.

[0065] The host device 102 also includes a data link layer block 314 configured to format frames of data for transmission on the memory interface 310. The frames may be provided to the physical layer access block 312 for transmission. The data link layer block 314 may receive frames from the physical layer access block 312 and decode frames of data received on the memory interface 310. The memory system 110 includes a similarly-configured data link layer block 324 for processing frames transmitted on or received on the memory interface 310 by the physical layer access block 322. One example data link protocol for communicating on a MIPI M-PHYTM physical link is the MIPI UNIPROTM specification.

[0066] The memory system 110 includes N logical units 350a-n comprising logical memory blocks for storing information including user data (e.g., user documents, application data) and configuration data (e.g., information regarding operation of the memory system 110) . The logical units 350a-n may map to portions of the physical memory blocks 152, 154, and 156. Some of the logical units 350a-n or portions of the logical units 350a-n may be configured with write protection, with boot capability, as a specific memory type (e.g., default, system code, non-persistent, enhanced) , with priority access, or with replay protection as a replay protected memory block (RPMB) . The physical layer access block 322 and the data link layer block 324 perform operations of a memory controller for the memory system 110 for storing and retrieving data in logical units 350a-n.

[0067] The memory system 110 also includes configuration structures 352. The configuration structures 352 may include information such as configuration descriptors for boot enable  (bBootEnable) , initial power mode (bInitPowerMode) , RPMB active (bRPMBRegionEnable) , and / or RPMB region sizes (bRPMBRegion1Size, bRPMBRegion2Size, bRPMBRegion3Size) . Such configuration structures and / or parameters may, for example, be configuration structures and / or parameters identified by the UFS standard. [ [Insert additional description regarding and configuration parameters on the memory system are involved in or added for supporting the invention. ] ]

[0068] The host device 102 may be configured to execute one or more applications 334, such as user applications executed by an operating system under the control of a user to receive user input and provide information stored in the memory system 110 to the user. The host device 102 may include several components for interfacing the application 334 to the memory system 110 through the memory interface 310. For example, a SCSI driver 332 and a UFS driver 330 may interface the application 334 to a host memory controller that includes the data link layer block 314 and the physical layer access block 312. The SCSI driver 332 may execute at an application layer for handling transactions requested by the application 334 with the memory system 110. The UFS driver 330 may execute at a transport layer and manage operation of the data link layer block 314, such as to operate the memory interface 310 at one of a plurality of modes of operations. The modes of operations may include two or more gear settings, such as one or more PWM-GEAR settings and four or more HS-GEAR settings specifying one bitrate from 182 MBps, 364 MBps, 728 MBps, and 1457 MBps.

[0069] The memory interface 310 may include one or more lines including a reset RST line, a reference clock REF_CLK line, a data-in DIN line (for data transmissions from the host device 102 to the memory system 110) , and a data-out DOUT line (for data transmissions from the memory system 110 to the host device 102) . The DIN and DOUT lines may be two separate conductors, or the DIN and DOUT lines may include multiple conductors. In some embodiments, the DIN and DOUT lines may be asymmetric with the DIN line including N conductors and the DOUT line including M conductors, with N > M or M > N.

[0070] The UFS driver 330 may generate and decode packets to carry out transactions requested by the application 334. The packets are transmitted over the memory interface 310. The packets may be formatted as UFS Protocol Information Units (UPIUs) . In a transaction with the memory system 110, the host device 102 is an initiator and the memory system 110 is a target. The UFS driver 330, based on the type of transaction, may form one of several types of UPIUs for handling SCSI commands, data operations, task management operations, and / or query operations. Each transaction may include one command UPIU, zero or more DATA IN or DATA OUT UPIUs, and a response UPIU. Each UPIU may include a header followed by optional fields depending on the type of UPIU.

[0071] One example transaction is a read operation. A read transaction may include the initiator (e.g., host device 102) transmitting a command UPIU for causing the target (e.g., memory system 110) to perform a read operation requested by the application 334. The target provides one or more DATA IN UPIUs in response to the command UPIU, in which the DATA IN UPIUs include the requested data. The read transaction is completed by the target transmitting a Response UPIU.

[0072] Another example transaction is a write operation. A write operation may include the initiator (e.g., host device 102) transmitting a command UPIU for causing the target (e.g., memory system 110) to perform a write operation requested by the application 334. The target provides a Ready to Transfer UPIU signaling the initiator to begin transfer of write data. The initiator then transmits one or more DATA OUT UPIUs, which are followed by a Ready to Transfer UPIU signaling the initiator to continue transfer of the write data. The sequence of DATA OUT UPIUs and Ready to Transfer UPIU continues until all write data is provided to the target, after which the target provides a Response UPIU to the initiator.

[0073] A further example transaction is a query operation. A query operation may include the initiator (e.g., host device 102) requesting information about the target (e.g., memory system 110) . The initiator may transmit a Query Request UPIU to request information such as configuration, enumeration, device descriptor, flags, and / or attributes of the target. Example query operations includes read descriptor, write descriptor, read attribute, write attribute, read flag, set flag, clear flag, and / or toggle flag. Example descriptors include  device, configuration, unit, interconnect, string, geometry, power, and / or device health. Example flags include fDeviceInit, fPermanenetWPEn, fPowerOnWPEn, fBackgroundOpsEn, fDeviceLifeSpanModeEn, fPurgeEnable, fRefreshEnable, fPhyResourceRemoval, fBusyRTC, and / or fPermanentlyDisableFwUpdate. Example attributes include bBootLunEn, bCurrentPowerMode, bActiveICCLevel, bOutOfORderDataEn, bBackgroundOpStatus, bPurgeStatus, bMaxDataInSize, bMaxDataOutSize, dDynCapNeeded, bRefClkFreq. Such flags may, for example, be flags identified by the UFS standard.

[0074] Figure 4 is a block diagram of an exemplary memory system 400 that includes a programmable FID-to-SID unit and related architecture. As seen, the memory system 400 implements access control for virtual functions in Universal Flash Storage (UFS) with I / O virtualization (UFS-IOV) and includes a Host 410, which encompasses a UFS Host Controller 402 and a UFS Device 404. The architecture of memory system 400 obviates limitations associated with known UFS Host Controllers, which typically include a single hard-wired Stream ID (SID) . That is, unlike traditional UFS Host Controllers with a single hard-wired SID, the UFS Host Controller 402 in memory system 400 implements a programmable approach to Stream ID assignment.

[0075] The UFS Host Controller 402 comprises a physical UFS Host Controller Interface (UFSHCI) function 406 and multiple virtual UFSHCI functions 408a, 408b, and 408n. The virtual UFSHCI functions may correspond to different applications or subsystems requiring access to the UFS Device 404. In a traditional system, the foregoing functions would share a single SID-making it difficult to isolate their respective data streams.

[0076] UFS Host Controller 402 includes a Programmable Function ID (FID) to Stream ID (SID) Mapping Unit 414 (PFTSMU) . The PFTSMU 414 is configured to assign unique Stream IDs to each of the virtual UFSHCI functions 408a, 408b, and 408n, as well as to the physical UFSHCI function 406. Again, assignment of unique Stream IDs to both physical and virtual functions enables maintaining distinct data streams and effective access control.

[0077] According to certain aspects, the PFTSMU 414 includes a set of registers 416a –416n that are accessible only within the address space of the physical UFSHCI function 406.  Registers 416 store mappings between Function IDs and Stream IDs. The PFTSMU 414 receives Function IDs associated with data transfer requests from the virtual UFSHCI functions and maps them to assigned Stream IDs based on the programmable mappings stored in the registers 416.

[0078] A Host Operating System 418 is configured to control the PFTSMU 414. The Host OS 418 can configure the mappings in the PFTSMU 414 through a secure interface 432, ensuring that only the trusted Host OS can modify these critical security settings. This secure interface 432 is restricted to the Host OS 418, preventing any unauthorized access or modifications to the Stream ID assignments. Also, the secure interface 432 can be internal to the Host 410, connecting the Host OS 418 to the PFTSMU 414 within the UFS Host Controller 402.

[0079] The Host 410 also includes multiple Software Images (SI) , labeled as SI 1, SI 2, and SIn. SI1 corresponds to the Host OS 418, while SI2 and SIn represent Guest Operating Systems. The Guest OSs operate in virtualized environments-each potentially associated with one or more virtual UFSHCI functions. The Host OS 418, as the primary and privileged operating system, maintains control over the PFTSMU 414 and system security while Guest OSs are restricted in their access to critical system resources.

[0080] Within the Host 410, a System Memory Management Unit or Input / Output Memory Management Unit (SMMU / IOMMU) 436 is implemented. The SMMU / IOMMU 436 is responsible for managing memory access and translations between the virtual addresses used by the UFS Host Controller 402 (including its virtual functions) and the physical addresses of the system memory. It works in conjunction with the Stream IDs assigned by the PFTSMU 414 to enforce memory access restrictions, ensuring that each virtual function can only access its designated memory areas. As such, this component plays a role in maintaining the isolation between different Software Images and their associated virtual UFSHCI functions.

[0081] Notably, the Host OS 418 is capable of dynamically adjusting the Stream ID assignments in the PFTSMU 414. The dynamic adjustment can be made in response to changes in  system configuration or evolving security requirements to provide adaptability to the access control mechanism.

[0082] The UFS Device 404 includes a controller 420 and a memory array 422. The controller 420 is configured to receive data transfer requests from the UFS Host Controller 402. These requests are processed independently of the Stream IDs assigned by the PFTSMU 414, as the Stream IDs are not transmitted to or used by the UFS Device 404.

[0083] The memory array 422 may be partitioned into multiple sections 424, 426, and 428. These partitions are based on the UFS Device’s internal organization and are not directly associated with Stream IDs. The partitioning allows for efficient data management within the UFS Device 404.

[0084] The memory system 400 also includes a System Memory Management Unit or Input / Output Memory Management Unit (SMMU / IOMMU) 436. The SMMU / IOMMU 436 uses the unique Stream IDs assigned by the PFTSMU 414 to enforce memory access restrictions for both the physical UFSHCI function 406 and each of the virtual UFSHCI functions 408a, 408b, 408n. In the illustrated embodiment, this access control is implemented between the UFS Host Controller 402 and the system’s main memory (not shown) .

[0085] The SMMU / IOMMU 436 can provide memory protection by handling system-level memory translations and access controls in the context of data transfers between the UFS Host Controller 402 and the system’s main memory. This functionality can extend beyond UFS-specific memory management to encompass broader system-level protections. Also, it can operate without requiring involvement of the UFS Device 404.

[0086] In operation, when a virtual UFSHCI function (e.g., 408b) initiates a data transfer request, its associated Function ID is sent to the PFTSMU 414. The PFTSMU 414 maps this Function ID to a unique Stream ID based on its programmed mappings. This Stream ID is then used by the SMMU / IOMMU 436 to manage access to the system’s main memory. Concurrently, the data transfer request is sent through the communication interface 430 to the UFS Device 404 without the Stream ID information. The controller 420 in the UFS  Device 404 processes this request based on its internal logic and does not require awareness of the Stream ID used for memory access control on the host side.

[0087] The architecture of memory system 400 enables fine-grained access control and isolation between different virtual functions, thereby enhancing security in UFS-IOV scenarios. It allows for dynamic assignment and management of Stream IDs for controlling access to the system’s main memory.

[0088] The combination of the PFTSMU 414, secure interface 432, dynamic adjustment capabilities of the Host OS 418, and the SMMU / IOMMU 436 create a robust access control system for UFS-IOV environments. In doing so, it protects data flows between the UFS Host Controller and the system’s main memory.

[0089] Turning back to the Programmable Function ID (FID) to Stream ID (SID) Mapping Unit 414 (PFTSMU) in Figure 4, it includes a set of registers that define the FID-to-SID mappings. According to an aspect, each mapping register can be 32 bits wide and corresponds to a specific Function ID (n) , where n ranges from 0 to 31. This implementation, where FID-to-SID maps n, n = 0 . . . 31, allows for up to 32 different mappings to support a wide range of virtual functions. The structure of each mapping register is shown in Table 1

[0090] Table 1

[0091] The value stored in the bits determines the Stream ID assigned to each function. According to an implementation, a value of 0h indicates that the function should use the Physical UFSHCI's SID without any offset, a value of 1h assigns a Stream ID that is the Physical  UFSHCI’s SID plus 1, and a value of 2h assigns a Stream ID that is the Physical UFSHCI's SID plus 2. The mapping register could contain any unique number, allowing for a wide range of possible Stream ID assignments. For example, if the Physical UFSHCI's SID is 100, and the mapping register for Function ID1 contains the value 2h, then Function ID1 would be assigned the Stream ID 102. Alternatively, the mapping register could contain a value like 10h, which would assign a Stream ID that is the Physical UFSHCI's SID plus 16, or any other unique value within the register's range, providing extensive flexibility in Stream ID assignment.

[0092] The mapping registers are located within the address space of the Physical UFSHCI function 406. This function is a security measure, i.e., the registers can only be configured through this specific address space, which is under the control of the Host Operating System 418.

[0093] The foregoing architectural design keeps the SID assignment under the control of the Host OS. It prevents Guest Operating Systems or other non-privileged entities from modifying the SID assignments, which could potentially be used to bypass access controls to the system’s main memory. For example, a Guest OS attempting to change the SID of its associated Virtual UFSHCI to gain unauthorized access to memory sections assigned to other functions would be prevented from doing so. This control mechanism helps in maintaining the isolation between different virtual functions’ access to the host system’s memory rather than controlling access to the UFS Device itself.

[0094] The Host OS 418 interacts with the mapping registers through the secure interface 432. This interface implements security measures, such as requiring privileged access levels or authentication, to ensure that only the Host OS can modify these settings. These security measures help maintain the integrity of the memory access control system within the host environment.

[0095] When a data transfer request is initiated by a virtual UFSHCI function (e.g., 408a, 408b, or 408n) , the PFTSMU 414 consults the mapping registers. It takes the Function ID associated with the request, looks up the corresponding mapping register, and applies the stored offset to the Physical UFSHCI’s base SID. The resulting Stream ID is then used for  memory access control within the host system. This dynamic mapping allows the system to support various configurations for memory access. Certain functions can be assigned SIDs with larger offsets to create separation from other functions in terms of their memory access privileges. Related functions can be grouped by assigning them consecutive SIDs, potentially allowing for more efficient memory management. The Host OS can implement a rotation scheme, periodically changing the SID assignments to enhance security of memory access patterns. Notably, while these SIDs control access to the host system’s memory, they do not directly affect the operation of or communication with the UFS Device.

[0096] Figure 5 shows a flowchart illustrating an example process 500 performable by a Universal Flash Storage (UFS) host controller that implements access control for virtual functions with I / O virtualization. The operations of the process in Figure 5 may be implemented by components of a UFS host controller as described herein, such as the UFS Host Controller 402 described with reference to Figure 4.

[0097] At step 502, the UFS host controller receives a function ID associated with a virtual UFS Host Controller Interface (UFSHCI) function. The function ID typically corresponds to one of the virtual UFSHCI functions (e.g., 408a, 408b, 408n) that require access to the UFS Device. Also, the function ID is received through a set of registers accessible within an address space of a physical UFSHCI function to enhance security by limiting the potential for unauthorized modifications.

[0098] At step 504, the UFS host controller maps the received function ID to an assigned stream ID based on a programmable mapping. The programmable nature of the mapping enables adaptability to various system configurations and security requirements. The programmable mapping associates each of a plurality of virtual UFSHCI functions with a unique assigned stream ID, ensuring clear differentiation between virtual functions. The unique assigned stream IDs may be based on offsets from a stream ID of a physical UFSHCI function, providing a structured and efficient method for assigning stream IDs while maintaining their uniqueness.

[0099] At step 506, the UFS host controller outputs the assigned stream ID associated with the virtual UFSHCI function. This is done to isolate data streams, i.e., this output enables the system to maintain distinct data streams and implement effective access control. The assigned stream ID is used to differentiate data streams from different virtual UFSHCI functions, implementing access control between security domains. In certain configurations, the assigned stream ID also serves as a device ID for enabling Message Signaled Interrupts (MSIs) with a Generic Interrupt Controller (GIC) Interrupt Translation Service (ITS) .

[0100] In one implementation, the UFS host controller may receive configuration data for the programmable mapping from a host operating system through a dedicated interface. This step enables dynamic updates to the mapping based on changing system requirements or security needs. The UFS host controller is configured to receive configuration commands from the host operating system while denying attempts to modify the programmable mapping from non-host operating system sources, ensuring that only authorized changes are made to the mapping.

[0101] Further, the UFS host controller can enable dynamic reconfiguration of the programmable mapping in response to changes in system memory management unit (SMMU) driver frameworks. This step allows for adaptation in evolving system environments where SMMU configurations may change. Additionally, the UFS host controller allows for allocation of stream IDs by either a UFS host driver or an SMMU driver, providing flexibility in system configuration.

[0102] In another implementation, the UFS host controller maintains a set of readable registers within the UFSHCI address space, allowing for inspection of the current mapping configuration for system monitoring and debugging purposes.

[0103] In automotive applications, the UFS host controller can assign unique stream IDs to each of a plurality of virtual UFSHCI functions associated with automotive subsystems. This step enables isolated data streams for each automotive subsystem, which is helpful in contexts where different subsystems (e.g., infotainment, navigation, safety systems) need to operate independently without interfering with each other.

[0104] Throughout the execution of method 500, the set of registers used by the programmable FID to SID mapping unit is accessible and configurable only through an interface that restricts access to the host operating system. This arrangement ensures that only authorized entities can modify the mapping, providing an additional layer of security.

[0105] By implementing these steps, the UFS host controller provides a comprehensive and flexible approach to managing stream IDs for virtual UFSHCI functions. It enables secure and efficient operation of UFS systems with I / O virtualization and is adaptable to various applications from general computing to specialized automotive use cases.

[0106] FIG. 6 illustrates a block diagram of an example Universal Flash Storage (UFS) host controller 600 that implements access control for virtual functions with I / O virtualization. UFS host controller 600 may represent aspects of the UFS Host Controller 402 described with reference to Figure 4 and is designed to perform method 500. It operates within a host system environment, typically including a main processor running a host operating system and other system components. UFS host controller 600 addresses the challenges of managing access control in modern UFS implementations by providing a framework for security and efficiency.

[0107] UFS host controller 600 comprises a UFS interface 602 configured to communicate with a UFS Device, such as UFS Device 404 described with reference to Figure 4. This interface handles the data transfer requests and responses between the host system and the UFS device, facilitating the core functionality of the UFS system.

[0108] A programmable Function ID (FID) to Stream ID (SID) mapping unit 604 forms another component of UFS host controller 600. Unit 604, which may be an example of PFTSMU 414 described with reference to Figure 4, is configured to receive function IDs, map them to stream IDs, and output the assigned stream IDs for isolating data streams. The mapping process is fundamental to the access control mechanism implemented by the UFS host controller.

[0109] UFS host controller 600 incorporates a set of registers 606 within the address space of a physical UFSHCI function. These registers store the programmable mapping and are  accessible only through a secure interface restricted to the host operating system. This component corresponds to the registers 416 described in Figure 4. The restricted access to registers 606 ensures that only authorized entities can modify the critical mapping information, contributing to the system’s security.

[0110] An access control manager 608 is included in UFS host controller 600. It supports access control for virtual UFSHCI functions in accordance with examples as disclosed herein. Its features include managing the programmable mapping, handling configuration updates, and enforcing access restrictions based on assigned stream IDs. Manager 608 acts as an authority for access control decisions, ensuring that operations within the UFS system adhere to defined security policies and access rules.

[0111] UFS host controller 600 includes circuitry for receiving a function ID associated with a virtual UFSHCI function (circuitry 610) . This circuitry handles the initial reception of function IDs from the virtual UFSHCI functions (e.g., 408a, 408b, 408n in Figure 4) . UFS host controller 600 also includes, stored in a computer-readable medium, code for receiving a function ID associated with a virtual UFSHCI function (code 612) . The combination of dedicated circuitry and software implementation provides flexibility in handling function ID reception.

[0112] UFS host controller 600 includes circuitry for mapping the received function ID to an assigned stream ID based on a programmable mapping (circuitry 614) . This circuitry works in conjunction with the programmable FID to SID mapping unit 604 to perform the mapping process. UFS host controller 600 also includes, stored in a computer-readable medium, code for mapping the received function ID to an assigned stream ID based on a programmable mapping (code 616) .

[0113] UFS host controller 600 includes circuitry for outputting the assigned stream ID for use in isolating data streams associated with the virtual UFSHCI function (circuitry 618) . This circuitry handles the transmission of the assigned stream IDs to other components in the system that require this information for access control. UFS host controller 600 also includes, stored in a computer-readable medium, code for outputting the assigned stream ID for use in isolating data streams associated with the virtual UFSHCI function (code 620) .  The presence of both hardware and software components for these functions provides redundancy and flexibility in implementing the access control mechanism.

[0114] UFS host controller 600 operates under the control of a host operating system, which manages the programmable FID to SID mapping unit and oversees the assignment and modification of stream IDs. This arrangement ensures that a trusted entity maintains control over access control mechanisms within the UFS system.

[0115] Various components of UFS host controller 600 provide means for performing method 500 described with respect to Figure 5. For example, means for receiving a function ID may include the UFS interface 602 and / or circuitry 610 and / or code 612. Means for mapping the function ID to a stream ID may include the programmable FID to SID mapping unit 604 and / or circuitry 614 and / or code 616. Means for outputting the assigned stream ID may include the UFS interface 602 and / or circuitry 618 and / or code 620. This modular approach to implementing the method allows for flexibility in system design and optimization of performance.

[0116] The components of UFS host controller 600 collectively provide a comprehensive approach to managing access control in UFS implementations with I / O virtualization, enabling secure operation while maintaining flexibility to adapt to evolving system requirements.

[0117] Figure 7 shows a flowchart illustrating an example process 700 performable by or at a Universal Flash Storage (UFS) system that implements access control for virtual functions with I / O virtualization. The operations of the process in Figure 7 may be implemented by components of a UFS system as described herein. For example, the method 700 may be performed by a UFS system comprising a UFS Host Controller Interface (UFSHCI) , such as the system described with reference to Figure 4.

[0118] At step 702, unique stream IDs are assigned to the physical UFSHCI function and each of the one or more virtual UFSHCI functions. The assignment can be performed by a programmable Function ID (FID) to Stream ID (SID) mapping unit in system 700. The unique stream IDs serve as identifiers for differentiating between the physical and virtual  functions within the UFS system. In some implementations, the unique stream IDs assigned in step 702 are used to control access between security domains associated with the physical UFSHCI function and each of the one or more virtual UFSHCI functions. This enhances security of the system by maintaining clear boundaries between different functions.

[0119] Following the assignment of stream IDs, at step 704, the method 700 includes enabling segregation of data streams through the use of the assigned stream IDs. Segregation can be achieved when the programmable Function ID (FID) to Stream ID (SID) mapping unit in system 700 maps each function to its unique SID, and the system’s memory management unit uses the unique SIDs to enforce memory access restrictions. The unique SID assignments enable the system to automatically maintain isolation between different functions’ data streams, as each stream can only access memory regions authorized for its assigned SID. This mapping-based segregation contributes to the security and efficiency of the UFS system by ensuring that each virtual function can only access its designated memory areas. Further, the method 700 may include restricting access to the programmable FID to SID mapping unit to a secure interface accessible only by the host operating system. A secure interface ensures that only the trusted host operating system can configure and modify the stream ID assignments to maintain the integrity of the access control mechanism.

[0120] The method 700 incorporates additional aspects that enhance its functionality and security. Access to the programmable FID to SID mapping unit may be restricted to a secure interface accessible only by the host operating system, maintaining the integrity of stream ID assignments by preventing unauthorized modifications. Additionally, the method 700 may include enforcing memory access restrictions to ensure that the physical UFSHCI function and each of the virtual UFSHCI functions can only access their designated memory areas.

[0121] To further bolster security, the programmable FID to SID mapping unit can be configured to prevent guest operating systems from modifying the assigned stream IDs. Such a  configuration ensures that only the host operating system can make changes to the stream ID assignments, preserving the integrity of the access control mechanism.

[0122] In some implementations, dynamic adjustment of stream ID assignments is another feature of method 700. A host operating system or similar entity may be configured to adjust the assignments in response to changes in system configuration or security requirements. This adaptability allows the UFS system to respond to evolving needs while maintaining performance and security.

[0123] Some implementations of method 700 place the programmable FID to SID mapping unit within a physical UFSHCI function, making it inaccessible to the one or more virtual UFSHCI functions. An extra layer of security is added to the system by physically isolating the mapping unit from potential interference by virtual functions.

[0124] Throughout the execution of method 700, a host operating system can maintain control over the programmable FID to SID mapping unit. Such oversight ensures that a trusted entity manages all stream ID assignments and modifications and preserves integrity and security of the UFS system. The comprehensive approach of method 700 to managing access control in UFS systems with I / O virtualization enables secure operation while maintaining flexibility to adapt to changing system requirements.

[0125] FIG. 8 illustrates a block diagram of an example Universal Flash Storage (UFS) system 800 that implements access control for virtual functions with I / O virtualization. UFS system 800 may represent aspects of the UFS system described with reference to Figure 4 and is designed to perform method 700. It operates within a host system environment, typically including a main processor running a host operating system and other system components. UFS system 800 is designed to address the challenges of managing access control in UFS implementations by providing a robust framework for enhanced security and efficiency.

[0126] UFS system 800 comprises a UFS Host Controller Interface (UFSHCI) 802 configured to manage communications between the host system and UFS devices. UFSHCI 802 includes both physical and virtual functions, which enable efficient resource utilization and isolation.  This architecture allows for flexible allocation of resources while maintaining strict boundaries between different functions, a critical feature in systems requiring high levels of security and performance.

[0127] Another component of UFS system 800 is a programmable Function ID (FID) to Stream ID (SID) mapping unit 804. Unit 804 can assign unique stream IDs to the physical UFSHCI function and each virtual UFSHCI function. It may also segregate data streams associated with each function based on the assigned stream IDs, potentially enhancing system security and efficiency. The mapping unit plays a role in maintaining the isolation between different functions and their associated data streams and contributes to the security posture of the UFS system.

[0128] UFS system 800 incorporates a set of registers 806 within the address space of the physical UFSHCI function. Registers 806 can store the programmable mapping and may be accessible only through a secure interface restricted to the host operating system to prevent unauthorized modifications. The restricted access to the registers 806 ensures that only trusted entities can modify the critical mapping information. This further strengthens the security of the system against potential threats or unauthorized access attempts.

[0129] An access control manager 808 is also included in UFS system 800. It can support access control for virtual UFSHCI functions, with capabilities that may include managing the programmable mapping, handling configuration updates, and enforcing access restrictions based on assigned stream IDs. Manager 808 acts as a central authority for access control decisions to ensure that all operations within the UFS system adhere to defined security policies and access rules.

[0130] UFS system 800 includes circuitry for assigning unique stream IDs to UFSHCI functions (circuitry 810) . This circuitry handles the assignment of stream IDs to both physical and virtual UFSHCI functions. UFS system 800 also includes, stored in a computer-readable medium, code for assigning unique stream IDs to UFSHCI functions (code 812) . The combination of dedicated circuitry and software implementation provides flexibility and performance in managing stream ID assignments.

[0131] UFS system 800 includes circuitry for segregating data streams associated with each function according to the assigned stream IDs (circuitry 814) . This circuitry works in conjunction with the programmable FID to SID mapping unit 804 to perform the segregation process. UFS system 800 also includes, stored in a computer-readable medium, code for segregating data streams associated with each function according to the assigned stream IDs (code 816) .

[0132] UFS system 800 includes circuitry for controlling access to the programmable FID to SID mapping unit (circuitry 818) . This circuitry manages access to the mapping unit, potentially ensuring that only authorized entities can modify the stream ID assignments. UFS system 800 also includes, stored in a computer-readable medium, code for controlling access to the programmable FID to SID mapping unit (code 820) . The presence of both hardware and software components for these functions provides redundancy and flexibility in enforcing security policies.

[0133] A memory management unit 822 is also included in UFS system 800. It can use the unique stream IDs to enforce memory access restrictions for both physical and virtual UFSHCI functions, and may work in tandem with other components to maintain boundaries between different functions and their associated memory areas. Unit 822 plays a role in preventing unauthorized access to memory regions, further enhancing security of the system.

[0134] UFS system 800 operates under the control of a host operating system, which manages the programmable FID to SID mapping unit and oversees the assignment and modification of stream IDs. This arrangement ensures that a trusted entity maintains control over access control mechanisms within the UFS system. The host operating system’s role in managing security functions provides an additional layer of protection against potential security breaches or unauthorized modifications to the system’s security settings.

[0135] Various components of UFS system 800 provide means for performing method 700 described with respect to Figure 7. For example, means for assigning unique stream IDs may include the programmable FID to SID mapping unit 804 and / or circuitry 810 and / or code 812. Means for segregating data streams may involve circuitry 814 and / or code 816. Means for controlling access to the mapping unit may utilize circuitry 818 and / or code 820.  This modular approach to implementing the method allows for flexibility in system design and potential optimization of performance.

[0136] The components of UFS system 800 collectively provide a comprehensive approach to managing access control in UFS implementations with I / O virtualization, enabling secure operation while maintaining flexibility to adapt to evolving system requirements.

[0137] Figure 9 shows a flowchart illustrating an example process 900 performable by or at a Universal Flash Storage (UFS) device that implements access control for data transfers. The operations of the process in Figure 9 may be implemented by components of a UFS device as described herein. For example, method 900 may be performed by a UFS device configured to interact with a UFS Host Device Interface (UFSHCI) , such as the system described with reference to Figure 4.

[0138] At step 902, the UFS device receives a stream ID associated with a data transfer request from the UFSHCI. A programmable Function ID (FID) to Stream ID (SID) mapping unit in the UFSHCI may assign this stream ID, serving as a unique identifier for the transfer request. This stream ID corresponds to specific areas of the UFS device’s memory array that the request seeks to access. The memory array is organized into different sections, each associated with one or more authorized stream IDs. In some implementations, the memory array may be partitioned into multiple secure domains, with each domain encompassing one or more sections and associated with specific authorized stream IDs. This partitioning allows for more granular control over data access, as each received stream ID effectively determines which sections of the memory array can be accessed by the incoming data transfer request.

[0139] At step 904, the device validates the received stream ID against a set of authorized stream IDs for accessing specific areas of the UFS device. Validation ensures only permitted access attempts proceed further. The device may maintain a mapping between authorized stream IDs and sections of the memory array to facilitate this validation process. The mapping can be dynamically updated according to instructions received from a host operating system via the UFSHCI, allowing for flexible adjustment of access permissions as system requirements change.

[0140] At step 906, the device executes the data transfer associated with the validated stream ID. By gatekeeping access based on stream ID verification, unauthorized attempts to interact with the UFS device’s memory array are blocked. In some configurations, the device may be set up to reject data transfer requests associated with stream IDs that are not in the set of authorized stream IDs. This serves as an additional security measure and trigger alerts or logging attempts for security auditing purposes.

[0141] At step 908, different sections of the memory array are associated with various authorized stream IDs. This granular access control within the UFS device allows for precise management of data security and isolation between different functional areas or user domains.

[0142] At step 910, the device may optionally maintain a mapping between authorized stream IDs and sections of the memory array. This mapping facilitates efficient management of access permissions within the device, allowing quick reference during validation processes. Step 910 can speed up access control operations, particularly in systems with complex memory organizations or frequently changing access permissions.

[0143] At step 912, the device may implement an additional security measure by rejecting data transfer requests associated with stream IDs absent from the set of authorized stream IDs. This mechanism protects against unauthorized access attempts. Rejected requests may be logged for security auditing purposes, adding a layer of security monitoring to the system.

[0144] At step 914, the device updates the set of authorized stream IDs based on instructions received from a host operating system via the UFSHCI. Dynamic adjustment of access permissions allows adaptability to changing security requirements or system configurations. The UFS device can thus respond to evolving security needs without requiring a system restart or the like.

[0145] At step 916, the memory array may optionally be partitioned into multiple secure domains, each associated with one or more authorized stream IDs. Implementing this type of memory organization, i.e., as executed at step 908, enables isolation between different security contexts within the UFS device. Such partitioning serves multi-tenant  environments or systems requiring strict separation between different types of data or applications. Also, it allows for more sophisticated access control policies and can minimize the potential impact of a security breach across domains.

[0146] Throughout the execution of method 900, the UFS device controller manages access to the memory array based on validated stream IDs. Access control in UFS devices enables secure operation while maintaining flexibility to adapt to evolving system requirements. By implementing the foregoing, UFS devices can provide security measures, granular access control, and dynamic permission management.

[0147] FIG. 10 illustrates a block diagram of an example Universal Flash Storage (UFS) system 1000 that implements access control for data transfers. System 1000 represents both host and UFS device components, as described with reference to Figure 4, and is designed to perform method 900. The system operates within a host environment, typically including a main processor running a host operating system and other system components.

[0148] On the host side, system 1000 comprises a UFS Host Controller Interface (UFSHCI) 1002 configured to manage communications with UFS devices. UFSHCI 1002 includes a programmable Function ID (FID) to Stream ID (SID) mapping unit 1004, which assigns unique stream IDs to data transfer requests.

[0149] On the device side, system 1000 includes a controller 1006 that receives data transfer requests from the UFSHCI 1002. Controller 1006 manages access to the device’s memory array 1008, which is organized into different sections, each potentially associated with specific authorized stream IDs.

[0150] Memory array 1008 may be partitioned into multiple secure domains, with each domain encompassing one or more sections. This partitioning is managed by controller 1006 and is independent of the stream ID assignments made by the host.

[0151] On the host side, system 1000 includes a set of registers 1010 within the address space of the UFSHCI function. Registers 1010 store the programmable mapping between FIDs and SIDs and are accessible through a secure interface restricted to the host operating system to prevent unauthorized modifications.

[0152] An access control manager 1012, implemented on the host side, supports access control for data transfer requests. Its capabilities include managing the programmable mapping, handling configuration updates, and enforcing access restrictions based on assigned stream IDs.

[0153] On the host side, system 1000 includes circuitry for receiving a stream ID associated with a data transfer request from the UFSHCI (circuitry 1014) . This stream ID is assigned by the programmable Function ID (FID) to Stream ID (SID) mapping unit 1004 in the UFSHCI. System 1000 also includes, stored in a computer-readable medium on the host side, code for receiving a stream ID associated with a data transfer request from the UFSHCI (code 1016) .

[0154] Also on the host side, system 1000 includes circuitry for validating the received stream ID against a set of authorized stream IDs for accessing specific areas of the UFS device (circuitry 1018) . Correspondingly, system 1000 includes, stored in a computer-readable medium on the host side, code for validating the received stream ID against a set of authorized stream IDs for accessing specific areas of the UFS device (code 1020) .

[0155] The host side of system 1000 further includes circuitry for executing the data transfer request if the associated stream ID is validated (circuitry 1022) . It also includes, stored in a computer-readable medium, code for executing the data transfer request if the received stream ID is validated (code 1024) .

[0156] A memory management unit 1026, implemented on the host side, uses the assigned stream IDs to enforce memory access restrictions. It works in conjunction with the UFSHCI and mapping unit to maintain security boundaries.

[0157] The host operating system controls the programmable FID to SID mapping unit and oversees the assignment and modification of stream IDs. It ensures trusted control over access mechanisms.

[0158] A dynamic adjustment module 1028, part of the host system, allows the operating system to update the set of authorized stream IDs in response to changes in system configuration or security requirements.

[0159] On the device side, system 1000 may include a rejection unit 1030 that rejects data transfer requests associated with unauthorized access attempts, as determined by the controller 1006.

[0160] The components of system 1000 collectively provide the means for implementing access control in UFS, with the host side managing stream ID assignments and overall security policies, and the device side enforcing access controls based on these assignments.

[0161] Figure 11 shows a flowchart illustrating an example process 1100 performable by a Universal Flash Storage (UFS) system that implements access control for data transfers between its UFS Host Controller Interface (UFSHCI) and UFS device components. The operations of the process in Figure 11 may be implemented by components of a UFS system as described herein, such as the system described with reference to Figure 4.

[0162] At step 1102, the UFS system, through its UFSHCI component which includes a physical UFSHCI function and one or more virtual UFSHCI functions, assigns unique stream IDs to the functions using a programmable Function ID (FID) to Stream ID (SID) mapping unit. The assignment can be controlled by the system’s host operating system to ensure centralized management of stream ID allocation.

[0163] At step 1104, the UFS system transmits a data transfer request from its UFSHCI to its UFS device component via a communication interface. Each request is associated with a unique stream ID assigned by the FID to SID mapping unit in step 1102. This stream ID corresponds to specific sections of the system’s UFS device memory array that the request seeks to access.

[0164] At step 1106, the UFS system, through its UFS device controller, validates the received stream ID against a set of authorized stream IDs for accessing specific areas of the UFS device’s memory array. This validation process ensures that only permitted access attempts proceed further within the system.

[0165] At step 1108, if the stream ID is validated, the UFS system executes the data transfer request, enabling data transfer between the UFSHCI functions and the corresponding  sections of the UFS device memory array associated with the assigned and validated stream IDs. If the stream ID is not validated, the system may deny the data transfer request.

[0166] At step 1110, the UFS system, through its host operating system, may adjust the assignment of stream IDs according to changes in system configuration or security requirements. This dynamic adjustment allows the UFS system to adapt to evolving needs without requiring a restart.

[0167] At step 1112, the UFS system ensures that the programmable FID to SID mapping unit is accessible only via a secure interface restricted to the host operating system. This restricted access within the system ensures that only the trusted host operating system can modify the critical mapping information.

[0168] At step 1114, the UFS system, using a memory management unit, employs the unique stream IDs to enforce memory access restrictions for the physical UFSHCI function and each of the virtual UFSHCI functions. This step provides an additional layer of security within the system by ensuring that each function can only access its designated memory areas.

[0169] Throughout the execution of method 1100, the UFS system’s communication interface between the UFSHCI and the UFS device facilitates the transmission of data transfer requests and enables data transfer between the UFSHCI functions and sections of the UFS device memory array associated with the assigned and validated stream IDs.

[0170] This approach to access control in the UFS system enables secure operation while maintaining flexibility to adapt to evolving requirements. By implementing these steps, the UFS system provides security measures, granular access control, and dynamic permission management, addressing the challenges of modern storage systems in environments with both physical and virtual UFSHCI functions.

[0171] FIG. 12 illustrates a block diagram of an example Universal Flash Storage (UFS) system 1200 that implements access control for data transfers between its UFS Host Controller Interface (UFSHCI) and UFS device components. UFS system 1200 may represent aspects of the UFS system described with reference to Figure 4 and is designed to perform method  1100. It operates within a host system environment, typically including a main processor running a host operating system and other system components.

[0172] UFS system 1200 comprises a UFSHCI 1202 configured to manage communications between the host system and UFS devices. UFSHCI 1202 includes a physical UFSHCI function 1204 and one or more virtual UFSHCI functions 1206. This architecture allows for efficient resource utilization and isolation between different functions.

[0173] Another component of UFS system 1200 is a programmable Function ID (FID) to Stream ID (SID) mapping unit 1208. Unit 1208 assigns unique stream IDs to the physical UFSHCI function 1204 and each virtual UFSHCI function 1206. It also segregates data streams associated with each function based on the assigned stream IDs, enhancing system security and efficiency.

[0174] UFS system 1200 also includes a host operating system 1210 configured to control the programmable FID to SID mapping unit 1208. This arrangement ensures that a trusted entity maintains control over access control mechanisms within the UFS system. The host operating system 1210 can adjust the assignment of stream IDs according to changes in system configuration or security requirements, providing adaptability to evolving needs.

[0175] A UFS device 1212 is included in the system 1200, comprising a controller 1214 and a memory array 1216. Controller 1214 is configured to validate received stream IDs and execute data transfer requests based on the validation. Memory array 1216 is accessible according to the validated stream IDs, with different sections associated with various authorized stream IDs.

[0176] UFS system 1200 includes a communication interface 1218 between the UFSHCI 1202 and the UFS device 1212. This interface is configured to transmit data transfer requests from the UFSHCI to the UFS device, with each request associated with a unique stream ID assigned by the FID to SID mapping unit 1208. It also enables data transfer between the UFSHCI functions and sections of the UFS device memory array associated with the assigned and validated stream IDs.

[0177] The UFS system 1200 incorporates hardware and software components designed to manage and secure data transfers. At its core, the system 1200 includes circuitry (1220) for assigning unique stream IDs to UFSHCI functions, which is an central process in differentiating between various data streams. This hardware implementation is complemented by corresponding code (1222) stored in a computer-readable medium, a for assigning unique stream IDs to UFSHCI functions.

[0178] In conjunction with the stream ID assignment components, UFS system 1200 includes circuitry (1224) and associated code (1226) for validating received stream IDs against a set of authorized IDs. Validation serves as a checkpoint that ensures only approved data transfers can access specific areas of the UFS device’s memory array. The hardware-software combination allows for rapid validation while maintaining the ability to update authorization criteria dynamically.

[0179] The execution of data transfer requests based on validated stream IDs is handled by circuitry (1228) and corresponding code (1230) . This component acts as the gatekeeper, only allowing data transfers that have passed the validation process to proceed. By implementing this function in both hardware and software, the system achieves a balance between the high-speed processing capabilities of dedicated circuitry and the flexibility of software-based decision making. This dual approach enables the system to handle high-volume data transfers efficiently while retaining the ability to adapt its execution criteria as needed.

[0180] A memory management unit 1232 plays a role in enforcing access restrictions based on the unique stream IDs. Unit 1232 works in concert with other system components to maintain strict boundaries between different functions and their associated memory areas. Its operation extends beyond access control-actively participating in the system’s security architecture by ensuring that each function, whether physical or virtual, can only interact with its designated memory spaces. This granular level of control is helpful for preventing unauthorized data access or cross-contamination between different functional domains within the UFS system.

[0181] To further enhance security, UFS system 1200 implements a secure interface 1234 that acts as a gatekeeper for the programmable FID to SID mapping unit (1208) . Interface 1234 is designed to enable stringent access controls by restricting its use exclusively to the host operating system 1210. By channeling all modifications to the critical mapping information through interface 1234 the system 1200 significantly reduces the risk of unauthorized alterations that could compromise the integrity of the access control framework. This architectural decision underscores the system’s ability to maintain a trusted chain of command in managing stream ID assignments and their associated access privileges.

[0182] According to some implmentations, a denial unit 1236 can be integrated within the UFS device controller 1214. Unit 1236 rejects any data transfer requests that are associated with unauthorized stream IDs for specific sections of the memory array. By implementing this check at the device controller level, the system 1200 adds a safeguard against potential security breaches that might have bypassed earlier validation stages. The denial unit 1236 works in tandem with other security measures to form a multi-layered defense strategy that enhances the integrity and confidentiality of data.

[0183] The components of UFS system 1200 collectively provide the means for performing method 1100. For example, the programmable Function ID to Stream ID mapping unit 1208, along with circuitry 1220 and code 1222, serve as the means for assigning unique stream IDs to UFSHCI functions. The UFS device controller 1214, supported by circuitry 1224 and code 1226, serves as a means for validating received stream IDs. The same UFS device controller 1214, utilizing circuitry 1228 and code 1230, serves as a means for executing data transfer requests based on validated stream IDs. The memory management unit 1232 serves as a means for enforcing memory access restrictions, ensuring each function interacts only with its designated memory spaces. The secure interface 1234 serves as a means for maintaining security by acting as a gatekeeper for the mapping unit 1208, restricting access to the host operating system 1210. The host operating system 1210 itself serves as a means for adjusting stream ID assignments. Collectively, these components provide the means for transmitting data transfer requests from the UFSHCI to the UFS device, with each request associated with a unique stream ID, and enabling data  transfer between the UFSHCI functions and sections of the UFS device memory array associated with the assigned and validated stream IDs. This comprehensive approach addresses the challenges of modern storage systems, providing a robust framework for enhanced security and efficiency in UFS implementations with both physical and virtual UFSHCI functions.

[0184] While aspects and implementations are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, packaging arrangements. For example, implementations or uses may come about via integrated chip implementations or other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail devices or purchasing devices, medical devices, AI-enabled devices, etc. ) . While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range from chip-level or modular components to non-modular, non-chip-level implementations and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more described aspects. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for implementation and practice of claimed and described aspects. It is intended that innovations described herein may be practiced in a wide variety of implementations, including both large devices or small devices, chip-level components, multi-component systems (e.g., radio frequency (RF) -chain, communication interface, processor) , distributed arrangements, end-user devices, etc. of varying sizes, shapes, and constitution.

[0185] In one or more aspects, techniques for supporting data storage and / or data transmission 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 or devices described elsewhere herein. The exemplary clauses that illustrate as much follow:

[0186] Clause 1: A method for managing access control in a Universal Flash Storage (UFS) host controller, the method comprising: receiving a function ID associated with a virtual UFS Host Controller Interface (UFSHCI) function; mapping the received function ID to an assigned stream ID based on a programmable mapping; and outputting the assigned stream ID for use in isolating data streams associated with the virtual UFSHCI function.

[0187] Clause 2: The method of Clause 1, wherein the programmable mapping is stored in a set of registers accessible only within an address space of a physical UFSHCI function.

[0188] Clause 3: The method of Clause 2, further comprising: accessing and configuring the set of registers through an interface that restricts access to the host operating system.

[0189] Clause 4: The method of Clause 1, wherein the programmable mapping associates each of a plurality of virtual UFSHCI functions with a unique assigned stream ID.

[0190] Clause 5: The method of Clause 4, wherein the unique assigned stream IDs for the plurality of virtual UFSHCI functions are based on a unique stream ID of a physical UFSHCI function.

[0191] Clause 6: The method of Clause 1, further comprising: receiving configuration data for the programmable mapping from a host operating system through an interface.

[0192] Clause 7: The method of Clause 1, further comprising: using the assigned stream ID to differentiate data streams from different virtual UFSHCI functions for implementing access control between security domains.

[0193] Clause 8: The method of Clause 1, further comprising: using the assigned stream ID as a device ID for enabling Message Signaled Interrupts (MSIs) with a Generic Interrupt Controller (GIC) Interrupt Translation Service (ITS) .

[0194] Clause 9: The method of Clause 1, further comprising: receiving configuration commands from a host operating system; and denying attempts to modify the programmable mapping from non-host operating system sources.

[0195] Clause 10: The method of Clause 1, further comprising: enabling dynamic reconfiguration of the programmable mapping in response to changes in system memory management unit (SMMU) driver frameworks; and enabling allocation of stream IDs by at least one of a UFS host driver or an SMMU driver.

[0196] Clause 11: The method of Clause 1, further comprising: including a set of readable registers within a UFSHCI address space of the UFS host controller.

[0197] Clause 12: The method of Clause 1, further comprising: assigning unique stream IDs to each of a plurality of virtual UFSHCI functions associated with an automotive subsystem; and enabling isolated data streams for each automotive subsystem using the unique stream IDs.

[0198] Clause 13: A method for managing access control in a Universal Flash Storage (UFS) system, the method comprising: assigning unique stream IDs to a physical UFSHCI function and each of one or more virtual UFSHCI functions using a programmable Function ID (FID) to Stream ID (SID) mapping unit; segregating data streams associated with each function according to the assigned stream IDs; and controlling the programmable FID to SID mapping unit using a host operating system.

[0199] Clause 14: The method of Clause 13, further comprising: accessing the programmable FID to SID mapping unit only through a secure interface restricted to the host operating system.

[0200] Clause 15: The method of Clause 13, further comprising: using the unique stream IDs to control access between security domains associated with the physical UFSHCI function and each of the one or more virtual UFSHCI functions.

[0201] Clause 16: The method of Clause 13, further comprising: using the unique stream IDs to enforce memory access restrictions for the physical UFSHCI function and each of the one or more virtual UFSHCI functions using a memory management unit.

[0202] Clause 17: The method of Clause 13, further comprising: preventing guest operating systems from modifying the assigned stream IDs using the programmable FID to SID mapping unit.

[0203] Clause 18: The method of Clause 13, further comprising: dynamically adjusting the assignment of stream IDs in response to a change in system configuration or security requirement using the host operating system.

[0204] Clause 19: The method of Clause 13, further comprising: implementing the programmable FID to SID mapping unit within the physical UFSHCI function and making it inaccessible to the one or more virtual UFSHCI functions.

[0205] Clause 20: A method for managing access control in a Universal Flash Storage (UFS) device configured to interact with a UFS Host Controller Interface (UFSHCI) , the method comprising: receiving a stream ID associated with a data transfer request from the UFSHCI, wherein the stream ID is assigned by a programmable Function ID (FID) to Stream ID (SID) mapping unit in the UFSHCI; validating the received stream ID against a set of authorized stream IDs for accessing specific areas of the UFS device; executing the data transfer request associated with the validated stream ID; and accessing a memory array according to the validated stream IDs, wherein different sections of the memory array are associated with different authorized stream IDs.

[0206] Clause 21: The method of Clause 20, further comprising: maintaining a mapping between authorized stream IDs and sections of the memory array.

[0207] Clause 22: The method of Clause 20, further comprising: rejecting data transfer requests associated with stream IDs that are not in the set of authorized stream IDs.

[0208] Clause 23: The method of Clause 20, further comprising: updating the set of authorized stream IDs according to instructions received from a host operating system via the UFSHCI.

[0209] Clause 24: The method of Clause 20, further comprising: partitioning the memory array into multiple secure domains, each secure domain associated with one or more authorized stream IDs.

[0210] Clause 25: A method for managing access control in a Universal Flash Storage (UFS) system, the method comprising: assigning unique stream IDs to a physical UFSHCI function and each of one or more virtual UFSHCI functions using a programmable  Function ID (FID) to Stream ID (SID) mapping unit in a UFS Host Controller Interface (UFSHCI) ; controlling the programmable FID to SID mapping unit using a host operating system; validating received stream IDs and executing data transfer requests based on the validation using a controller in a UFS device; accessing a memory array in the UFS device according to the validated stream IDs; transmitting data transfer requests from the UFSHCI to the UFS device, each request associated with a unique stream ID assigned by the FID to SID mapping unit; and enabling data transfer between the UFSHCI functions and sections of the UFS device memory array associated with the assigned and validated stream IDs.

[0211] Clause 26: The method of Clause 25, further comprising: accessing the programmable FID to SID mapping unit via a secure interface restricted to the host operating system.

[0212] Clause 27: The method of Clause 25, further comprising: adjusting the assignment of stream IDs according to changes in system configuration or a security requirement using the host operating system.

[0213] Clause 28: The method of Clause 25, further comprising: denying a data transfer request associated with a stream ID not authorized for a targeted section of the memory array using the UFS device controller.

[0214] Clause 29: The method of Clause 25, further comprising: using the unique stream IDs to enforce memory access restrictions for the physical UFSHCI function and each of the one or more virtual UFSHCI functions using a memory management unit.

[0215] Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0216] Components, the functional blocks, and the modules described herein with respect to FIGs. 1-12 include processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, among other examples, or any  combination thereof. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, application, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, and / or functions, among other examples, whether referred to as software, firmware, middleware, microcode, hardware description language or otherwise. In addition, features discussed herein may be implemented via specialized processor circuitry, via executable instructions, or combinations thereof.

[0217] Those of skill in the art that one or more blocks (or operations) described with reference to FIGs. 1-12 may be combined with one or more blocks (or operations) described with reference to another of the figures. For example, one or more blocks (or operations) of FIG. 1 may be combined with one or more blocks (or operations) of FIG. 3. As another example, one or more blocks associated with FIG. 1 may be combined with one or more blocks (or operations) associated with FIGs. 6-12. Additionally, or alternatively, one or more operations described above with reference to FIGs. 1-4 may be combined with one or more operations described with reference to FIGs. 5-12.

[0218] Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Skilled artisans will also readily recognize that the order or combination of components, methods, or interactions that are described herein are merely examples and that the components, methods, or interactions of the various aspects of the present disclosure may be combined or performed in ways other than those illustrated and described herein.

[0219] The various illustrative logics, logical blocks, modules, circuits and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. The interchangeability of hardware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0220] The hardware and data processing apparatus used to implement the various illustrative logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single-or multi-chip processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or, any conventional processor, controller, microcontroller, or state machine. In some implementations, a processor may be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes and methods may be performed by circuitry that is specific to a given function.

[0221] In one or more aspects, the functions described may be implemented in hardware, digital electronic circuitry, computer software, firmware, including the structures disclosed in this specification and their structural equivalents thereof, or in any combination thereof. Implementations of the subject matter described in this specification also may be implemented as one or more computer programs, which is one or more modules of computer program instructions, encoded on a computer storage media for execution by, or to control the operation of, data processing apparatus.

[0222] If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The processes of a method or algorithm disclosed herein may be implemented in a processor-executable software module which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that may be enabled to transfer a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may include random-access memory (RAM) , read-only memory (ROM) , electrically erasable programmable read-only memory (EEPROM) , CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection may be properly termed a computer-readable medium. Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and instructions on a machine readable medium and computer-readable medium, which may be incorporated into a computer program product.

[0223] Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to some other implementations without departing from the spirit or scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein, but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0224] Additionally, a person having ordinary skill in the art will readily appreciate, opposing terms such as “upper” and “lower” or “front” and back” or “top” and “bottom” or “forward” and “backward” are sometimes used for ease of describing the figures, and indicate relative  positions corresponding to the orientation of the figure on a properly oriented page, and may not reflect the proper orientation of any device as implemented.

[0225] Certain features that are described in this specification in the context of separate implementations also may be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also may be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0226] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one or more example processes in the form of a flow diagram. However, other operations that are not depicted may be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations may be performed before, after, simultaneously, or between any of the illustrated operations. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products. Additionally, some other implementations are within the scope of the following claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve desirable results.

[0227] As used herein, including in the claims, the term “or, ” when used in a list of two or more items, means that any one of the listed items may be employed by itself, or any combination of two or more of the listed items may be employed. For example, if a composition is described as containing components A, B, or C, the composition may contain A alone; B  alone; C alone; A and B in combination; A and C in combination; B and C in combination; or A, B, and C in combination. Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of” indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (that is A and B and C) or any of these in any combination thereof. The term “substantially” is defined as largely but not necessarily wholly what is specified (and includes what is specified; for example, substantially 90 degrees includes 90 degrees and substantially parallel includes parallel) , as understood by a person of ordinary skill in the art. In any disclosed implementations, the term “substantially” may be substituted with “within [apercentage] of” what is specified, where the percentage includes . 1, 1, 5, or 10 percent.

[0228] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1.A Universal Flash Storage (UFS) host controller, comprising:a programmable Function ID (FID) to Stream ID (SID) mapping unit configured to:receive a function ID associated with a virtual UFS Host Controller Interface (UFSHCI) function;map the received function ID to an assigned stream ID based on a programmable mapping; andoutput the assigned stream ID associated with the virtual UFSHCI function, where the output enables in isolating one or more data streams.2.The controller of claim 1, wherein the programmable FID to SID mapping unit comprises a set of registers accessible within an address space of a physical UFSHCI function.3.The controller of claim 2, wherein the set of registers is accessible and configurable through an interface that restricts access to a host operating system.4.The controller of claim 1, wherein the programmable mapping associates each of a plurality of virtual UFSHCI functions with a unique assigned stream ID.5.The controller of claim 4, wherein the unique assigned stream IDs for the plurality of virtual UFSHCI functions are based on a unique stream ID of a physical UFSHCI function.6.The controller of claim 1, further comprising:an interface configured to receive configuration data for the programmable mapping from a host operating system.7.The controller of claim 1, wherein the assigned stream ID is used to differentiate data streams from different virtual UFSHCI functions for implementing access control between security domains.8.The controller of claim 1, wherein the assigned stream ID is used as a device ID for enabling Message Signaled Interrupts (MSIs) with a Generic Interrupt Controller (GIC) Interrupt Translation Service (ITS) .9.The controller of claim 1, wherein the programmable FID to SID mapping unit is configured to:receive configuration commands from a host operating system; anddeny attempts to modify the programmable mapping from non-host operating system sources.10.The controller of claim 1, wherein the programmable FID to SID mapping unit is configured to:enable dynamic reconfiguration of the programmable mapping in response to changes in system memory management unit (SMMU) driver frameworks; andenable allocation of stream IDs by at least one of a UFS host driver or an SMMU driver.11.The controller of claim 1, wherein:the UFS host controller comprises a UFSHCI address space; andthe programmable FID to SID mapping unit includes a set of readable registers within the UFSHCI address space.12.The controller of claim 1, wherein the UFS host controller is configured for use in automotive applications, and wherein:the programmable FID to SID mapping unit is configured to assign unique stream IDs to each of a plurality of virtual UFSHCI functions, the plurality of virtual UFSHCI functions associated with an automotive subsystem; andthe unique stream IDs enable isolated data streams for each automotive subsystem.13.A Universal Flash Storage (UFS) system, comprising:a UFS Host Controller Interface (UFSHCI) functions;one or more virtual UFSHCI functions;a programmable Function ID (FID) to Stream ID (SID) mapping unit configured to:assign unique stream IDs to the physical UFSHCI function and each of the one or more virtual UFSHCI functions; andsegregate data streams associated with each function according to the assigned stream IDs; anda host operating system configured to control the programmable FID to SID mapping unit.14.The UFS system of claim 13, wherein the programmable FID to SID mapping unit is accessible only through a secure interface restricted to the host operating system.15.The UFS system of claim 13, wherein the unique stream IDs are used to control access between security domains associated with the physical UFSHCI function and each of the one or more virtual UFSHCI functions.16.The UFS system of claim 13, further comprising:a memory management unit configured to use the unique stream IDs to enforce memory access restrictions for the physical UFSHCI function and each of the one or more virtual UFSHCI functions.17.The UFS system of claim 13, wherein the programmable FID to SID mapping unit is configured to prevent guest operating systems from modifying the assigned stream IDs.18.The UFS system of claim 13, wherein the host operating system is configured to dynamically adjust the assignment of stream IDs in response to a change in system configuration or security requirement.19.The UFS system of claim 13, wherein the programmable FID to SID mapping unit is implemented within the physical UFSHCI function and is inaccessible to the one or more virtual UFSHCI functions.20.A Universal Flash Storage (UFS) device configured to interact with a UFS Host Controller Interface (UFSHCI) implementing a programmable Function ID (FID) to Stream ID (SID) mapping, the UFS device comprising:a controller configured to:receive at least one data transfer request from the UFSHCI, wherein the at least one data transfer request is associated with at least one virtual UFSHCI function in the UFSHCI;process the at least one data transfer request without utilization of any Stream ID information; andexecute the at least one data transfer request; anda memory array accessible by the controller in response to the at least one data transfer request.21.The UFS device of claim 20, wherein the controller maintains an internal mapping for managing access to at least one section of the memory array, independent of any Stream ID assignments in the UFSHCI.22.The UFS device of claim 20, wherein the controller processes the at least one data transfer request according to a UFS protocol, irrespective of a Stream ID-based access control implemented in the UFSHCI.23.The UFS device of claim 20, wherein the controller updates at least one internal configuration according to at least one instruction received from a host operating system via the UFSHCI, wherein the at least one instruction is independent of Stream ID assignments.24.The UFS device of claim 20, wherein the memory array includes at least one partition, and wherein access to the at least one partition is managed by the controller independently of a Stream ID-based access control implemented in the UFSHCI.25.A Universal Flash Storage (UFS) system, comprising:a UFS Host Controller Interface (UFSHCI) including:a physical UFSHCI function;one or more virtual UFSHCI functions;a programmable Function ID (FID) to Stream ID (SID) mapping unit configured to assign unique stream IDs to the physical UFSHCI function and each of the one or more virtual UFSHCI functions;a host operating system configured to control the programmable FID to SID mapping unit;a UFS device including:a controller configured to validate received stream IDs and execute data transfer requests based on the validation; anda memory array accessible according to the validated stream IDs; anda communication interface between the UFSHCI and the UFS device, configured to:transmit data transfer requests from the UFSHCI to the UFS device, each request associated with a unique stream ID assigned by the FID to SID mapping unit; andenable data transfer between the UFSHCI functions and sections of the UFS device memory array associated with the assigned and validated stream IDs.26.The UFS system of claim 25, wherein the programmable FID to SID mapping unit is accessible via a secure interface restricted to the host operating system.27.The UFS system of claim 25, wherein the host operating system is configured to adjust the assignment of stream IDs according to changes in system configuration or a security requirement.28.The UFS system of claim 25, wherein the UFS device controller is configured to deny a data transfer request associated with a stream ID not authorized for the a targeted section of the memory array.29.The UFS system of claim 25, further comprising a memory management unit configured to use the unique stream IDs to enforce memory access restrictions for the physical UFSHCI function and each of the one or more virtual UFSHCI functions.

Images