linux-kernel - Re: [RFC PATCH 0/3] Allow access to confidential computing secret area

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]

Date:   Mon, 24 May 2021 08:35:38 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Dov Murik <dovmurik@...ux.ibm.com>
Cc:     Brijesh Singh <brijesh.singh@....com>, linux-efi@...r.kernel.org,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Jim Cadden <jcadden@....com>,
        Hubertus Franke <frankeh@...ibm.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Laszlo Ersek <lersek@...hat.com>,
        Ashish Kalra <ashish.kalra@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: Re: [RFC PATCH 0/3] Allow access to confidential computing secret
 area

On Mon, 2021-05-24 at 13:08 +0100, Dr. David Alan Gilbert wrote:
> * Andi Kleen (ak@...ux.intel.com) wrote:
[...]
> > We opted to use ioctls, with the idea that it should be just read
> > and cleared once to not let the secret lying around. Typically you
> > would just use it to set up dmcrypt or similar once. I think read-
> > and-clear with explicit operations is a better model than some
> > virtual file because of the security properties.
> 
> Do you think the ioctl is preferable to read+ftruncate/unlink ?

I really think if we do a unified upper interface it should be file
based.  An ioctl based on will have too much temptation to expose the
architecture of the underlying system.  However, the way to explore
this would be to ask if there's anything the current ioctl based one
can do that a file based one couldn't?

I think ftruncate/unlink is a preferable interface because it puts the
control in the hands of the consumer: you don't know how far the secret
might get shared, so by doing clear on first read the driver is forcing
the user implementation to cache it instead, thus shifting the problem
not solving it.

James