On Thu, Mar 11, 2021 at 10:08 PM Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: > I guess what we are saying is that real secure monitors should come up > with their own common API for interfacing with RPMB devices without > looking to the Linux kernel for inspiration? The problem is that eMMC at least (I don't know about NVME etc) has serialized commands, meaning you execute one command at a time (some augmentation exist nowadays to speed up things). When it comes to RPMB, the eMMC device must stop all other activity (such as reading/writing any blocks to the eMMC) send a special command to switch to the RPMB partition, then execute the RPMB command(s) then send a special command to switch back to ordinary storage. Someone has to be in control of the eMMC arbitration. Right now Linux MMC/SD storage stack does this. If the secure world want to use RPMB independently of the Linux kernel there are two solutions: - Mount a second eMMC just for the secure world - looks expensive so some other secure counter storage would likely be cheaper and it inevitably increases the BOM which is sensitive to manufacturers (this option is unrealistic) - Let the secure world arbitrate all access to the eMMC - looks inefficient and also dangerous since the secure world now has to implement everything in drivers/mmc/core which is a few 100 KB of really complex code that need to be maintained perpetually. (IMO this option is also unrealistic for performance and maintenance reasons, but who knows what secure world imperialists are out there). This leaves Linux in control of the eMMC RPMB under all circumstances as far as I can see. Yours, Linus Walleij
