[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YbhFTj561N4Ir2RG@kroah.com>
Date: Tue, 14 Dec 2021 08:18:38 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: David Brazdil <dbrazdil@...gle.com>
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 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?
thanks,
greg k-h
Powered by blists - more mailing lists