linux-kernel - RE: [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend

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: <DM6PR04MB6575FFFC4897119A0F8234D1FC909@DM6PR04MB6575.namprd04.prod.outlook.com>
Date:   Thu, 11 Mar 2021 13:45:55 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Alex Bennée <alex.bennee@...aro.org>
CC:     "Matti.Moell@...nsynergy.com" <Matti.Moell@...nsynergy.com>,
        "arnd@...aro.org" <arnd@...aro.org>,
        "bing.zhu@...el.com" <bing.zhu@...el.com>,
        "hmo@...nsynergy.com" <hmo@...nsynergy.com>,
        "ilias.apalodimas@...aro.org" <ilias.apalodimas@...aro.org>,
        "joakim.bech@...aro.org" <joakim.bech@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-nvme@...r.kernel.org" <linux-nvme@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "maxim.uvarov@...aro.org" <maxim.uvarov@...aro.org>,
        "ruchika.gupta@...aro.org" <ruchika.gupta@...aro.org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "yang.huang@...el.com" <yang.huang@...el.com>
Subject: RE: [RFC PATCH  0/5] RPMB internal and user-space API + WIP
 virtio-rpmb frontend

> Avri Altman <avri.altman@....com> writes:
> 
> > The mmc driver has some hooks to support rpmb access, but access is
> > mainly facilitated from user space, e.g. mmc-utils.
> >
> > The ufs driver has no concept of rpmb access - it is facilitated via
> > user space, e.g. ufs-utils and similar.
> >
> > Both for ufs and mmc, rpmb access is defined in their applicable jedec
> > specs. This is the case for few years now - AFAIK No new rpmb-related
> > stuff is expected to be introduced in the near future.
> >
> > What problems, as far as mmc and ufs, are you trying to solve by this
> > new subsystem?
> 
> Well in my case the addition of virtio-rpmb. As yet another RPMB device
> which only supports RPMB transactions and isn't part of a wider block
> device. The API dissonance comes into play when looking to implement it
> as part of wider block device stacks and then having to do things like
> fake 0 length eMMC devices with just an RPMB partition to use existing
> tools.
> 
> I guess that was the original attraction of having a common kernel
> subsystem to interact with RPMB functionality regardless of the
> underlying HW. However from the other comments it seems the preference
> is just to leave it to user-space and domain specific tools for each
> device type.
Yes.  It took us a while to clean those tools to perform by-spec rpmb access.

Anyway, I do see value in Tomas's/your approach, 
that will refrain from the need to register a designated block device.
Provided that each host is allowed to register its own ops.
Those ops can be a super-set of the various device types.
For ufs and mmc rpmb ops contains 7 operations.

Thanks,
Avri