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:   Thu, 10 Jan 2019 13:36:15 -0800
From:   Andy Lutomirski <>
To:     Jarkko Sakkinen <>
Cc:     Andy Lutomirski <>,
        Sean Christopherson <>,
        "Huang, Kai" <>,
        Jethro Beekman <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        "" <>,
        Dave Hansen <>,
        Peter Zijlstra <>,
        "H. Peter Anvin" <>,
        "" <>,
        "" <>,
        Josh Triplett <>,
        Haitao Huang <>,
        "Dr . Greg Wettstein" <>
Subject: Re: x86/sgx: uapi change proposal

On Thu, Jan 10, 2019 at 9:46 AM Jarkko Sakkinen
<> wrote:
> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > I do think it makes sense to have QEMU delegate the various ENCLS
> > operations (especially EINIT) to the regular SGX interface, which will
> > mean that VM guests will have exactly the same access controls applied
> > as regular user programs, which is probably what we want.  If so,
> > there will need to be a way to get INITTOKEN privilege for the purpose
> > of running non-Linux OSes in the VM, which isn't the end of the world.
> > We might still want the actual ioctl to do EINIT using an actual
> > explicit token to be somehow restricted in a way that strongly
> > discourages its use by anything other than a hypervisor.  Or I suppose
> > we could just straight-up ignore the guest-provided init token.
> Does it even matter if just leave EINITTOKENKEY attribute unprivileged
> given that Linux requires that MSRs are writable? Maybe I'll just
> whitelist that attribute to any enclave?

I would at least make it work like the PROVISIONKEY bit (or whatever
it's called).  Or just deny it at first.  It's easy to start allowing
it if we need to down the road, but it's harder to start denying it.

Also, I don't really want to see some SDK invoke a launch enclave
because that's how it works on Windows and then do nothing with the
resulting EINITOKEN.  If we don't allow it, then the SDKs will be
forced to do a better job, which is probably a good thing.

Powered by blists - more mailing lists