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 measured hardware/software combination
and can be used by userspace for remote attestation and sealing.
This patchset adds DeviceTree bindings for the DICE device referencing
a reserved memory region containing the CDIs, and a driver that exposes
the memory region to userspace via a misc device.
See https://pigweed.googlesource.com/open-dice for more details.
The patches are based on top of v5.16-rc6 and can also be found here:
https://android-kvm.googlesource.com/linux topic/dice_v5
Changes since v4:
* registered compatible in 'reserved_mem_matches'
* removed unnecessary DT node, only reserved-memory
* fixed typos in comments
Changes since v3:
* align with semantics of read/write
* fix kerneldoc warnings
* fix printf format warnings
Changes since v2:
* renamed from 'dice' to 'open-dice'
* replaced ioctls with read/write
* replaced memzero_explicit with memset
* allowed multiple instances
* expanded Kconfig description
Changes since v1:
* converted to miscdevice
* all mappings now write-combine to simplify semantics
* removed atomic state, any attempt at exclusive access
* simplified wipe, applied on ioctl, not on release
* fixed ioctl return value
David Brazdil (2):
dt-bindings: reserved-memory: Open Profile for DICE
misc: open-dice: Add driver to expose DICE data to userspace
.../reserved-memory/google,open-dice.yaml | 45 +++++
drivers/misc/Kconfig | 12 ++
drivers/misc/Makefile | 1 +
drivers/misc/open-dice.c | 188 ++++++++++++++++++
drivers/of/platform.c | 1 +
5 files changed, 247 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
create mode 100644 drivers/misc/open-dice.c
--
2.34.1.307.g9b7440fafd-goog
Add DeviceTree bindings for Open Profile for DICE, an open protocol for
measured boot. Firmware uses DICE to measure the hardware/software
combination and generates Compound Device Identifier (CDI) certificates.
These are stored in memory and the buffer is described in the DT as
a reserved memory region compatible with 'google,open-dice'.
Signed-off-by: David Brazdil <[email protected]>
---
.../reserved-memory/google,open-dice.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
new file mode 100644
index 000000000000..7bc714e9715f
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/google,open-dice.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open Profile for DICE Device Tree Bindings
+
+description: |
+ This binding represents a reserved memory region containing data
+ generated by the Open Profile for DICE protocol.
+
+ See https://pigweed.googlesource.com/open-dice/
+
+maintainers:
+ - David Brazdil <[email protected]>
+
+allOf:
+ - $ref: "reserved-memory.yaml"
+
+properties:
+ compatible:
+ const: google,open-dice
+
+ reg:
+ description: page-aligned region of memory containing DICE data
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: true
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ dice: dice@12340000 {
+ compatible = "google,open-dice";
+ reg = <0x00 0x12340000 0x2000>;
+ no-map;
+ };
+ };
--
2.34.1.307.g9b7440fafd-goog
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 <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: David Brazdil <[email protected]>
---
drivers/misc/Kconfig | 12 +++
drivers/misc/Makefile | 1 +
drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 1 +
4 files changed, 202 insertions(+)
create mode 100644 drivers/misc/open-dice.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
--- /dev/null
+++ b/drivers/misc/open-dice.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 - Google LLC
+ * Author: David Brazdil <[email protected]>
+ *
+ * Driver for Open Profile for DICE.
+ *
+ * This driver takes ownership of a reserved memory region containing data
+ * generated by the Open Profile for DICE measured boot protocol. The memory
+ * contents are not interpreted by the kernel but can be mapped into a userspace
+ * process via a misc device. Userspace can also request a wipe of the memory.
+ *
+ * Userspace can access the data with (w/o error handling):
+ *
+ * fd = open("/dev/open-dice0", O_RDWR);
+ * read(fd, &size, sizeof(unsigned long));
+ * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ * write(fd, NULL, 0); // wipe
+ * close(fd);
+ */
+
+#include <linux/io.h>
+#include <linux/miscdevice.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+
+#define DRIVER_NAME "open-dice"
+
+struct open_dice_drvdata {
+ spinlock_t lock;
+ char name[16];
+ struct reserved_mem *rmem;
+ struct miscdevice misc;
+};
+
+static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
+{
+ return container_of(filp->private_data, struct open_dice_drvdata, misc);
+}
+
+static int open_dice_wipe(struct open_dice_drvdata *drvdata)
+{
+ void *kaddr;
+
+ spin_lock(&drvdata->lock);
+ kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
+ drvdata->rmem->size, MEMREMAP_WC);
+ if (IS_ERR(kaddr)) {
+ spin_unlock(&drvdata->lock);
+ return PTR_ERR(kaddr);
+ }
+
+ memset(kaddr, 0, drvdata->rmem->size);
+ devm_memunmap(drvdata->misc.this_device, kaddr);
+ spin_unlock(&drvdata->lock);
+ return 0;
+}
+
+/*
+ * Copies the size of the reserved memory region to the user-provided buffer.
+ */
+static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
+ loff_t *off)
+{
+ unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
+
+ return simple_read_from_buffer(ptr, len, off, &val, sizeof(val));
+}
+
+/*
+ * Triggers a wipe of the reserved memory region. The user-provided pointer
+ * is never dereferenced.
+ */
+static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
+ size_t len, loff_t *off)
+{
+ if (open_dice_wipe(to_open_dice_drvdata(filp)))
+ return -EIO;
+
+ /* Consume the input buffer. */
+ return len;
+}
+
+/*
+ * Creates a mapping of the reserved memory region in user address space.
+ */
+static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
+
+ /* Do not allow userspace to modify the underlying data. */
+ if ((vma->vm_flags & VM_WRITE) && (vma->vm_flags & VM_SHARED))
+ return -EPERM;
+
+ /* Create write-combine mapping so all clients observe a wipe. */
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
+ return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
+}
+
+static const struct file_operations open_dice_fops = {
+ .owner = THIS_MODULE,
+ .read = open_dice_read,
+ .write = open_dice_write,
+ .mmap = open_dice_mmap,
+};
+
+static int __init open_dice_probe(struct platform_device *pdev)
+{
+ static unsigned int dev_idx;
+ struct device *dev = &pdev->dev;
+ struct reserved_mem *rmem;
+ struct open_dice_drvdata *drvdata;
+ int ret;
+
+ rmem = of_reserved_mem_lookup(dev->of_node);
+ if (!rmem) {
+ dev_err(dev, "failed to lookup reserved memory\n");
+ return -EINVAL;
+ }
+
+ if (!rmem->size || (rmem->size > ULONG_MAX)) {
+ dev_err(dev, "invalid memory region size\n");
+ return -EINVAL;
+ }
+
+ if (!PAGE_ALIGNED(rmem->base) || !PAGE_ALIGNED(rmem->size)) {
+ dev_err(dev, "memory region must be page-aligned\n");
+ return -EINVAL;
+ }
+
+ drvdata = devm_kmalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ *drvdata = (struct open_dice_drvdata){
+ .lock = __SPIN_LOCK_UNLOCKED(drvdata->lock),
+ .rmem = rmem,
+ .misc = (struct miscdevice){
+ .parent = dev,
+ .name = drvdata->name,
+ .minor = MISC_DYNAMIC_MINOR,
+ .fops = &open_dice_fops,
+ .mode = 0600,
+ },
+ };
+
+ /* Index overflow check not needed, misc_register() will fail. */
+ snprintf(drvdata->name, sizeof(drvdata->name), DRIVER_NAME"%u", dev_idx++);
+
+ ret = misc_register(&drvdata->misc);
+ if (ret) {
+ dev_err(dev, "failed to register misc device '%s': %d\n",
+ drvdata->name, ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, drvdata);
+ return 0;
+}
+
+static int open_dice_remove(struct platform_device *pdev)
+{
+ struct open_dice_drvdata *drvdata = platform_get_drvdata(pdev);
+
+ misc_deregister(&drvdata->misc);
+ return 0;
+}
+
+static const struct of_device_id open_dice_of_match[] = {
+ { .compatible = "google,open-dice" },
+ {},
+};
+
+static struct platform_driver open_dice_driver = {
+ .remove = open_dice_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = open_dice_of_match,
+ },
+};
+
+module_platform_driver_probe(open_dice_driver, open_dice_probe);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("David Brazdil <[email protected]>");
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..d659ed0be342 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -514,6 +514,7 @@ static const struct of_device_id reserved_mem_matches[] = {
{ .compatible = "qcom,smem" },
{ .compatible = "ramoops" },
{ .compatible = "nvmem-rmem" },
+ { .compatible = "google,open-dice" },
{}
};
--
2.34.1.307.g9b7440fafd-goog
On Tue, Dec 21, 2021 at 05:45:01PM +0000, David Brazdil wrote:
> Add DeviceTree bindings for Open Profile for DICE, an open protocol for
> measured boot. Firmware uses DICE to measure the hardware/software
> combination and generates Compound Device Identifier (CDI) certificates.
> These are stored in memory and the buffer is described in the DT as
> a reserved memory region compatible with 'google,open-dice'.
>
> Signed-off-by: David Brazdil <[email protected]>
> ---
> .../reserved-memory/google,open-dice.yaml | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
> new file mode 100644
> index 000000000000..7bc714e9715f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/google,open-dice.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Profile for DICE Device Tree Bindings
> +
> +description: |
> + This binding represents a reserved memory region containing data
> + generated by the Open Profile for DICE protocol.
> +
> + See https://pigweed.googlesource.com/open-dice/
> +
> +maintainers:
> + - David Brazdil <[email protected]>
> +
> +allOf:
> + - $ref: "reserved-memory.yaml"
> +
> +properties:
> + compatible:
> + const: google,open-dice
> +
> + reg:
> + description: page-aligned region of memory containing DICE data
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: true
unevaluatedProperties: false
Additional properties are only allowed for common schema included by
other schemas.
> +
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + dice: dice@12340000 {
> + compatible = "google,open-dice";
> + reg = <0x00 0x12340000 0x2000>;
> + no-map;
> + };
> + };
> --
> 2.34.1.307.g9b7440fafd-goog
>
>
On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> Cc: Will Deacon <[email protected]>
> Signed-off-by: David Brazdil <[email protected]>
> ---
> drivers/misc/Kconfig | 12 +++
> drivers/misc/Makefile | 1 +
> drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> drivers/of/platform.c | 1 +
Acked-by: Rob Herring <[email protected]>
> 4 files changed, 202 insertions(+)
> create mode 100644 drivers/misc/open-dice.c
On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> Cc: Will Deacon <[email protected]>
> Signed-off-by: David Brazdil <[email protected]>
> ---
> drivers/misc/Kconfig | 12 +++
> drivers/misc/Makefile | 1 +
> drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> drivers/of/platform.c | 1 +
> 4 files changed, 202 insertions(+)
> create mode 100644 drivers/misc/open-dice.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> --- /dev/null
> +++ b/drivers/misc/open-dice.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2021 - Google LLC
> + * Author: David Brazdil <[email protected]>
> + *
> + * Driver for Open Profile for DICE.
> + *
> + * This driver takes ownership of a reserved memory region containing data
> + * generated by the Open Profile for DICE measured boot protocol. The memory
> + * contents are not interpreted by the kernel but can be mapped into a userspace
> + * process via a misc device. Userspace can also request a wipe of the memory.
> + *
> + * Userspace can access the data with (w/o error handling):
> + *
> + * fd = open("/dev/open-dice0", O_RDWR);
> + * read(fd, &size, sizeof(unsigned long));
> + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> + * write(fd, NULL, 0); // wipe
> + * close(fd);
> + */
> +
> +#include <linux/io.h>
> +#include <linux/miscdevice.h>
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +
> +#define DRIVER_NAME "open-dice"
> +
> +struct open_dice_drvdata {
> + spinlock_t lock;
> + char name[16];
> + struct reserved_mem *rmem;
> + struct miscdevice misc;
> +};
> +
> +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> +{
> + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> +}
> +
> +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> +{
> + void *kaddr;
> +
> + spin_lock(&drvdata->lock);
> + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> + drvdata->rmem->size, MEMREMAP_WC);
> + if (IS_ERR(kaddr)) {
> + spin_unlock(&drvdata->lock);
> + return PTR_ERR(kaddr);
> + }
> +
> + memset(kaddr, 0, drvdata->rmem->size);
> + devm_memunmap(drvdata->misc.this_device, kaddr);
> + spin_unlock(&drvdata->lock);
> + return 0;
> +}
> +
> +/*
> + * Copies the size of the reserved memory region to the user-provided buffer.
> + */
> +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> + loff_t *off)
> +{
> + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
There's a UAF issue here (and in all file operations that call
to_open_dice_drvdata) when the platform device in unbounded from the driver
while userspace has an instance of the misc device open: after open_dice_remove
is called, all managed resources are freed (which includes this
open_dice_drvdata allocation).
No new miscdev files can be created, but the existing ones continue to exist
with a now dangling pointer stored in private_data. So read/write/mmap syscalls
from userspace will lead to dereferencing this dangling pointer.
> +
> + return simple_read_from_buffer(ptr, len, off, &val, sizeof(val));
> +}
> +
> +/*
> + * Triggers a wipe of the reserved memory region. The user-provided pointer
> + * is never dereferenced.
> + */
> +static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> + size_t len, loff_t *off)
> +{
> + if (open_dice_wipe(to_open_dice_drvdata(filp)))
> + return -EIO;
> +
> + /* Consume the input buffer. */
> + return len;
> +}
> +
> +/*
> + * Creates a mapping of the reserved memory region in user address space.
> + */
> +static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
> +
> + /* Do not allow userspace to modify the underlying data. */
> + if ((vma->vm_flags & VM_WRITE) && (vma->vm_flags & VM_SHARED))
> + return -EPERM;
> +
> + /* Create write-combine mapping so all clients observe a wipe. */
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> +}
Is there a reason for mapping this memory instead of, say, copying it to
userspace via read?
I ask because there's also a problem here related to unbind. Specifically, after
the device is unbound (open_dice_remove is called), the driver should stop using
the device resources. But if userspace has mapped these pages in, the resources
are still in use despite the unbind.
So if we really want to map this to userspace, it seems like we need to keep
track of all mappings and tear them down on remove.
> +
> +static const struct file_operations open_dice_fops = {
> + .owner = THIS_MODULE,
> + .read = open_dice_read,
> + .write = open_dice_write,
> + .mmap = open_dice_mmap,
> +};
> +
> +static int __init open_dice_probe(struct platform_device *pdev)
> +{
> + static unsigned int dev_idx;
> + struct device *dev = &pdev->dev;
> + struct reserved_mem *rmem;
> + struct open_dice_drvdata *drvdata;
> + int ret;
> +
> + rmem = of_reserved_mem_lookup(dev->of_node);
> + if (!rmem) {
> + dev_err(dev, "failed to lookup reserved memory\n");
> + return -EINVAL;
> + }
> +
> + if (!rmem->size || (rmem->size > ULONG_MAX)) {
> + dev_err(dev, "invalid memory region size\n");
> + return -EINVAL;
> + }
> +
> + if (!PAGE_ALIGNED(rmem->base) || !PAGE_ALIGNED(rmem->size)) {
> + dev_err(dev, "memory region must be page-aligned\n");
> + return -EINVAL;
> + }
> +
> + drvdata = devm_kmalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + *drvdata = (struct open_dice_drvdata){
> + .lock = __SPIN_LOCK_UNLOCKED(drvdata->lock),
> + .rmem = rmem,
> + .misc = (struct miscdevice){
> + .parent = dev,
> + .name = drvdata->name,
> + .minor = MISC_DYNAMIC_MINOR,
> + .fops = &open_dice_fops,
> + .mode = 0600,
> + },
> + };
> +
> + /* Index overflow check not needed, misc_register() will fail. */
> + snprintf(drvdata->name, sizeof(drvdata->name), DRIVER_NAME"%u", dev_idx++);
> +
> + ret = misc_register(&drvdata->misc);
> + if (ret) {
> + dev_err(dev, "failed to register misc device '%s': %d\n",
> + drvdata->name, ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, drvdata);
> + return 0;
> +}
> +
> +static int open_dice_remove(struct platform_device *pdev)
> +{
> + struct open_dice_drvdata *drvdata = platform_get_drvdata(pdev);
> +
> + misc_deregister(&drvdata->misc);
> + return 0;
> +}
> +
> +static const struct of_device_id open_dice_of_match[] = {
> + { .compatible = "google,open-dice" },
> + {},
> +};
> +
> +static struct platform_driver open_dice_driver = {
> + .remove = open_dice_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = open_dice_of_match,
> + },
> +};
> +
> +module_platform_driver_probe(open_dice_driver, open_dice_probe);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("David Brazdil <[email protected]>");
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b3faf89744aa..d659ed0be342 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -514,6 +514,7 @@ static const struct of_device_id reserved_mem_matches[] = {
> { .compatible = "qcom,smem" },
> { .compatible = "ramoops" },
> { .compatible = "nvmem-rmem" },
> + { .compatible = "google,open-dice" },
> {}
> };
>
> --
> 2.34.1.307.g9b7440fafd-goog
>
Hi Wedson,
On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Signed-off-by: David Brazdil <[email protected]>
> > ---
> > drivers/misc/Kconfig | 12 +++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > drivers/of/platform.c | 1 +
> > 4 files changed, 202 insertions(+)
> > create mode 100644 drivers/misc/open-dice.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > --- /dev/null
> > +++ b/drivers/misc/open-dice.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 - Google LLC
> > + * Author: David Brazdil <[email protected]>
> > + *
> > + * Driver for Open Profile for DICE.
> > + *
> > + * This driver takes ownership of a reserved memory region containing data
> > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > + * process via a misc device. Userspace can also request a wipe of the memory.
> > + *
> > + * Userspace can access the data with (w/o error handling):
> > + *
> > + * fd = open("/dev/open-dice0", O_RDWR);
> > + * read(fd, &size, sizeof(unsigned long));
> > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > + * write(fd, NULL, 0); // wipe
> > + * close(fd);
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/miscdevice.h>
> > +#include <linux/mm.h>
> > +#include <linux/module.h>
> > +#include <linux/of_reserved_mem.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define DRIVER_NAME "open-dice"
> > +
> > +struct open_dice_drvdata {
> > + spinlock_t lock;
> > + char name[16];
> > + struct reserved_mem *rmem;
> > + struct miscdevice misc;
> > +};
> > +
> > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > +{
> > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > +}
> > +
> > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > +{
> > + void *kaddr;
> > +
> > + spin_lock(&drvdata->lock);
> > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > + drvdata->rmem->size, MEMREMAP_WC);
> > + if (IS_ERR(kaddr)) {
> > + spin_unlock(&drvdata->lock);
> > + return PTR_ERR(kaddr);
> > + }
> > +
> > + memset(kaddr, 0, drvdata->rmem->size);
> > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > + spin_unlock(&drvdata->lock);
> > + return 0;
> > +}
> > +
> > +/*
> > + * Copies the size of the reserved memory region to the user-provided buffer.
> > + */
> > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > + loff_t *off)
> > +{
> > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
>
> There's a UAF issue here (and in all file operations that call
> to_open_dice_drvdata) when the platform device in unbounded from the driver
> while userspace has an instance of the misc device open: after open_dice_remove
> is called, all managed resources are freed (which includes this
> open_dice_drvdata allocation).
>
> No new miscdev files can be created, but the existing ones continue to exist
> with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> from userspace will lead to dereferencing this dangling pointer.
Please correct me if I'm wrong, but I don't think this can happen
without tainting the kernel.
To call open_dice_remove, we have to remove the module. And any process
holding an FD of the misc device will increase the module's refcounter,
which is zero-checked in SYS_delete_module. The only way to get past
that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
which changes the implementation of try_force_unload (kernel/module.c)
and adds taint. Otherwise SYS_delete_module returns an error.
Unless there is another way how to trigger this situation, I think the
existing protection is sufficient. The user cannot force the removal of
the module without agreeing to the consequences.
> > +
> > + return simple_read_from_buffer(ptr, len, off, &val, sizeof(val));
> > +}
> > +
> > +/*
> > + * Triggers a wipe of the reserved memory region. The user-provided pointer
> > + * is never dereferenced.
> > + */
> > +static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> > + size_t len, loff_t *off)
> > +{
> > + if (open_dice_wipe(to_open_dice_drvdata(filp)))
> > + return -EIO;
> > +
> > + /* Consume the input buffer. */
> > + return len;
> > +}
> > +
> > +/*
> > + * Creates a mapping of the reserved memory region in user address space.
> > + */
> > +static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> > +{
> > + struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
> > +
> > + /* Do not allow userspace to modify the underlying data. */
> > + if ((vma->vm_flags & VM_WRITE) && (vma->vm_flags & VM_SHARED))
> > + return -EPERM;
> > +
> > + /* Create write-combine mapping so all clients observe a wipe. */
> > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > +}
>
> Is there a reason for mapping this memory instead of, say, copying it to
> userspace via read?
The data should be treated as secret, so the idea is that avoiding
reading it in the kernel means we don't need to worry about it leakage
via the stack, etc. The reason for this is that the DICE derivation
chain may continue in userspace, so we want to minimize the chance of
a child process getting the parent secret from the kernel.
>
> I ask because there's also a problem here related to unbind. Specifically, after
> the device is unbound (open_dice_remove is called), the driver should stop using
> the device resources. But if userspace has mapped these pages in, the resources
> are still in use despite the unbind.
>
> So if we really want to map this to userspace, it seems like we need to keep
> track of all mappings and tear them down on remove.
Same as above, don't think this can happen without the user knowingly
shooting themselves in the foot.
> > +
> > +static const struct file_operations open_dice_fops = {
> > + .owner = THIS_MODULE,
> > + .read = open_dice_read,
> > + .write = open_dice_write,
> > + .mmap = open_dice_mmap,
> > +};
> > +
> > +static int __init open_dice_probe(struct platform_device *pdev)
> > +{
> > + static unsigned int dev_idx;
> > + struct device *dev = &pdev->dev;
> > + struct reserved_mem *rmem;
> > + struct open_dice_drvdata *drvdata;
> > + int ret;
> > +
> > + rmem = of_reserved_mem_lookup(dev->of_node);
> > + if (!rmem) {
> > + dev_err(dev, "failed to lookup reserved memory\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (!rmem->size || (rmem->size > ULONG_MAX)) {
> > + dev_err(dev, "invalid memory region size\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (!PAGE_ALIGNED(rmem->base) || !PAGE_ALIGNED(rmem->size)) {
> > + dev_err(dev, "memory region must be page-aligned\n");
> > + return -EINVAL;
> > + }
> > +
> > + drvdata = devm_kmalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > + if (!drvdata)
> > + return -ENOMEM;
> > +
> > + *drvdata = (struct open_dice_drvdata){
> > + .lock = __SPIN_LOCK_UNLOCKED(drvdata->lock),
> > + .rmem = rmem,
> > + .misc = (struct miscdevice){
> > + .parent = dev,
> > + .name = drvdata->name,
> > + .minor = MISC_DYNAMIC_MINOR,
> > + .fops = &open_dice_fops,
> > + .mode = 0600,
> > + },
> > + };
> > +
> > + /* Index overflow check not needed, misc_register() will fail. */
> > + snprintf(drvdata->name, sizeof(drvdata->name), DRIVER_NAME"%u", dev_idx++);
> > +
> > + ret = misc_register(&drvdata->misc);
> > + if (ret) {
> > + dev_err(dev, "failed to register misc device '%s': %d\n",
> > + drvdata->name, ret);
> > + return ret;
> > + }
> > +
> > + platform_set_drvdata(pdev, drvdata);
> > + return 0;
> > +}
> > +
> > +static int open_dice_remove(struct platform_device *pdev)
> > +{
> > + struct open_dice_drvdata *drvdata = platform_get_drvdata(pdev);
> > +
> > + misc_deregister(&drvdata->misc);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id open_dice_of_match[] = {
> > + { .compatible = "google,open-dice" },
> > + {},
> > +};
> > +
> > +static struct platform_driver open_dice_driver = {
> > + .remove = open_dice_remove,
> > + .driver = {
> > + .name = DRIVER_NAME,
> > + .of_match_table = open_dice_of_match,
> > + },
> > +};
> > +
> > +module_platform_driver_probe(open_dice_driver, open_dice_probe);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("David Brazdil <[email protected]>");
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index b3faf89744aa..d659ed0be342 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -514,6 +514,7 @@ static const struct of_device_id reserved_mem_matches[] = {
> > { .compatible = "qcom,smem" },
> > { .compatible = "ramoops" },
> > { .compatible = "nvmem-rmem" },
> > + { .compatible = "google,open-dice" },
> > {}
> > };
> >
> > --
> > 2.34.1.307.g9b7440fafd-goog
> >
On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> Hi Wedson,
>
> On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > Cc: Will Deacon <[email protected]>
> > > Signed-off-by: David Brazdil <[email protected]>
> > > ---
> > > drivers/misc/Kconfig | 12 +++
> > > drivers/misc/Makefile | 1 +
> > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > drivers/of/platform.c | 1 +
> > > 4 files changed, 202 insertions(+)
> > > create mode 100644 drivers/misc/open-dice.c
> > >
> > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > --- /dev/null
> > > +++ b/drivers/misc/open-dice.c
> > > @@ -0,0 +1,188 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (C) 2021 - Google LLC
> > > + * Author: David Brazdil <[email protected]>
> > > + *
> > > + * Driver for Open Profile for DICE.
> > > + *
> > > + * This driver takes ownership of a reserved memory region containing data
> > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > + *
> > > + * Userspace can access the data with (w/o error handling):
> > > + *
> > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > + * read(fd, &size, sizeof(unsigned long));
> > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > + * write(fd, NULL, 0); // wipe
> > > + * close(fd);
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/miscdevice.h>
> > > +#include <linux/mm.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of_reserved_mem.h>
> > > +#include <linux/platform_device.h>
> > > +
> > > +#define DRIVER_NAME "open-dice"
> > > +
> > > +struct open_dice_drvdata {
> > > + spinlock_t lock;
> > > + char name[16];
> > > + struct reserved_mem *rmem;
> > > + struct miscdevice misc;
> > > +};
> > > +
> > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > +{
> > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > +}
> > > +
> > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > +{
> > > + void *kaddr;
> > > +
> > > + spin_lock(&drvdata->lock);
> > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > + drvdata->rmem->size, MEMREMAP_WC);
> > > + if (IS_ERR(kaddr)) {
> > > + spin_unlock(&drvdata->lock);
> > > + return PTR_ERR(kaddr);
> > > + }
> > > +
> > > + memset(kaddr, 0, drvdata->rmem->size);
> > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > + spin_unlock(&drvdata->lock);
> > > + return 0;
> > > +}
> > > +
> > > +/*
> > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > + */
> > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > + loff_t *off)
> > > +{
> > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> >
> > There's a UAF issue here (and in all file operations that call
> > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > while userspace has an instance of the misc device open: after open_dice_remove
> > is called, all managed resources are freed (which includes this
> > open_dice_drvdata allocation).
> >
> > No new miscdev files can be created, but the existing ones continue to exist
> > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > from userspace will lead to dereferencing this dangling pointer.
>
> Please correct me if I'm wrong, but I don't think this can happen
> without tainting the kernel.
>
> To call open_dice_remove, we have to remove the module. And any process
> holding an FD of the misc device will increase the module's refcounter,
> which is zero-checked in SYS_delete_module. The only way to get past
> that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> which changes the implementation of try_force_unload (kernel/module.c)
> and adds taint. Otherwise SYS_delete_module returns an error.
>
> Unless there is another way how to trigger this situation, I think the
> existing protection is sufficient. The user cannot force the removal of
> the module without agreeing to the consequences.
You can remove the driver from the device by writing to the "unbind"
file in sysfs for this driver.
Otherwise, yes, you are correct, you can not remove the module from the
system if the file is open, but that does not prevent the driver from
being unbound from the device.
Yes, it is rare, and only able to be done by root, and even then is
something that many drivers fail at. But for new ones, when we notice
it, it should be fixed up before merging just to prevent any future
problems.
> > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > +}
> >
> > Is there a reason for mapping this memory instead of, say, copying it to
> > userspace via read?
>
> The data should be treated as secret, so the idea is that avoiding
> reading it in the kernel means we don't need to worry about it leakage
> via the stack, etc. The reason for this is that the DICE derivation
> chain may continue in userspace, so we want to minimize the chance of
> a child process getting the parent secret from the kernel.
The kernel stack is already secret, this should not be an issue. And
even then, you can always erase it before the call returns to ensure
that it does not stick around, like many crypto functions do.
thanks,
greg k-h
Hi Greg,
On Thu, Jan 06, 2022 at 12:29:15PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> > Hi Wedson,
> >
> > On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > > Cc: Will Deacon <[email protected]>
> > > > Signed-off-by: David Brazdil <[email protected]>
> > > > ---
> > > > drivers/misc/Kconfig | 12 +++
> > > > drivers/misc/Makefile | 1 +
> > > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > > drivers/of/platform.c | 1 +
> > > > 4 files changed, 202 insertions(+)
> > > > create mode 100644 drivers/misc/open-dice.c
> > > >
> > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > > --- /dev/null
> > > > +++ b/drivers/misc/open-dice.c
> > > > @@ -0,0 +1,188 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * Copyright (C) 2021 - Google LLC
> > > > + * Author: David Brazdil <[email protected]>
> > > > + *
> > > > + * Driver for Open Profile for DICE.
> > > > + *
> > > > + * This driver takes ownership of a reserved memory region containing data
> > > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > > + *
> > > > + * Userspace can access the data with (w/o error handling):
> > > > + *
> > > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > > + * read(fd, &size, sizeof(unsigned long));
> > > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > > + * write(fd, NULL, 0); // wipe
> > > > + * close(fd);
> > > > + */
> > > > +
> > > > +#include <linux/io.h>
> > > > +#include <linux/miscdevice.h>
> > > > +#include <linux/mm.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of_reserved_mem.h>
> > > > +#include <linux/platform_device.h>
> > > > +
> > > > +#define DRIVER_NAME "open-dice"
> > > > +
> > > > +struct open_dice_drvdata {
> > > > + spinlock_t lock;
> > > > + char name[16];
> > > > + struct reserved_mem *rmem;
> > > > + struct miscdevice misc;
> > > > +};
> > > > +
> > > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > > +{
> > > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > > +}
> > > > +
> > > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > > +{
> > > > + void *kaddr;
> > > > +
> > > > + spin_lock(&drvdata->lock);
> > > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > > + drvdata->rmem->size, MEMREMAP_WC);
> > > > + if (IS_ERR(kaddr)) {
> > > > + spin_unlock(&drvdata->lock);
> > > > + return PTR_ERR(kaddr);
> > > > + }
> > > > +
> > > > + memset(kaddr, 0, drvdata->rmem->size);
> > > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > > + spin_unlock(&drvdata->lock);
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > > + */
> > > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > > + loff_t *off)
> > > > +{
> > > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > >
> > > There's a UAF issue here (and in all file operations that call
> > > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > > while userspace has an instance of the misc device open: after open_dice_remove
> > > is called, all managed resources are freed (which includes this
> > > open_dice_drvdata allocation).
> > >
> > > No new miscdev files can be created, but the existing ones continue to exist
> > > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > > from userspace will lead to dereferencing this dangling pointer.
> >
> > Please correct me if I'm wrong, but I don't think this can happen
> > without tainting the kernel.
> >
> > To call open_dice_remove, we have to remove the module. And any process
> > holding an FD of the misc device will increase the module's refcounter,
> > which is zero-checked in SYS_delete_module. The only way to get past
> > that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> > which changes the implementation of try_force_unload (kernel/module.c)
> > and adds taint. Otherwise SYS_delete_module returns an error.
> >
> > Unless there is another way how to trigger this situation, I think the
> > existing protection is sufficient. The user cannot force the removal of
> > the module without agreeing to the consequences.
>
> You can remove the driver from the device by writing to the "unbind"
> file in sysfs for this driver.
>
> Otherwise, yes, you are correct, you can not remove the module from the
> system if the file is open, but that does not prevent the driver from
> being unbound from the device.
>
> Yes, it is rare, and only able to be done by root, and even then is
> something that many drivers fail at. But for new ones, when we notice
> it, it should be fixed up before merging just to prevent any future
> problems.
Ah, I see. I'd opt for just setting 'suppress_bind_attrs=true' to
prevent that, unless you think unbinding needs to be supported. I don't
see a use for that on our side and would prefer to keep the code simple.
>
> > > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > > +}
> > >
> > > Is there a reason for mapping this memory instead of, say, copying it to
> > > userspace via read?
> >
> > The data should be treated as secret, so the idea is that avoiding
> > reading it in the kernel means we don't need to worry about it leakage
> > via the stack, etc. The reason for this is that the DICE derivation
> > chain may continue in userspace, so we want to minimize the chance of
> > a child process getting the parent secret from the kernel.
>
> The kernel stack is already secret, this should not be an issue. And
> even then, you can always erase it before the call returns to ensure
> that it does not stick around, like many crypto functions do.
I can rewrite it and memzero_explicit the memory if you or Wedson feel
strongly about this, but I actually really like mmap() because it avoids
the need for dealing with that.
David
On Thu, Jan 06, 2022 at 05:07:43PM +0000, David Brazdil wrote:
> Hi Greg,
>
> On Thu, Jan 06, 2022 at 12:29:15PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> > > Hi Wedson,
> > >
> > > On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > > > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > > > Cc: Will Deacon <[email protected]>
> > > > > Signed-off-by: David Brazdil <[email protected]>
> > > > > ---
> > > > > drivers/misc/Kconfig | 12 +++
> > > > > drivers/misc/Makefile | 1 +
> > > > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > > > drivers/of/platform.c | 1 +
> > > > > 4 files changed, 202 insertions(+)
> > > > > create mode 100644 drivers/misc/open-dice.c
> > > > >
> > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > > > --- /dev/null
> > > > > +++ b/drivers/misc/open-dice.c
> > > > > @@ -0,0 +1,188 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > +/*
> > > > > + * Copyright (C) 2021 - Google LLC
> > > > > + * Author: David Brazdil <[email protected]>
> > > > > + *
> > > > > + * Driver for Open Profile for DICE.
> > > > > + *
> > > > > + * This driver takes ownership of a reserved memory region containing data
> > > > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > > > + *
> > > > > + * Userspace can access the data with (w/o error handling):
> > > > > + *
> > > > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > > > + * read(fd, &size, sizeof(unsigned long));
> > > > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > > > + * write(fd, NULL, 0); // wipe
> > > > > + * close(fd);
> > > > > + */
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/miscdevice.h>
> > > > > +#include <linux/mm.h>
> > > > > +#include <linux/module.h>
> > > > > +#include <linux/of_reserved_mem.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +
> > > > > +#define DRIVER_NAME "open-dice"
> > > > > +
> > > > > +struct open_dice_drvdata {
> > > > > + spinlock_t lock;
> > > > > + char name[16];
> > > > > + struct reserved_mem *rmem;
> > > > > + struct miscdevice misc;
> > > > > +};
> > > > > +
> > > > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > > > +{
> > > > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > > > +}
> > > > > +
> > > > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > > > +{
> > > > > + void *kaddr;
> > > > > +
> > > > > + spin_lock(&drvdata->lock);
> > > > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > > > + drvdata->rmem->size, MEMREMAP_WC);
> > > > > + if (IS_ERR(kaddr)) {
> > > > > + spin_unlock(&drvdata->lock);
> > > > > + return PTR_ERR(kaddr);
> > > > > + }
> > > > > +
> > > > > + memset(kaddr, 0, drvdata->rmem->size);
> > > > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > > > + spin_unlock(&drvdata->lock);
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > > > + */
> > > > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > > > + loff_t *off)
> > > > > +{
> > > > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > > >
> > > > There's a UAF issue here (and in all file operations that call
> > > > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > > > while userspace has an instance of the misc device open: after open_dice_remove
> > > > is called, all managed resources are freed (which includes this
> > > > open_dice_drvdata allocation).
> > > >
> > > > No new miscdev files can be created, but the existing ones continue to exist
> > > > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > > > from userspace will lead to dereferencing this dangling pointer.
> > >
> > > Please correct me if I'm wrong, but I don't think this can happen
> > > without tainting the kernel.
> > >
> > > To call open_dice_remove, we have to remove the module. And any process
> > > holding an FD of the misc device will increase the module's refcounter,
> > > which is zero-checked in SYS_delete_module. The only way to get past
> > > that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> > > which changes the implementation of try_force_unload (kernel/module.c)
> > > and adds taint. Otherwise SYS_delete_module returns an error.
> > >
> > > Unless there is another way how to trigger this situation, I think the
> > > existing protection is sufficient. The user cannot force the removal of
> > > the module without agreeing to the consequences.
> >
> > You can remove the driver from the device by writing to the "unbind"
> > file in sysfs for this driver.
> >
> > Otherwise, yes, you are correct, you can not remove the module from the
> > system if the file is open, but that does not prevent the driver from
> > being unbound from the device.
> >
> > Yes, it is rare, and only able to be done by root, and even then is
> > something that many drivers fail at. But for new ones, when we notice
> > it, it should be fixed up before merging just to prevent any future
> > problems.
>
> Ah, I see. I'd opt for just setting 'suppress_bind_attrs=true' to
> prevent that, unless you think unbinding needs to be supported. I don't
> see a use for that on our side and would prefer to keep the code simple.
No objection from me, that solves it easily :)
> > > > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > > > +}
> > > >
> > > > Is there a reason for mapping this memory instead of, say, copying it to
> > > > userspace via read?
> > >
> > > The data should be treated as secret, so the idea is that avoiding
> > > reading it in the kernel means we don't need to worry about it leakage
> > > via the stack, etc. The reason for this is that the DICE derivation
> > > chain may continue in userspace, so we want to minimize the chance of
> > > a child process getting the parent secret from the kernel.
> >
> > The kernel stack is already secret, this should not be an issue. And
> > even then, you can always erase it before the call returns to ensure
> > that it does not stick around, like many crypto functions do.
>
> I can rewrite it and memzero_explicit the memory if you or Wedson feel
> strongly about this, but I actually really like mmap() because it avoids
> the need for dealing with that.
I think if we remove the ability for userspace to unbind the device from
the driver with the file handle open like above, all should be ok to
keep this as a mmap thing.
Wedson, any objection?
David, I pointed Wedson as this driver as an example of maybe something
that might be possible to write in Rust instead, which is why he looked
at it. I don't recommend doing that just now, but we are feeling out
what types of drivers would be good examples in that language.
thanks,
greg k-h
On Thu, Jan 06, 2022 at 06:24:45PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 06, 2022 at 05:07:43PM +0000, David Brazdil wrote:
> > Hi Greg,
> >
> > On Thu, Jan 06, 2022 at 12:29:15PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> > > > Hi Wedson,
> > > >
> > > > On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > > > > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > > > > Cc: Will Deacon <[email protected]>
> > > > > > Signed-off-by: David Brazdil <[email protected]>
> > > > > > ---
> > > > > > drivers/misc/Kconfig | 12 +++
> > > > > > drivers/misc/Makefile | 1 +
> > > > > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > > > > drivers/of/platform.c | 1 +
> > > > > > 4 files changed, 202 insertions(+)
> > > > > > create mode 100644 drivers/misc/open-dice.c
> > > > > >
> > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/misc/open-dice.c
> > > > > > @@ -0,0 +1,188 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +/*
> > > > > > + * Copyright (C) 2021 - Google LLC
> > > > > > + * Author: David Brazdil <[email protected]>
> > > > > > + *
> > > > > > + * Driver for Open Profile for DICE.
> > > > > > + *
> > > > > > + * This driver takes ownership of a reserved memory region containing data
> > > > > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > > > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > > > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > > > > + *
> > > > > > + * Userspace can access the data with (w/o error handling):
> > > > > > + *
> > > > > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > > > > + * read(fd, &size, sizeof(unsigned long));
> > > > > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > > > > + * write(fd, NULL, 0); // wipe
> > > > > > + * close(fd);
> > > > > > + */
> > > > > > +
> > > > > > +#include <linux/io.h>
> > > > > > +#include <linux/miscdevice.h>
> > > > > > +#include <linux/mm.h>
> > > > > > +#include <linux/module.h>
> > > > > > +#include <linux/of_reserved_mem.h>
> > > > > > +#include <linux/platform_device.h>
> > > > > > +
> > > > > > +#define DRIVER_NAME "open-dice"
> > > > > > +
> > > > > > +struct open_dice_drvdata {
> > > > > > + spinlock_t lock;
> > > > > > + char name[16];
> > > > > > + struct reserved_mem *rmem;
> > > > > > + struct miscdevice misc;
> > > > > > +};
> > > > > > +
> > > > > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > > > > +{
> > > > > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > > > > +}
> > > > > > +
> > > > > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > > > > +{
> > > > > > + void *kaddr;
> > > > > > +
> > > > > > + spin_lock(&drvdata->lock);
> > > > > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > > > > + drvdata->rmem->size, MEMREMAP_WC);
> > > > > > + if (IS_ERR(kaddr)) {
> > > > > > + spin_unlock(&drvdata->lock);
> > > > > > + return PTR_ERR(kaddr);
> > > > > > + }
> > > > > > +
> > > > > > + memset(kaddr, 0, drvdata->rmem->size);
> > > > > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > > > > + spin_unlock(&drvdata->lock);
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > > > > + */
> > > > > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > > > > + loff_t *off)
> > > > > > +{
> > > > > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > > > >
> > > > > There's a UAF issue here (and in all file operations that call
> > > > > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > > > > while userspace has an instance of the misc device open: after open_dice_remove
> > > > > is called, all managed resources are freed (which includes this
> > > > > open_dice_drvdata allocation).
> > > > >
> > > > > No new miscdev files can be created, but the existing ones continue to exist
> > > > > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > > > > from userspace will lead to dereferencing this dangling pointer.
> > > >
> > > > Please correct me if I'm wrong, but I don't think this can happen
> > > > without tainting the kernel.
> > > >
> > > > To call open_dice_remove, we have to remove the module. And any process
> > > > holding an FD of the misc device will increase the module's refcounter,
> > > > which is zero-checked in SYS_delete_module. The only way to get past
> > > > that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> > > > which changes the implementation of try_force_unload (kernel/module.c)
> > > > and adds taint. Otherwise SYS_delete_module returns an error.
> > > >
> > > > Unless there is another way how to trigger this situation, I think the
> > > > existing protection is sufficient. The user cannot force the removal of
> > > > the module without agreeing to the consequences.
> > >
> > > You can remove the driver from the device by writing to the "unbind"
> > > file in sysfs for this driver.
> > >
> > > Otherwise, yes, you are correct, you can not remove the module from the
> > > system if the file is open, but that does not prevent the driver from
> > > being unbound from the device.
> > >
> > > Yes, it is rare, and only able to be done by root, and even then is
> > > something that many drivers fail at. But for new ones, when we notice
> > > it, it should be fixed up before merging just to prevent any future
> > > problems.
> >
> > Ah, I see. I'd opt for just setting 'suppress_bind_attrs=true' to
> > prevent that, unless you think unbinding needs to be supported. I don't
> > see a use for that on our side and would prefer to keep the code simple.
>
> No objection from me, that solves it easily :)
>
> > > > > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > > > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > > > > +}
> > > > >
> > > > > Is there a reason for mapping this memory instead of, say, copying it to
> > > > > userspace via read?
> > > >
> > > > The data should be treated as secret, so the idea is that avoiding
> > > > reading it in the kernel means we don't need to worry about it leakage
> > > > via the stack, etc. The reason for this is that the DICE derivation
> > > > chain may continue in userspace, so we want to minimize the chance of
> > > > a child process getting the parent secret from the kernel.
> > >
> > > The kernel stack is already secret, this should not be an issue. And
> > > even then, you can always erase it before the call returns to ensure
> > > that it does not stick around, like many crypto functions do.
> >
> > I can rewrite it and memzero_explicit the memory if you or Wedson feel
> > strongly about this, but I actually really like mmap() because it avoids
> > the need for dealing with that.
>
> I think if we remove the ability for userspace to unbind the device from
> the driver with the file handle open like above, all should be ok to
> keep this as a mmap thing.
>
> Wedson, any objection?
>
> David, I pointed Wedson as this driver as an example of maybe something
> that might be possible to write in Rust instead, which is why he looked
> at it. I don't recommend doing that just now, but we are feeling out
> what types of drivers would be good examples in that language.
Wedson already reached out to me about that. 100% agree that this is a
good candidate and happy to help test it if needed. Thanks for making
the connection, Greg.
On Thu, Jan 06, 2022 at 06:24:45PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 06, 2022 at 05:07:43PM +0000, David Brazdil wrote:
> > Hi Greg,
> >
> > On Thu, Jan 06, 2022 at 12:29:15PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> > > > Hi Wedson,
> > > >
> > > > On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > > > > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > > > > Cc: Will Deacon <[email protected]>
> > > > > > Signed-off-by: David Brazdil <[email protected]>
> > > > > > ---
> > > > > > drivers/misc/Kconfig | 12 +++
> > > > > > drivers/misc/Makefile | 1 +
> > > > > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > > > > drivers/of/platform.c | 1 +
> > > > > > 4 files changed, 202 insertions(+)
> > > > > > create mode 100644 drivers/misc/open-dice.c
> > > > > >
> > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/misc/open-dice.c
> > > > > > @@ -0,0 +1,188 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +/*
> > > > > > + * Copyright (C) 2021 - Google LLC
> > > > > > + * Author: David Brazdil <[email protected]>
> > > > > > + *
> > > > > > + * Driver for Open Profile for DICE.
> > > > > > + *
> > > > > > + * This driver takes ownership of a reserved memory region containing data
> > > > > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > > > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > > > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > > > > + *
> > > > > > + * Userspace can access the data with (w/o error handling):
> > > > > > + *
> > > > > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > > > > + * read(fd, &size, sizeof(unsigned long));
> > > > > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > > > > + * write(fd, NULL, 0); // wipe
> > > > > > + * close(fd);
> > > > > > + */
> > > > > > +
> > > > > > +#include <linux/io.h>
> > > > > > +#include <linux/miscdevice.h>
> > > > > > +#include <linux/mm.h>
> > > > > > +#include <linux/module.h>
> > > > > > +#include <linux/of_reserved_mem.h>
> > > > > > +#include <linux/platform_device.h>
> > > > > > +
> > > > > > +#define DRIVER_NAME "open-dice"
> > > > > > +
> > > > > > +struct open_dice_drvdata {
> > > > > > + spinlock_t lock;
> > > > > > + char name[16];
> > > > > > + struct reserved_mem *rmem;
> > > > > > + struct miscdevice misc;
> > > > > > +};
> > > > > > +
> > > > > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > > > > +{
> > > > > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > > > > +}
> > > > > > +
> > > > > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > > > > +{
> > > > > > + void *kaddr;
> > > > > > +
> > > > > > + spin_lock(&drvdata->lock);
> > > > > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > > > > + drvdata->rmem->size, MEMREMAP_WC);
> > > > > > + if (IS_ERR(kaddr)) {
> > > > > > + spin_unlock(&drvdata->lock);
> > > > > > + return PTR_ERR(kaddr);
> > > > > > + }
> > > > > > +
> > > > > > + memset(kaddr, 0, drvdata->rmem->size);
> > > > > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > > > > + spin_unlock(&drvdata->lock);
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > > > > + */
> > > > > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > > > > + loff_t *off)
> > > > > > +{
> > > > > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > > > >
> > > > > There's a UAF issue here (and in all file operations that call
> > > > > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > > > > while userspace has an instance of the misc device open: after open_dice_remove
> > > > > is called, all managed resources are freed (which includes this
> > > > > open_dice_drvdata allocation).
> > > > >
> > > > > No new miscdev files can be created, but the existing ones continue to exist
> > > > > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > > > > from userspace will lead to dereferencing this dangling pointer.
> > > >
> > > > Please correct me if I'm wrong, but I don't think this can happen
> > > > without tainting the kernel.
> > > >
> > > > To call open_dice_remove, we have to remove the module. And any process
> > > > holding an FD of the misc device will increase the module's refcounter,
> > > > which is zero-checked in SYS_delete_module. The only way to get past
> > > > that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> > > > which changes the implementation of try_force_unload (kernel/module.c)
> > > > and adds taint. Otherwise SYS_delete_module returns an error.
> > > >
> > > > Unless there is another way how to trigger this situation, I think the
> > > > existing protection is sufficient. The user cannot force the removal of
> > > > the module without agreeing to the consequences.
> > >
> > > You can remove the driver from the device by writing to the "unbind"
> > > file in sysfs for this driver.
> > >
> > > Otherwise, yes, you are correct, you can not remove the module from the
> > > system if the file is open, but that does not prevent the driver from
> > > being unbound from the device.
> > >
> > > Yes, it is rare, and only able to be done by root, and even then is
> > > something that many drivers fail at. But for new ones, when we notice
> > > it, it should be fixed up before merging just to prevent any future
> > > problems.
> >
> > Ah, I see. I'd opt for just setting 'suppress_bind_attrs=true' to
> > prevent that, unless you think unbinding needs to be supported. I don't
> > see a use for that on our side and would prefer to keep the code simple.
>
> No objection from me, that solves it easily :)
>
> > > > > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > > > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > > > > +}
> > > > >
> > > > > Is there a reason for mapping this memory instead of, say, copying it to
> > > > > userspace via read?
> > > >
> > > > The data should be treated as secret, so the idea is that avoiding
> > > > reading it in the kernel means we don't need to worry about it leakage
> > > > via the stack, etc. The reason for this is that the DICE derivation
> > > > chain may continue in userspace, so we want to minimize the chance of
> > > > a child process getting the parent secret from the kernel.
> > >
> > > The kernel stack is already secret, this should not be an issue. And
> > > even then, you can always erase it before the call returns to ensure
> > > that it does not stick around, like many crypto functions do.
> >
> > I can rewrite it and memzero_explicit the memory if you or Wedson feel
> > strongly about this, but I actually really like mmap() because it avoids
> > the need for dealing with that.
>
> I think if we remove the ability for userspace to unbind the device from
> the driver with the file handle open like above, all should be ok to
> keep this as a mmap thing.
>
> Wedson, any objection?
No object from me, I like simplicity!
For maintainability, I think it would be a good idea to leave a comment when
setting suppress_bind_attrs to true that indicates that if one wants to change
it to false in the future, one must ensure that mappings are torn down and
lifetime issues with drvdata are addressed after unbind.
Cheers,
-Wedson
On Fri, Jan 07, 2022 at 12:04:39AM +0000, Wedson Almeida Filho wrote:
> On Thu, Jan 06, 2022 at 06:24:45PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 06, 2022 at 05:07:43PM +0000, David Brazdil wrote:
> > > Hi Greg,
> > >
> > > On Thu, Jan 06, 2022 at 12:29:15PM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Jan 06, 2022 at 10:50:41AM +0000, David Brazdil wrote:
> > > > > Hi Wedson,
> > > > >
> > > > > On Wed, Jan 05, 2022 at 04:52:51PM +0000, Wedson Almeida Filho wrote:
> > > > > > On Tue, Dec 21, 2021 at 05:45:02PM +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 <[email protected]>
> > > > > > > Cc: Will Deacon <[email protected]>
> > > > > > > Signed-off-by: David Brazdil <[email protected]>
> > > > > > > ---
> > > > > > > drivers/misc/Kconfig | 12 +++
> > > > > > > drivers/misc/Makefile | 1 +
> > > > > > > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > > > > > > drivers/of/platform.c | 1 +
> > > > > > > 4 files changed, 202 insertions(+)
> > > > > > > create mode 100644 drivers/misc/open-dice.c
> > > > > > >
> > > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > > > index 0f5a49fc7c9e..a2b26426efba 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 use 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..f1819f951173
> > > > > > > --- /dev/null
> > > > > > > +++ b/drivers/misc/open-dice.c
> > > > > > > @@ -0,0 +1,188 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > +/*
> > > > > > > + * Copyright (C) 2021 - Google LLC
> > > > > > > + * Author: David Brazdil <[email protected]>
> > > > > > > + *
> > > > > > > + * Driver for Open Profile for DICE.
> > > > > > > + *
> > > > > > > + * This driver takes ownership of a reserved memory region containing data
> > > > > > > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > > > > > > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > > > > > > + * process via a misc device. Userspace can also request a wipe of the memory.
> > > > > > > + *
> > > > > > > + * Userspace can access the data with (w/o error handling):
> > > > > > > + *
> > > > > > > + * fd = open("/dev/open-dice0", O_RDWR);
> > > > > > > + * read(fd, &size, sizeof(unsigned long));
> > > > > > > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > > > > > + * write(fd, NULL, 0); // wipe
> > > > > > > + * close(fd);
> > > > > > > + */
> > > > > > > +
> > > > > > > +#include <linux/io.h>
> > > > > > > +#include <linux/miscdevice.h>
> > > > > > > +#include <linux/mm.h>
> > > > > > > +#include <linux/module.h>
> > > > > > > +#include <linux/of_reserved_mem.h>
> > > > > > > +#include <linux/platform_device.h>
> > > > > > > +
> > > > > > > +#define DRIVER_NAME "open-dice"
> > > > > > > +
> > > > > > > +struct open_dice_drvdata {
> > > > > > > + spinlock_t lock;
> > > > > > > + char name[16];
> > > > > > > + struct reserved_mem *rmem;
> > > > > > > + struct miscdevice misc;
> > > > > > > +};
> > > > > > > +
> > > > > > > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > > > > > > +{
> > > > > > > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > > > > > > +{
> > > > > > > + void *kaddr;
> > > > > > > +
> > > > > > > + spin_lock(&drvdata->lock);
> > > > > > > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > > > > > > + drvdata->rmem->size, MEMREMAP_WC);
> > > > > > > + if (IS_ERR(kaddr)) {
> > > > > > > + spin_unlock(&drvdata->lock);
> > > > > > > + return PTR_ERR(kaddr);
> > > > > > > + }
> > > > > > > +
> > > > > > > + memset(kaddr, 0, drvdata->rmem->size);
> > > > > > > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > > > > > > + spin_unlock(&drvdata->lock);
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * Copies the size of the reserved memory region to the user-provided buffer.
> > > > > > > + */
> > > > > > > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > > > > > > + loff_t *off)
> > > > > > > +{
> > > > > > > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > > > > >
> > > > > > There's a UAF issue here (and in all file operations that call
> > > > > > to_open_dice_drvdata) when the platform device in unbounded from the driver
> > > > > > while userspace has an instance of the misc device open: after open_dice_remove
> > > > > > is called, all managed resources are freed (which includes this
> > > > > > open_dice_drvdata allocation).
> > > > > >
> > > > > > No new miscdev files can be created, but the existing ones continue to exist
> > > > > > with a now dangling pointer stored in private_data. So read/write/mmap syscalls
> > > > > > from userspace will lead to dereferencing this dangling pointer.
> > > > >
> > > > > Please correct me if I'm wrong, but I don't think this can happen
> > > > > without tainting the kernel.
> > > > >
> > > > > To call open_dice_remove, we have to remove the module. And any process
> > > > > holding an FD of the misc device will increase the module's refcounter,
> > > > > which is zero-checked in SYS_delete_module. The only way to get past
> > > > > that check is by compiling the kernel with CONFIG_MODULE_FORCE_UNLOAD,
> > > > > which changes the implementation of try_force_unload (kernel/module.c)
> > > > > and adds taint. Otherwise SYS_delete_module returns an error.
> > > > >
> > > > > Unless there is another way how to trigger this situation, I think the
> > > > > existing protection is sufficient. The user cannot force the removal of
> > > > > the module without agreeing to the consequences.
> > > >
> > > > You can remove the driver from the device by writing to the "unbind"
> > > > file in sysfs for this driver.
> > > >
> > > > Otherwise, yes, you are correct, you can not remove the module from the
> > > > system if the file is open, but that does not prevent the driver from
> > > > being unbound from the device.
> > > >
> > > > Yes, it is rare, and only able to be done by root, and even then is
> > > > something that many drivers fail at. But for new ones, when we notice
> > > > it, it should be fixed up before merging just to prevent any future
> > > > problems.
> > >
> > > Ah, I see. I'd opt for just setting 'suppress_bind_attrs=true' to
> > > prevent that, unless you think unbinding needs to be supported. I don't
> > > see a use for that on our side and would prefer to keep the code simple.
> >
> > No objection from me, that solves it easily :)
> >
> > > > > > > + /* Create write-combine mapping so all clients observe a wipe. */
> > > > > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > > > > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
> > > > > > > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > > > > > > +}
> > > > > >
> > > > > > Is there a reason for mapping this memory instead of, say, copying it to
> > > > > > userspace via read?
> > > > >
> > > > > The data should be treated as secret, so the idea is that avoiding
> > > > > reading it in the kernel means we don't need to worry about it leakage
> > > > > via the stack, etc. The reason for this is that the DICE derivation
> > > > > chain may continue in userspace, so we want to minimize the chance of
> > > > > a child process getting the parent secret from the kernel.
> > > >
> > > > The kernel stack is already secret, this should not be an issue. And
> > > > even then, you can always erase it before the call returns to ensure
> > > > that it does not stick around, like many crypto functions do.
> > >
> > > I can rewrite it and memzero_explicit the memory if you or Wedson feel
> > > strongly about this, but I actually really like mmap() because it avoids
> > > the need for dealing with that.
> >
> > I think if we remove the ability for userspace to unbind the device from
> > the driver with the file handle open like above, all should be ok to
> > keep this as a mmap thing.
> >
> > Wedson, any objection?
>
> No object from me, I like simplicity!
>
> For maintainability, I think it would be a good idea to leave a comment when
> setting suppress_bind_attrs to true that indicates that if one wants to change
> it to false in the future, one must ensure that mappings are torn down and
> lifetime issues with drvdata are addressed after unbind.
I was gonna add the flag but I realized it was set already. The driver
is registered with module_platform_driver_probe, which sets it in
__platform_driver_probe. The comments around/in these also state that the
device does not support bind/unbind. So I think the current
implementation should be sufficient.
NB: This thread is on v5. I posted a v6 addressing a comment from Rob a
few days ago. That's the latest version.
https://lore.kernel.org/all/[email protected]/
David