[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYNdoK9T503en6dPfz5sSc0eDGLzhnUBqRUbZR3j43byA@mail.gmail.com>
Date: Fri, 12 Mar 2021 11:00:24 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Alex Bennée <alex.bennee@...aro.org>
Cc: Hector Martin <marcan@...can.st>,
Sumit Garg <sumit.garg@...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>,
"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>,
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 Thu, Mar 11, 2021 at 10:08 PM Alex Bennée <alex.bennee@...aro.org> 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
Powered by blists - more mailing lists