On Fri, 12 Mar 2021 at 01:59, Hector Martin <marcan@xxxxxxxxx> 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@xxxxxxxxx) > Public Key: https://mrcn.st/pub
