| Message ID | 20211207123617.3040177-1-dbrazdil@google.com |
|---|---|
| Headers | show |
| Series | Driver for Open Profile for DICE | expand |
On Tue, Dec 07, 2021 at 12:36:17PM +0000, David Brazdil wrote: > Open Profile for DICE is a protocol for deriving unique secrets at boot, > used by some Android devices. The firmware/bootloader hands over secrets > in a reserved memory region, this driver takes ownership of the memory > region and exposes it to userspace via a character device that > lets userspace mmap the memory region into its process. > > The character device can only be opened once at any given time. Why? That should not matter. And your code (correctly), does not check for that. So why say that here? > Userspace can issue an ioctl requesting that the memory be wiped after > the current FD is released. In that case, the driver will clear > the buffer and refuse to open any new FDs. > > Cc: Andrew Scull <ascull@google.com> > Cc: Will Deacon <will@kernel.org> > Signed-off-by: David Brazdil <dbrazdil@google.com> Some minor comments on the code: > +#include <linux/cdev.h> > +#include <linux/dice.h> > +#include <linux/io.h> > +#include <linux/mm.h> > +#include <linux/module.h> > +#include <linux/of_reserved_mem.h> > +#include <linux/platform_device.h> > + > +#define DICE_MKDEV MKDEV(MAJOR(dice_devt), 0) > +#define DICE_MINOR_COUNT 1 Please just use the misc_device api, no need to try to claim a major number for just one device node. That will simplify your code a lot as well. > +enum dice_state { > + DICE_STATE_READY = 0, > + DICE_STATE_BUSY, > + DICE_STATE_BUSY_WIPE_ON_CLOSE, > + DICE_STATE_WIPED, > +}; > + > +struct dice_data { > + struct device *dev; What is this for? The parent? If so, say parent :) > + struct cdev cdev; > + atomic_t state; > + phys_addr_t base; > + size_t size; > +}; > + > +static dev_t dice_devt; > +static struct class *dice_class; > + > +static int dice_open(struct inode *inode, struct file *filp) > +{ > + struct dice_data *data; > + > + data = container_of(inode->i_cdev, struct dice_data, cdev); > + > + /* Never allow write access. */ > + if (filp->f_mode & FMODE_WRITE) > + return -EROFS; Why do you care? Writes just will not work anyway, right? > + > + switch (atomic_cmpxchg(&data->state, DICE_STATE_READY, DICE_STATE_BUSY)) { > + case DICE_STATE_READY: > + break; > + case DICE_STATE_WIPED: > + /* Return error to inform caller memory has been wiped. */ > + return -EACCES; > + default: > + return -EBUSY; > + } > + > + filp->private_data = data; > + nonseekable_open(inode, filp); > + return 0; > +} > + > +static int dice_release(struct inode *inode, struct file *filp) > +{ > + struct dice_data *data = filp->private_data; > + void *base; > + > + if (atomic_read(&data->state) == DICE_STATE_BUSY_WIPE_ON_CLOSE) { > + base = devm_memremap(data->dev, data->base, data->size, MEMREMAP_WT); > + if (!WARN_ON(!base)) { > + memzero_explicit(base, data->size); > + devm_memunmap(data->dev, base); > + } > + atomic_set(&data->state, DICE_STATE_WIPED); > + return 0; > + } > + > + atomic_set(&data->state, DICE_STATE_READY); > + return 0; > +} > + > +static int dice_mmap(struct file *filp, struct vm_area_struct *vma) > +{ > + struct dice_data *data = filp->private_data; > + > + vma->vm_flags |= VM_DONTCOPY; > + return vm_iomap_memory(vma, data->base, data->size); > +} > + > +static long dice_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) > +{ > + struct dice_data *data = filp->private_data; > + > + switch (cmd) { > + case DICE_GET_SIZE: > + /* Checked against INT_MAX in dice_probe(). */ > + return data->size; > + case DICE_SET_WIPE_ON_CLOSE: > + atomic_set(&data->state, DICE_STATE_BUSY_WIPE_ON_CLOSE); > + return 0; > + } > + > + return -EINVAL; Wrong error value for invalid ioctl. And why do these have to be ioctls at all? I guess sysfs could be used, but if you are comfortable with ioctls, that's fine. > +} > + > +static const struct file_operations dice_fops = { > + .open = dice_open, > + .release = dice_release, > + .mmap = dice_mmap, > + .unlocked_ioctl = dice_ioctl, > + .llseek = no_llseek, > +}; > + > +static int __init dice_probe(struct platform_device *pdev) > +{ > + struct device *chr_dev, *dev = &pdev->dev; > + struct device_node *rmem_np; > + struct reserved_mem *rmem; > + struct dice_data *data; > + int ret; > + > + rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0); > + if (!rmem_np) { > + dev_err(dev, "missing 'memory-region' property\n"); > + return -EINVAL; > + } > + > + rmem = of_reserved_mem_lookup(rmem_np); > + of_node_put(rmem_np); > + if (!rmem) { > + dev_err(dev, "failed to lookup reserved memory\n"); > + return -EINVAL; > + } > + > + if (!PAGE_ALIGNED(rmem->base) || !PAGE_ALIGNED(rmem->size)) { > + dev_err(dev, "memory region must be page-aligned\n"); > + return -EINVAL; > + } > + > + if (rmem->size > INT_MAX) { > + dev_err(dev, "memory region too large\n"); > + return -EINVAL; > + } > + > + data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; > + > + *data = (struct dice_data){ > + .dev = dev, > + .base = rmem->base, > + .size = rmem->size, > + .state = ATOMIC_INIT(DICE_STATE_READY), > + }; > + > + cdev_init(&data->cdev, &dice_fops); Again a misc device will make this much simpler. > + data->cdev.owner = THIS_MODULE; > + ret = cdev_add(&data->cdev, DICE_MKDEV, 1); > + if (ret) > + return ret; > + > + chr_dev = device_create(dice_class, dev, DICE_MKDEV, NULL, "dice"); > + if (IS_ERR(chr_dev)) { > + cdev_del(&data->cdev); > + return PTR_ERR(chr_dev); > + } > + > + platform_set_drvdata(pdev, data); > + return 0; > +} > + > +static int dice_remove(struct platform_device *pdev) > +{ > + struct dice_data *data = platform_get_drvdata(pdev); > + > + cdev_del(&data->cdev); > + device_destroy(dice_class, DICE_MKDEV); > + return 0; > +} > + > +static char *dice_devnode(struct device *dev, umode_t *mode) > +{ > + /* Initial permissions: read-only by owner */ > + if (mode) > + *mode = 0400; > + return NULL; Put the mode in the misc device structure please. > +} > + > +static const struct of_device_id dice_of_match[] = { > + { .compatible = "google,dice" }, > + {}, > +}; > + > +static struct platform_driver dice_driver = { > + .remove = dice_remove, > + .driver = { > + .name = "dice", > + .of_match_table = dice_of_match, > + }, > +}; > + > +static int __init dice_init(void) > +{ > + int ret; > + > + ret = alloc_chrdev_region(&dice_devt, 0, DICE_MINOR_COUNT, "dice"); > + if (ret) > + return ret; > + > + dice_class = class_create(THIS_MODULE, "dice"); > + if (IS_ERR(dice_class)) { > + ret = PTR_ERR(dice_class); > + goto fail; > + } > + dice_class->devnode = dice_devnode; Never create a class and reserve things like this, if you do not even know if your hardware is present or not. That just wastes resources. Only allocate it if your device probes properly. And again, moving to a misc_device makes this all much simpler and your whole init function can go away. thanks, greg k-h
Hi Greg, On Tue, Dec 07, 2021 at 02:08:17PM +0100, Greg Kroah-Hartman wrote: > On Tue, Dec 07, 2021 at 12:36:17PM +0000, David Brazdil wrote: > > Open Profile for DICE is a protocol for deriving unique secrets at boot, > > used by some Android devices. The firmware/bootloader hands over secrets > > in a reserved memory region, this driver takes ownership of the memory > > region and exposes it to userspace via a character device that > > lets userspace mmap the memory region into its process. > > > > The character device can only be opened once at any given time. > > Why? That should not matter. And your code (correctly), does not check > for that. So why say that here? It does check - open() returns -EBUSY if cmpxchg of the state from READY to BUSY fails. I agree this is a bit unconventional but it makes things easier to reason about. With multiple open FDs the driver would have to wait for all of them to get released before wiping, so one user could block the wiping requested by others by holding the FD indefinitely. And wiping despite other open FDs seems wrong, too. Is there a better way of doing this? > > +#include <linux/cdev.h> > > +#include <linux/dice.h> > > +#include <linux/io.h> > > +#include <linux/mm.h> > > +#include <linux/module.h> > > +#include <linux/of_reserved_mem.h> > > +#include <linux/platform_device.h> > > + > > +#define DICE_MKDEV MKDEV(MAJOR(dice_devt), 0) > > +#define DICE_MINOR_COUNT 1 > > Please just use the misc_device api, no need to try to claim a major > number for just one device node. That will simplify your code a lot as > well. Ok, I'll look into it. > > +static int dice_open(struct inode *inode, struct file *filp) > > +{ > > + struct dice_data *data; > > + > > + data = container_of(inode->i_cdev, struct dice_data, cdev); > > + > > + /* Never allow write access. */ > > + if (filp->f_mode & FMODE_WRITE) > > + return -EROFS; > > Why do you care? Writes just will not work anyway, right? There is nothing else preventing writes, the reserved memory is just plain old RAM. Thanks, David
On Tue, Dec 07, 2021 at 04:44:18PM +0000, David Brazdil wrote: > Hi Greg, > > On Tue, Dec 07, 2021 at 02:08:17PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Dec 07, 2021 at 12:36:17PM +0000, David Brazdil wrote: > > > Open Profile for DICE is a protocol for deriving unique secrets at boot, > > > used by some Android devices. The firmware/bootloader hands over secrets > > > in a reserved memory region, this driver takes ownership of the memory > > > region and exposes it to userspace via a character device that > > > lets userspace mmap the memory region into its process. > > > > > > The character device can only be opened once at any given time. > > > > Why? That should not matter. And your code (correctly), does not check > > for that. So why say that here? > > It does check - open() returns -EBUSY if cmpxchg of the state from READY > to BUSY fails. I agree this is a bit unconventional but it makes things > easier to reason about. With multiple open FDs the driver would have to > wait for all of them to get released before wiping, so one user could > block the wiping requested by others by holding the FD indefinitely. > And wiping despite other open FDs seems wrong, too. Is there a better > way of doing this? Yes, totally ignore it from the kernel point of view. You don't know what userspace just did with that FD the kernel gave it, it could have sent it across a pipe, run dup() on it, or any sort of other things. Just rely on open/release to know when the device is opened, and then when that instance is released. If userspace wants to do looney things, and oddities happen, that's userspace's problem, not yours :) > > > +#include <linux/cdev.h> > > > +#include <linux/dice.h> > > > +#include <linux/io.h> > > > +#include <linux/mm.h> > > > +#include <linux/module.h> > > > +#include <linux/of_reserved_mem.h> > > > +#include <linux/platform_device.h> > > > + > > > +#define DICE_MKDEV MKDEV(MAJOR(dice_devt), 0) > > > +#define DICE_MINOR_COUNT 1 > > > > Please just use the misc_device api, no need to try to claim a major > > number for just one device node. That will simplify your code a lot as > > well. > > Ok, I'll look into it. > > > > +static int dice_open(struct inode *inode, struct file *filp) > > > +{ > > > + struct dice_data *data; > > > + > > > + data = container_of(inode->i_cdev, struct dice_data, cdev); > > > + > > > + /* Never allow write access. */ > > > + if (filp->f_mode & FMODE_WRITE) > > > + return -EROFS; > > > > Why do you care? Writes just will not work anyway, right? > > There is nothing else preventing writes, the reserved memory is just plain > old RAM. And you can rely on this check only? Nothing else needed with mmap? And why can't userspace write to this? What's wrong with that happening? thanks, greg k-h
On Tue, Dec 07, 2021 at 06:16:17PM +0100, Greg Kroah-Hartman wrote: > On Tue, Dec 07, 2021 at 04:44:18PM +0000, David Brazdil wrote: > > Hi Greg, > > > > On Tue, Dec 07, 2021 at 02:08:17PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Dec 07, 2021 at 12:36:17PM +0000, David Brazdil wrote: > > > > Open Profile for DICE is a protocol for deriving unique secrets at boot, > > > > used by some Android devices. The firmware/bootloader hands over secrets > > > > in a reserved memory region, this driver takes ownership of the memory > > > > region and exposes it to userspace via a character device that > > > > lets userspace mmap the memory region into its process. > > > > > > > > The character device can only be opened once at any given time. > > > > > > Why? That should not matter. And your code (correctly), does not check > > > for that. So why say that here? > > > > It does check - open() returns -EBUSY if cmpxchg of the state from READY > > to BUSY fails. I agree this is a bit unconventional but it makes things > > easier to reason about. With multiple open FDs the driver would have to > > wait for all of them to get released before wiping, so one user could > > block the wiping requested by others by holding the FD indefinitely. > > And wiping despite other open FDs seems wrong, too. Is there a better > > way of doing this? > > Yes, totally ignore it from the kernel point of view. You don't know > what userspace just did with that FD the kernel gave it, it could have > sent it across a pipe, run dup() on it, or any sort of other things. > Just rely on open/release to know when the device is opened, and then > when that instance is released. If userspace wants to do looney things, > and oddities happen, that's userspace's problem, not yours :) > Fair point. > > > > +#include <linux/cdev.h> > > > > +#include <linux/dice.h> > > > > +#include <linux/io.h> > > > > +#include <linux/mm.h> > > > > +#include <linux/module.h> > > > > +#include <linux/of_reserved_mem.h> > > > > +#include <linux/platform_device.h> > > > > + > > > > +#define DICE_MKDEV MKDEV(MAJOR(dice_devt), 0) > > > > +#define DICE_MINOR_COUNT 1 > > > > > > Please just use the misc_device api, no need to try to claim a major > > > number for just one device node. That will simplify your code a lot as > > > well. > > > > Ok, I'll look into it. > > > > > > +static int dice_open(struct inode *inode, struct file *filp) > > > > +{ > > > > + struct dice_data *data; > > > > + > > > > + data = container_of(inode->i_cdev, struct dice_data, cdev); > > > > + > > > > + /* Never allow write access. */ > > > > + if (filp->f_mode & FMODE_WRITE) > > > > + return -EROFS; > > > > > > Why do you care? Writes just will not work anyway, right? > > > > There is nothing else preventing writes, the reserved memory is just plain > > old RAM. > > And you can rely on this check only? Nothing else needed with mmap? > And why can't userspace write to this? What's wrong with that > happening? AFAICT vm_iomap_memory takes care of it. It will allow a MAP_PRIVATE mapping of a read-only FD but not a MAP_SHARED one. I think that gives nice guarantees to userspace that if a process opens the char device itself, it's getting the original data, not something another process wrote there. -David