linux-kernel - Re: [PATCH v2 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: <YbN2tbYZyLBdyEfS@google.com>
Date:   Fri, 10 Dec 2021 15:48:05 +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 v2 2/2] misc: dice: Add driver to forward secrets to
 userspace

In your first email you also mentioned removing the check in dice_probe()
that only allows a single instance. On a second thought, I think it's
simpler to keep it there for now, even if the memory is dynamically
allocated, which I agree makes the code cleaner.
The reason being that if we allowed multiple instances, we'd also need
some static unique identifier that ties the cdev filename to the DT entry,
same as /dev/disk/by-uuid/. Just adding an index number to the misc
device nodename based on DT probe order sounds very fragile, and
anything more sophisticated sounds like too much trouble for something
we don't have a clear use case for right now.

On Fri, Dec 10, 2021 at 03:39:44PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 10, 2021 at 11:16:06AM +0000, David Brazdil wrote:
> > On Thu, Dec 09, 2021 at 04:31:53PM +0100, Greg Kroah-Hartman wrote:
> > > What is the module name, please add that here.
> > > 
> > > And "dice" is a very generic name.  I don't mind, but if you want to
> > > name it a bit more specific, that might be better.
> > Does "open-dice" sound good? I think that's the shorthand used on the
> > official website.
> 
> That might be better.
> 
> Naming is hard.
> 
> > > > +static long dice_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> > > > +{
> > > > +	switch (cmd) {
> > > > +	case DICE_GET_SIZE:
> > > > +		/* Checked against INT_MAX in dice_probe(). */
> > > > +		return dice_rmem->size;
> > > > +	case DICE_WIPE:
> > > > +		return dice_wipe();
> > > > +	}
> > > > +
> > > > +	return -ENOIOCTLCMD;
> > > 
> > > -ENOTTY please.
> > I have no personal attachment to ENOIOCTLCMD, but it is documented as
> > "no ioctl command" and converted to ENOTTY before returning to userspace.
> > That made me think this was the right thing to do.
> 
> ENOTTY is better please.
>
> 
> > > As you only have 2 ioctls, why not just use read/write for this?  Write
> > > would cause dice_wipe() to happen, and read would return the size in the
> > > buffer provided.  Then no ioctl is needed at all.
> > Fine by me but does feel like a bit of a hack. Is that a common pattern?
> 
> ioctls are hacks too :)
> 
> read/write like this is fine to do, might make the code simpler, and
> allow the code to be used by scripts easier.  At the very least, wipe
> can be done by any language instead of only those that allow ioctls.

Alright, read/write it is. And that gets rid of ioctls altogether.

-David