linux-kernel - Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

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: <CALCETrVcR_etAHSVZxvCz7CcPnF4ajpcWiRCtFrOckVWVJByHA@mail.gmail.com>
Date:   Tue, 26 Mar 2019 10:08:31 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Xing, Cedric" <cedric.xing@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Svahn, Kai" <kai.svahn@...el.com>, "bp@...en8.de" <bp@...en8.de>,
        "josh@...htriplett.org" <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Jethro Beekman <jethro@...tanix.com>,
        "Dr . Greg Wettstein" <greg@...ellic.com>
Subject: Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave()
 to wrap SGX enclave transitions

On Mon, Mar 25, 2019 at 9:53 PM Xing, Cedric <cedric.xing@...el.com> wrote:
>
> > On Mon, Mar 25, 2019 at 11:03 AM Sean Christopherson
> > <sean.j.christopherson@...el.com> wrote:
> > >
> > > On Sun, Mar 24, 2019 at 01:59:48AM -0700, Xing, Cedric wrote:
> > > > As said in my previous email, this vDSO API isn't even compliant to
> > > > x86_64 ABI and is absolutely NOT for average developers. Instead,
> > > > host/enclave communications are expected to be handled by SDKs and
> > > > those developers will be very aware of the limitations of their
> > > > targeted environments, and will need the freedom to deploy optimal
> > solutions.
> >
> > > I fully realize that the above approach saddles Cedric and the SDK
> > > team with the extra task of justifying the need for two vDSO
> > > interfaces, and likely reduces the probability of their proposal being
> > > accepted.  But, we don't *force* the SDK to be rewritten, and we gain
> > > a vDSO interface that many people want and is acceptable to the
> > > maintainers (unless I've horribly misread Andy's position).
> >
> > I don't think you've horribly misread it.  I would like to keep the
> > stuff in the vDSO as minimal as possible.  If we need to add a fancier
> > interface down the line, then that's fine.
>
> Andy, I don't know "many people" is how many in Sean's email. I couldn't tell you how long it took us to settle on the current SGX ISA because you would just LAUGH! Why? Because it took insanely ridiculously long. Why that long? Because the h/w and u-code teams would like to trim down the ISA as much as possible. The fact is, whatever new is released, Intel will have to maintain it on all future processors FOREVER! That means significant/on-going cost to Intel. So any addition to ISA has to undergo extensive reviews that involve all kinds of experts from both within Intel and externally, and would usually take years, before you can see what you are seeing today. As I said in my earlier emails, RBP is NOT needed for interrupt/exception handlers, then how did RBP end up being restored at AEX? You can guess how many people were standing behind it! Sean has no clue! I can assure you!
>
> Guess we've talked enough on the technical front. So let's talk about it on the business front. Let me take a step back. Let's say you are right, all enclaves would eventually be coded in the way you want. We (Intel SDK team) were convinced to follow your approach. But there were existing enclaves and a migration path would be needed. Would you like to support us? It'd be only 9 LOC on your side but how much would incur on our side? If you believe you are doing right thing, then acceptance is the next thing you should think of. You should offer an easy path for those who did "wrong" to get on your "right" boat. Don't you think so?
>

I suppose the real question is: are there a significant number of
users who will want to run enclaves created using an old SDK on Linux?
 And will there actually be support for doing this in the software
stack?

If the answer to both questions is yes, then it seems like it could be
reasonable to support it in the vDSO.  But I still think it should
probably be a different vDSO entry point so that the normal case
doesn't become more complicated.