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: <87y2ev6pkw.fsf@linaro.org>
Date:   Wed, 10 Mar 2021 14:29:15 +0000
From:   Alex Bennée <alex.bennee@...aro.org>
To:     Avri Altman <avri.altman@....com>
Cc:     Matti.Moell@...nsynergy.com, arnd@...aro.org, bing.zhu@...el.com,
        hmo@...nsynergy.com, ilias.apalodimas@...aro.org,
        joakim.bech@...aro.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org, linux-nvme@...r.kernel.org,
        linux-scsi@...r.kernel.org, maxim.uvarov@...aro.org,
        ruchika.gupta@...aro.org, tomas.winkler@...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.

>
> Thanks,
> Avri

-- 
Alex Bennée