linux-kernel - Re: [PATCH 2/2] misc: dice: Add driver to forward secrets to userspace

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

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

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

Message-ID: <Ya+PYiP43YxfLS4x@google.com>
Date:   Tue, 7 Dec 2021 16:44:18 +0000
From:   David Brazdil <dbrazdil@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Rob Herring <robh+dt@...nel.org>, Jonathan Corbet <corbet@....net>,
        Derek Kiernan <derek.kiernan@...inx.com>,
        Dragan Cvetic <dragan.cvetic@...inx.com>,
        Arnd Bergmann <arnd@...db.de>,
        Hans de Goede <hdegoede@...hat.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, Andrew Scull <ascull@...gle.com>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH 2/2] misc: dice: Add driver to forward secrets to
 userspace

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