linux-kernel - Re: [PATCH v3 2/2] misc: open-dice: Add driver to expose DICE data to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Dec 2021 14:37:12 +0000
From:   David Brazdil <dbrazdil@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Rob Herring <robh+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Will Deacon <will@...nel.org>,
        Andrew Scull <ascull@...gle.com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] misc: open-dice: Add driver to expose DICE data
 to userspace

On Tue, Dec 14, 2021 at 08:18:38AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 13, 2021 at 07:58:33PM +0000, David Brazdil wrote:
> > Open Profile for DICE is an open protocol for measured boot compatible
> > with the Trusted Computing Group's Device Identifier Composition
> > Engine (DICE) specification. The generated Compound Device Identifier
> > (CDI) certificates represent the hardware/software combination measured
> > by DICE, and can be used for remote attestation and sealing.
> > 
> > Add a driver that exposes reserved memory regions populated by firmware
> > with DICE CDIs and exposes them to userspace via a character device.
> > 
> > Userspace obtains the memory region's size from read() and calls mmap()
> > to create a mapping of the memory region in its address space. The
> > mapping is not allowed to be write+shared, giving userspace a guarantee
> > that the data were not overwritten by another process.
> > 
> > Userspace can also call write(), which triggers a wipe of the DICE data
> > by the driver. Because both the kernel and userspace mappings use
> > write-combine semantics, all clients observe the memory as zeroed after
> > the syscall has returned.
> > 
> > Cc: Andrew Scull <ascull@...gle.com>
> > Cc: Will Deacon <will@...nel.org>
> > Signed-off-by: David Brazdil <dbrazdil@...gle.com>
> > ---
> >  drivers/misc/Kconfig     |  12 +++
> >  drivers/misc/Makefile    |   1 +
> >  drivers/misc/open-dice.c | 197 +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 210 insertions(+)
> >  create mode 100644 drivers/misc/open-dice.c
> > 
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 0f5a49fc7c9e..4d996485f5a7 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -470,6 +470,18 @@ config HISI_HIKEY_USB
> >  	  switching between the dual-role USB-C port and the USB-A host ports
> >  	  using only one USB controller.
> >  
> > +config OPEN_DICE
> > +	tristate "Open Profile for DICE driver"
> > +	depends on OF_RESERVED_MEM
> > +	help
> > +	  This driver exposes a DICE reserved memory region to userspace via
> > +	  a character device. The memory region contains Compound Device
> > +	  Identifiers (CDIs) generated by firmware as an output of DICE
> > +	  measured boot flow. Userspace can uses CDIs for remote attestation
> > +	  and sealing.
> > +
> > +	  If unsure, say N.
> > +
> >  source "drivers/misc/c2port/Kconfig"
> >  source "drivers/misc/eeprom/Kconfig"
> >  source "drivers/misc/cb710/Kconfig"
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index a086197af544..70e800e9127f 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -59,3 +59,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
> >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> >  obj-$(CONFIG_HI6421V600_IRQ)	+= hi6421v600-irq.o
> > +obj-$(CONFIG_OPEN_DICE)		+= open-dice.o
> > diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> > new file mode 100644
> > index 000000000000..ea7b1a8d49ac
> > --- /dev/null
> > +++ b/drivers/misc/open-dice.c
> > @@ -0,0 +1,197 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 - Google LLC
> > + * Author: David Brazdil <dbrazdil@...gle.com>
> > + *
> > + * Driver for Open Profile for DICE.
> > + *
> > + * This driver takes ownership of a reserved memory region containing secrets
> > + * derived following the Open Profile for DICE. The contents of the memory
> > + * region are not interpreted by the kernel but can be mapped into a userspace
> > + * process via a misc device. The memory region can also be wiped, removing
> > + * the secrets from memory.
> > + *
> > + * Userspace can access the data by (w/o error handling):
> > + *
> > + *     fd = open("/dev/open-dice0", O_RDWR);
> > + *     size = read(fd, NULL, 0);
> 
> I was thinking you would return the value as a string in the buffer
> provided to the read call, not as the return value itself.  That is odd
> and probably breaks something.  What would happen if you ran 'cat' on
> the device node?

Ah, I misunderstood. Yeah, running `cat` will endlessly print garbage.
I'll do a quick respin and also change write() to appear to consume the
buffer because 'echo 1 > /dev/open-dice0' currently blocks.

David