linux-kernel - x86/sgx: uapi change proposal

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: <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com>
Date:   Wed, 19 Dec 2018 09:58:26 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        sean.j.christopherson@...el.com
Cc:     "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        linux-sgx@...r.kernel.org, Andy Lutomirski <luto@...capital.net>,
        Josh Triplett <josh@...htriplett.org>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Jethro Beekman <jethro@...tanix.com>,
        "Dr . Greg Wettstein" <greg@...ellic.com>
Subject: x86/sgx: uapi change proposal

I have pretty much figured out how to change the driver implementation
from VMA based to file based. Most of the code in the driver can be
reused with not that enormous changes. I think it is a clue that the
architecture is somewhat right because changing the driver this
radically does not seem to require any changes to the core.

Using anon inode is the right choice because it is more robust interface
to be able to create multiple enclaves.

The only remaining open that I have when it comes to implementing this
is the backing storage. From API perspective the most robust choice
would be to revert to use shmem file. It would be easy then to create a
complete construction flow without any dependencies to mm_struct.

I do recognize the issue with accounting but to which process the
backing storage should be accounted anyway in this new paradigm.

I've attached the new uapi header to this email that I'm going forward
with.

/Jarkko

View attachment "sgx.h" of type "text/x-chdr" (2079 bytes)