linux-kernel - Re: [PATCH v27 00/22] Intel SGX foundations

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: <CAOASepMmFC5bmoETu_KP967u+vFkqb385JckU1uFHHaVKNVaFw@mail.gmail.com>
Date:   Fri, 28 Feb 2020 17:19:45 -0500
From:   Nathaniel McCallum <npmccallum@...hat.com>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
        dave.hansen@...el.com, Neil Horman <nhorman@...hat.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        "Svahn, Kai" <kai.svahn@...el.com>, bp@...en8.de,
        Josh Triplett <josh@...htriplett.org>, luto@...nel.org,
        kai.huang@...el.com, rientjes@...gle.com, cedric.xing@...el.com,
        Patrick Uiterwijk <puiterwijk@...hat.com>
Subject: Re: [PATCH v27 00/22] Intel SGX foundations

On Fri, Feb 28, 2020 at 5:04 PM Dr. Greg <greg@...ellic.com> wrote:
>
> On Mon, Feb 24, 2020 at 01:13:17PM -0800, Sean Christopherson wrote:
>
> Hi, I hope the week is ending well for everyone.
>
> > On Mon, Feb 24, 2020 at 04:09:32AM -0600, Dr. Greg wrote:
> > > On Sun, Feb 23, 2020 at 07:25:37PM +0200, Jarkko Sakkinen wrote:
> > >
> > > Good morning, I hope the week is starting well for everyone.
> > >
> > > > Intel(R) SGX is a set of CPU instructions that can be used by
> > > > applications to set aside private regions of code and data. The code
> > > > outside the enclave is disallowed to access the memory inside the
> > > > enclave by the CPU access control.
> > >
> > > Do we misinterpret or is the driver not capable of being built in
> > > modular form?
>
> > Correct.
>
> That is what we had concluded, thanks for the verification.
>
> > > If not, it would appear that this functionality has been lost since
> > > version 19 of the driver, admittedly some time ago.
>
> > It was removed in v20[*].
>
> We didn't see documentation of this in any of the v20 release bullet
> points, hence the question.
>
> > > > * Allow the driver to be compiled as a module now that it no code is using
> > > >   its routines and it only uses exported symbols. Now the driver is
> > > >   essentially just a thin ioctl layer.
>
> > > Not having the driver available in modular form obviously makes
> > > work on the driver a bit more cumbersome.
>
> > Heh, depends on your development environment, e.g. I do 99% of my
> > testing in a VM with a very minimal kernel that even an anemic
> > system can incrementally build in a handful of seconds.
>
> Lacking a collection of big beefy development machines with 256+
> gigabytes of RAM isn't the challenge, rebooting to test functionality
> on the physical hardware is what is a bit of a nuisance.
>
> > > I'm assuming that the lack of module support is secondary to some
> > > innate architectural issues with the driver?
>
> > As of today, the only part of the driver that can be extracted into
> > a module is effectively the ioctl() handlers, i.e. a module would
> > just be an ioctl() wrapper around a bunch of in-kernel
> > functionality.  At that point, building the "driver" as a module
> > doesn't provide any novel benefit, e.g.  very little memory
> > footprint savings, reloading the module wouldn't "fix" any bugs with
> > EPC management, SGX can still be forcefully disabled via kernel
> > parameter, etc...  And on the flip side, allowing it to be a module
> > would require exporting a non-trivial number of APIs that really
> > shouldn't be exposed outside of the SGX subsystem.
> >
> > As for why things are baked into the kernel:
> >
> >   - EPC management: support for future enhancements (KVM and EPC cgroup).
> >
> >   - Reclaim: don't add a unnecessary infrastructure, i.e. avoid a callback
> >     mechanism for which there is a single implementation.
> >
> >   - Tracking of LEPUBKEYHASH MSRs: KVM support.
>
> I don't doubt the justifications, just a bit unusual for a driver, but
> this driver is obviously a bit unusual.
>
> It will be interesting to see if the distros compile it in.

We (Fedora) plan to as soon as it is merged. I even plan to ask for a backport.

> Thank you for the clarifications, have a good weekend.
>
> Dr. Greg
>
> As always,
> Dr. Greg Wettstein, Ph.D    Worker / Principal Engineer
> IDfusion, LLC
> 4206 19th Ave N.            Specialists in SGX secured infrastructure.
> Fargo, ND  58102
> PH: 701-281-1686            CELL: 701-361-2319
> EMAIL: gw@...usion.org
> ------------------------------------------------------------------------------
> "We are confronted with insurmountable opportunities."
>                                 -- Walt Kelly
>