linux-kernel - Re: [PATCH 0/3] Add quirk to support exynos ufshci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bc342ef-b434-6a56-97e8-582a6588e920@acm.org>
Date:   Thu, 27 May 2021 09:40:01 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     jongmin jeong <jjmin.jeong@...sung.com>, jejb@...ux.ibm.com,
        martin.petersen@...cle.com
Cc:     alim.akhtar@...sung.com, avri.altman@....com, cang@...eaurora.org,
        beanhuo@...ron.com, adrian.hunter@...el.com,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 0/3] Add quirk to support exynos ufshci

On 5/26/21 8:08 PM, jongmin jeong wrote:
> In ExynosAuto(variant of the Exynos for automotive), the UFS Storage needs
> to be accessed from multi-OS.
> To increase IO performance and reduce SW complexity, we implemented UFS-IOV
> to support storage IO virtualization feature on UFS.
> 
> IO virtualization increases IO performance and reduce SW complexity
> with small area cost. And IO virtualization supports virtual machine isolation
> for Security and Safety which are requested by Multi-OS system such as
> automotive application.
> 
> Below figure is the conception of UFS-IOV architeture.
> 
>     +------+          +------+
>     | OS#1 |          | OS#2 |
>     +------+          +------+
>        |                 |
>  +------------+     +------------+
>  |  Physical  |     |   Virtual  |
>  |    Host    |     |    Host    |
>  +------------+     +------------+
>    |      |              | <-- UTP_CMD_SAP, UTP_TM_SAP
>    |   +-------------------------+
>    |   |    Function Arbitor     |
>    |   +-------------------------+
>  +-------------------------------+
>  |           UTP Layer           |
>  +-------------------------------+
>  +-------------------------------+
>  |           UIC Layer           |
>  +-------------------------------+
> 
> There are two types of host controllers on the UFS host controller
> that we designed.
> The UFS device has a Function Arbitor that arranges commands of each host.
> When each host transmits a command to the Arbitor, the Arbitor transmits it
> to the UTP layer.
> Physical Host(PH) support all UFSHCI functions(all SAPs) same as conventional
> UFSHCI.
> Virtual Host(VH) support only data transfer function(UTP_CMD_SAP and UTP_TM_SAP).
> 
> In an environment where multiple OSs are used, the OS that has the leadership of
> the system is called System OS. This system OS uses PH and controls error handling.
> 
> Since VH can only use less functions than PH, it is necessary to send a request
> to PH for Detected Error Handling in VH. To interface among PH and VHs,
> UFSHCI HW supports mailbox. PH can broadcast mail to other VH at the same time
> with arguments and VH can mail to PH with arguments.
> PH and VH generate interrupts when mails from PH or VH.
> 
> In this structure, the virtual host can't support some feature and need to skip
> the some part of ufshcd code by using quirk.
> This patchs add quirks so that the UIC command is ignored and the ufshcd init
> process can be skipped for VH. Also, according to our UFS-IOV policy,
> we added a quirk to the abort handler or device reset handler to call
> the host reset handler.

More information is needed about how multiple operating systems share a
single UFS device. Are LUNs shared across operating systems, does each
OS access separate LUNs or does each OS access different partitions on
the same LUN? Do you agree that for the latter two it is not necessary
to provide the virtual host access to the UTP layer?

Bart.