On Fri, Mar 12, 2021 at 05:29:20PM +0530, Sumit Garg wrote:
> On Fri, 12 Mar 2021 at 01:59, Hector Martin 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
On Fri, 12 Mar 2021 at 01:59, Hector Martin 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
On Thu, Mar 11, 2021 at 10:08 PM Alex Bennée 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
Hi Hector,
I see a misunderstanding here :) explaining below.
On Thu, Mar 11, 2021 at 9:29 PM Hector Martin 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
Hi Hector,
thanks for the long and detailed answer! I learn new things
all the time. (Maybe one day I add something too, who knows.)
I hope I'm not taking too much of your time, we're having fun :)
On Thu, Mar 11, 2021 at 9:02 PM Hector Martin wrote:
> On 11/03/2021 23.06, Linus Walleij wrote:
Hector Martin writes:
> 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
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
On 11/03/2021 23.06, Linus Walleij wrote:
Yes. And this is what mobile phone vendors typically did.
But the nature of different electrical attacks made them worried
about different schemes involving cutting power and disturbing
signals with different probes, so they wanted this counter
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
On Thu, Mar 11, 2021 at 10:22 AM Hector Martin wrote:
> On 11/03/2021 09.36, Linus Walleij wrote:
> > The typical use-case mentioned in one reference is to restrict
> > the number of password/pin attempts and combine that with
> > secure time to make sure that longer and longer intervals are
>
On 11/03/2021 09.49, Linus Walleij wrote:
The use case for TPM on laptops is similar: it can be used by a
provider to lock down a machine, but it can also be used by the
random user to store keys. Very few users beside James
Bottomley are capable of doing that (I am not) but they exist.
On 11/03/2021 09.36, Linus Walleij wrote:
It is not intended to store keys in a way that is somehow safer than
other mechanisms. After all, you need to securely store the RPMB key to
begin with; you might as well use that to encrypt a keystore on any
random block device.
The typical use-case
On Thu, 2021-03-11 at 01:49 +0100, Linus Walleij wrote:
> The use case for TPM on laptops is similar: it can be used by a
> provider to lock down a machine, but it can also be used by the
> random user to store keys. Very few users beside James
> Bottomley are capable of doing that (I am not)
On Wed, Mar 10, 2021 at 11:29 AM Sumit Garg wrote:
> And RPMB key provisioning
> being a one time process should be carried out carefully during device
> manufacturing only.
For a product use case such as a mobile or chromebook or
set-top box: yes. In this scenario something like TEE possesses
On Wed, Mar 10, 2021 at 2:52 PM Hector Martin wrote:
> This relies on having a secure boot chain to start with (otherwise you
> can just bypass policy that way; the RPMB is merely storage to give you
> anti-rollback properties, it can't enforce anything itself). So you
> would have to have a
On 10/03/2021 18.48, Linus Walleij wrote:
Disk is encrypted, and RPMB is there to block any exhaustive
password or other authentication token search.
This relies on having a secure boot chain to start with (otherwise you
can just bypass policy that way; the RPMB is merely storage to give you
On Wed, 10 Mar 2021 at 14:17, Hector Martin wrote:
>
> On 10/03/2021 14.14, Sumit Garg wrote:
> > On Wed, 10 Mar 2021 at 02:47, Hector Martin wrote:
> >>
> >> On 09/03/2021 01.20, Linus Walleij wrote:
> >>> I suppose it would be a bit brutal if the kernel would just go in and
> >>> appropriate
On Wed, Mar 10, 2021 at 9:47 AM Hector Martin wrote:
> Remember that if the key is ever lost, the RPMB is now completely
> useless forever.
>
> This is why, as far as I know, most sane platforms will use hard fused
> values to derive this kind of thing, not any kind of key stored in
> erasable
On Tue, Mar 9, 2021 at 6:12 PM David Howells wrote:
> Linus Walleij wrote:
>
> > As it seems neither Microsoft nor Apple is paying it much attention
> > (+/- new facts) it will be up to the community to define use cases
> > for RPMB. I don't know what would make most sense, but the
> > kernel
On 10/03/2021 14.14, Sumit Garg wrote:
On Wed, 10 Mar 2021 at 02:47, Hector Martin wrote:
On 09/03/2021 01.20, Linus Walleij wrote:
I suppose it would be a bit brutal if the kernel would just go in and
appropriate any empty RPMB it finds, but I suspect it is the right way
to make use of this
On Wed, 10 Mar 2021 at 02:47, Hector Martin wrote:
>
> On 09/03/2021 01.20, Linus Walleij wrote:
> > I suppose it would be a bit brutal if the kernel would just go in and
> > appropriate any empty RPMB it finds, but I suspect it is the right way
> > to make use of this facility given that so many
Hi David,
On Tue, 9 Mar 2021 at 22:43, David Howells wrote:
>
> Linus Walleij wrote:
>
> > As it seems neither Microsoft nor Apple is paying it much attention
> > (+/- new facts) it will be up to the community to define use cases
> > for RPMB. I don't know what would make most sense, but the
>
On 09/03/2021 01.20, Linus Walleij wrote:
I suppose it would be a bit brutal if the kernel would just go in and
appropriate any empty RPMB it finds, but I suspect it is the right way
to make use of this facility given that so many of them are just sitting
there unused. Noone will run
Linus Walleij wrote:
> As it seems neither Microsoft nor Apple is paying it much attention
> (+/- new facts) it will be up to the community to define use cases
> for RPMB. I don't know what would make most sense, but the
> kernel keyring seems to make a bit of sense as it is a well maintained
>
On Fri, Mar 5, 2021 at 9:44 AM Arnd Bergmann wrote:
> I think the scenario for the 'nvme-rpmb' tool that does the signing in user
> space does not involve any TEE at the moment, because PCs usually
> don't have one.
Isn't that because (Windows-)PC:s prefer to use TPMs which
include their own
On Fri, Mar 5, 2021 at 8:52 AM Joakim Bech wrote:
> On Thu, Mar 04, 2021 at 09:56:24PM +0100, Arnd Bergmann wrote:
> > On Wed, Mar 3, 2021 at 2:54 PM Alex Bennée wrote:
> > That said, I can also imagine use cases where we do want to
> > store the key in the kernel's keyring, so maybe we end up
On Thu, Mar 04, 2021 at 09:56:24PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 3, 2021 at 2:54 PM Alex Bennée wrote:
> >
> > A number of storage technologies support a specialised hardware
> > partition designed to be resistant to replay attacks. The underlying
> > HW protocols differ but the
On Wed, Mar 3, 2021 at 2:54 PM Alex Bennée wrote:
>
> A number of storage technologies support a specialised hardware
> partition designed to be resistant to replay attacks. The underlying
> HW protocols differ but the operations are common. The RPMB partition
> cannot be accessed via standard
Foolishly I'd missed you out of the series Cc so you only got those
two patches. You should find the rest @
Subject: [RFC PATCH 0/5] RPMB internal and user-space API + WIP
virtio-rpmb frontend
Date: Wed, 3 Mar 2021 13:54:55 +
Message-Id: <20210303135500.24673-1-alex.ben...@linaro.org>
On Wed, 3 Mar 2021 at 14:55, Alex Bennée wrote:
>
> A number of storage technologies support a specialised hardware
> partition designed to be resistant to replay attacks. The underlying
> HW protocols differ but the operations are common. The RPMB partition
> cannot be accessed via standard
A number of storage technologies support a specialised hardware
partition designed to be resistant to replay attacks. The underlying
HW protocols differ but the operations are common. The RPMB partition
cannot be accessed via standard block layer, but by a set of specific
commands: WRITE, READ,
31 matches
Mail list logo
