Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <d7841acd416f9437b532a4acf65cfc46762ef79d.camel@linux.ibm.com>
Subject: Re: [RFC PATCH 0/3] Allow access to confidential computing secret
 area
From:   James Bottomley <jejb@linux.ibm.com>
Reply-To: jejb@linux.ibm.com
To:     "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
        Andi Kleen <ak@linux.intel.com>,
        Dov Murik <dovmurik@linux.ibm.com>
Cc:     Brijesh Singh <brijesh.singh@amd.com>, linux-efi@vger.kernel.org,
        Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@ibm.com>,
        Jim Cadden <jcadden@ibm.com>,
        Hubertus Franke <frankeh@us.ibm.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Laszlo Ersek <lersek@redhat.com>,
        Ashish Kalra <ashish.kalra@amd.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>
Date:   Mon, 24 May 2021 08:35:38 -0700
In-Reply-To: <YKuXI9TUBa3sjY3e@work-vm>
References: <20210513062634.2481118-1-dovmurik@linux.ibm.com>
         <2c8ae998-6dd0-bcb9-f735-e90da05ab9d9@amd.com> <YKZAUdbikp2Pt0XV@work-vm>
         <ccdf0059-7e39-7895-2733-412dbe4b13f1@linux.intel.com>
         <c316c49c-03db-22e3-0072-ebaf3c7f2ca2@amd.com>
         <45842efd-7b6b-496f-d161-e5786760078d@linux.intel.com>
         <YKuXI9TUBa3sjY3e@work-vm>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 2021-05-24 at 13:08 +0100, Dr. David Alan Gilbert wrote:
> * Andi Kleen (ak@linux.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