linux-kernel - RPMB user space ABI

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>] [day] [month] [year] [list]

Message-ID: <87mtwashi4.fsf@linaro.org>
Date:   Thu, 11 Feb 2021 14:07:00 +0000
From:   Alex Bennée <alex.bennee@...aro.org>
To:     linux-kernel@...r.kernel.org,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-nvme@...r.kernel.org" <linux-nvme@...r.kernel.org>
Cc:     Tomas Winkler <tomas.winkler@...el.com>,
        Alexander Usyskin <alexander.usyskin@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Arnd Bergmann <arnd.bergmann@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Huang Yang <yang.huang@...el.com>,
        Ruchika Gupta <ruchika.gupta@...aro.org>
Subject: RPMB user space ABI

Hi,

Last year while I was implementing a virtio-rpmb backend for QEMU I
ended up using patches from the ACRN tree which was based on Thomas'
patches last posted in 2016:

  https://lore.kernel.org/lkml/1478548394-8184-1-git-send-email-tomas.winkler@intel.com/

which I bastardised into a testing tree on a more recent kernel:

  https://git.linaro.org/people/alex.bennee/linux.git/log/?h=testing/virtio-rpmb

The main reason I hacked them around was because the VirtIO spec had
since been finalised and had a very different framing structure. The
original proposed ABI provided for an ioctl which sent JDEC frames to
the underlying device. This was later expanded to support NVME style
frames. Neither of these frame sequences matched the final VirtIO
specification.

It seems to me having the ioctl ABI at this level exposes too many
underlying HW details to user space. With the number of HW devices that
providing RPMB features likely to grow from the current 3 (eMMC/JDEC,
NVME, VirtIO) it seems this ABI should operate at a higher level, e.g.:

      PROGRAM_KEY
      GET_WRITE_COUNTER
      WRITE_DATA
      READ_DATA

and I guess some sort of asynchronous result check?

It would then be for the kernel to take the higher level concepts and
translate them to the final frames required to talk to the actual HW (if
indeed there is some).

Does this seem reasonable? Is this orthogonal to any access to RPMB
partitions that file-systems might want to do?

-- 
Alex Bennée