Hi Hector, I see a misunderstanding here :) explaining below. On Thu, Mar 11, 2021 at 9:29 PM Hector Martin <marcan@xxxxxxxxx> wrote: > 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. Hehe. I think we have different ideas of "user-controlled" here, our "users" include OP-TEE, which develop and deploy a TEE which is open source. https://www.op-tee.org/ Joakim who works on this project is on CC he's just not saying anything (yet). This project is forked and deployed by different Android and other Arm SoC-using vendors. Some vendors have written their own TEE from scratch. So our users include these guys. :) As in: they take an active interest in what we are designing here. They have access to devices where they can replace the whole secure world for development. They work actively with the kernel and created the drivers/tee subsystem which is the pipe where the kernel and the TEE communicate. > 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 :-) The way OP-TEE makes use of RPMB is to call out to a userspace daemon called tee-supplicant, which issues ioctl()s down to the eMMC device to read/write counters. AFAIK other TEE implementations use a similar scheme. (Judging from feedback I got when rewriting the RPMB code in the MMC subsystem, it mattered to them.) Their source code is here: https://github.com/OP-TEE/optee_client/blob/master/tee-supplicant/src/rpmb.c So Linux' eMMC RPMB code is already in wide use for this, it is what I think all Android phones are actually using to read/write RPMB counters. It's not like they're accessing RPMB "on the side" or so. (I might be wrong!) Since reading/writing RPMB on eMMC needs to be serialized alongside Linux' read/write commands it is absolutely necessary that the secure world and the Linux storage drivers cooperate so the solution is to let Linux handle this arbitration. Now the question for this patch set is: is TEE software the only user we need to care about? Yours, Linus Walleij
