Hi Marcan, thanks for the detailed description of your experience with the TPM and secure enclave! This is the kind of thinking and experience we really need here because it paints the bigger picture. I am very happy for involving you in this discussion because of your wide perspective on these features. On Thu, Mar 11, 2021 at 10:45 AM Hector Martin <marcan@xxxxxxxxx> wrote: > All of these things make putting keys into TPMs, YubiKeys, the SEP, etc > a useful thing for anyone, regardless of whether their machine is locked > down or not. > > This is not the case for RPMB. RPMB *relies* on the software running on > the other side being trusted. RPMB, alone, provides zero new security > guarantees, without trusted software communicating with it. I kind of agree. My position is more like this: different storage media like eMMC, nvme etc are starting to provide RPMB, so we should provide an interface to it, harden it and test it, such that trusted systems can eventually use them, once they get there. eMMC and NVME already have divergent RPMB userspace interfaces. The code is already there. An in-kernel interface and joining the interfaces is under discussion. ($SUBJECT) Currently engineers are probably concerned with being able to make use of RPMB in their machines for present day TEE use cases, but as community we need to think of a future scenario where we may want to use it, because the abstractions are being added now, it seems. (Otherwise, in the future, someone is going to say: "why didn't you think about that from the beginning?") It's a fine line. Sometimes it becomes just immature up-front design. Luckily we have people like you telling us off ;) > With the MAC key provisioning for RPMB being a one-time process, it is > inherently a very risky operation that a user must commit to with great > care, as they only get one chance, ever. Yes. Current use cases involve that key mostly being set in manufacturing by vendors and accessible to a TEE-like secure world. It fits them. Their expectation is that the secure world is managed by them and tightly connected to the root of trust in the machine. Then we have these random devices which just happen to have some RPMB on them, sitting around for no reason. The software such as a Linux distribution has not figured out a use case. As a developer, dark silicon is disturbing to me so I try to think about a use case. My idea is more like a one-time use seal: the first user of the machine can use this RPMB store to get some hardware backing for rollback, pin attempts etc, but once that user is done with the machine you have no RPMB anymore (unless the user gives the key to the next user). If they just reformat the harddrive and lose the key, the ability to use this hardware is forever gone. Then software will cope with the situation. Such things happen. It is uncomfortable for those of us coming from the world of generic computing to think about hardware resources as one-time-use-only but in other strands of life such as medical needles this is not unheard of, it happens. > RPMB was designed for the sole purpose of plugging the secure storage > replay exploit for Android phones running TrustZone secure monitors. It > doesn't really do anything else; it's just a single low-level primitive > and you need to already have an equivalent design that is only missing > that piece to get anything from it. And its provisioning model assumes a > typical OEM device production pipeline and integration with CPU fusing; > it isn't friendly to Linux hackers messing around with securing LUKS > unlock attempt counters. 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? Yours, Linus Walleij
