Date:   Fri, 12 Mar 2021 17:29:20 +0530
From:   Sumit Garg <sumit.garg@...aro.org>
To:     Hector Martin <marcan@...can.st>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Arnd Bergmann <arnd@...aro.org>,
        "open list:ASYMMETRIC KEYS" <keyrings@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Joakim Bech <joakim.bech@...aro.org>,
        Alex Bennée <alex.bennee@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Maxim Uvarov <maxim.uvarov@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Ruchika Gupta <ruchika.gupta@...aro.org>,
        "Winkler, Tomas" <tomas.winkler@...el.com>, yang.huang@...el.com,
        bing.zhu@...el.com, Matti.Moell@...nsynergy.com,
        hmo@...nsynergy.com, linux-mmc <linux-mmc@...r.kernel.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-nvme@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>,
        Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem

On Fri, 12 Mar 2021 at 01:59, Hector Martin <marcan@...can.st> wrote:
>
> On 11/03/2021 23.31, Linus Walleij wrote:
> > I understand your argument, is your position such that the nature
> > of the hardware is such that community should leave this hardware
> > alone and not try to make use of RPMB  for say ordinary (self-installed)
> > Linux distributions?
>
> It's not really that the community should leave this hardware alone, so
> much that I think there is a very small subset of users who will be able
> to benefit from it, and that subset will be happy with a usable
> kernel/userspace interface and some userspace tooling for this purpose,
> including provisioning and such.
>
> Consider the prerequisites for using RPMB usefully here:
>
> * You need (user-controlled) secureboot

Agree with this prerequisite since secure boot is essential to build
initial trust in any system whether that system employs TEE, TPM,
secure elements etc.

> * You need secret key storage - so either some kind of CPU-fused key, or
> one protected by a TPM paired with the secureboot (key sealed to PCR
> values and such)
> * But if you have a TPM, that can handle secure counters for you already
> AIUI, so you don't need RPMB

Does TPM provide replay protected memory to store information such as:
- PIN retry timestamps?
- Hash of encrypted nvme? IMO, having replay protection for user data
on encrypted nvme is a valid use-case.

> * So this means you must be running a non-TPM secureboot system
>

AFAIK, there exist such systems which provide you with a hardware
crypto accelerator (like CAAM on i.Mx SoCs) that can protect your keys
(in this case RPMB key) and hence can leverage RPMB for replay
protection.

> And so we're back to embedded platforms like Android phones and other
> SoC stuff... user-controlled secureboot is already somewhat rare here,
> and even rarer are the cases where the user controls the whole chain
> including the TEE if any (otherwise it'll be using RPMB already); this
> pretty much excludes all production Android phones except for a few
> designed as completely open systems; we're left with those and a subset
> of dev boards (e.g. the Jetson TX1 I did fuse experiments on). In the
> end, those systems will probably end up with fairly bespoke set-ups for
> any given device or SoC family, for using RPMB.
>
> But then again, if you have a full secureboot system where you control
> the TEE level, wouldn't you want to put the RPMB shenanigans there and
> get some semblance of secure TPM/keystore/attempt throttling
> functionality that is robust against Linux exploits and has a smaller
> attack surface? Systems without EL3 are rare (Apple M1 :-)) so it makes
> more sense to do this on those that do have it. If you're paranoid
> enough to be getting into building your own secure system with
> anti-rollback for retry counters, you should be heading in that directly
> anyway.
>
> And now Linux's RPMB code is useless because you're running the stack in
> the secure monitor instead :-)
>

As Linus mentioned in other reply, there are limitations in order to
put eMMC/RPMB drivers in TEE / secure monitor such as:
- One of the design principle for a TEE is to keep its footprint as
minimal as possible like in OP-TEE we generally try to rely on Linux
for filesystem services, RPMB access etc. And currently we rely on a
user-space daemon (tee-supplicant) for RPMB access which IMO isn't as
secure as compared to direct RPMB access via kernel.
- Most embedded systems possess a single storage device (like eMMC)
for which the kernel needs to play an arbiter role.

It looks like other TEE implementations such as Trusty on Android [1]
and QSEE [2] have a similar interface for RPMB access.

So it's definitely useful for various TEE implementations to have
direct RPMB access via kernel. And while we are at it, I think it
should be useful (given replay protection benefits) to provide an
additional kernel interface to RPMB leveraging Trusted and Encrypted
Keys subsystem.

[1] https://android.googlesource.com/trusty/app/storage/
[2] https://www.qualcomm.com/media/documents/files/guard-your-data-with-the-qualcomm-snapdragon-mobile-platform.pdf

-Sumit

> --
> Hector Martin (marcan@...can.st)
> Public Key: https://mrcn.st/pub

Powered by blists - more mailing lists