linux-kernel - Can we credibly make vdso_sgx_enter

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-next>] [day] [month] [year] [list]

Message-ID: <CALCETrUhQjQQa-BqNHPgdDfD9GDJZXJWSQ_M0tDF_ri5RfyTsw@mail.gmail.com>
Date:   Fri, 25 Sep 2020 09:55:00 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Borislav Petkov <bp@...en8.de>,
        Jethro Beekman <jethro@...tanix.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Can we credibly make vdso_sgx_enter_enclave() pleasant to use?

vdso_sgx_enter_enclave() sucks. I don't think anyone seriously likes
it, but maybe it's the best we can do.

I'm wondering if it's worth trying to do better.  Here's what I'd like
if I could wave a magic wand:

struct sgx_enclave_run {
       __u64 tcs;
       __u32 flags;
       __u32 exit_reason;

    /*
     * These values are exposed to the enclave on entry, and the values
     * left behind by the enclave are returned here.
     * Some enclaves might write to memory pointed to by rsp.
     */
       __u64 rsp, rbp, r8, r9, r10, r11, r12, r13, r14, r15;
       /* Maybe other regs too? */

       union {
               struct sgx_enclave_exception exception;

               /* Pad the entire struct to 256 bytes. */
               __u8 pad[256 - 32];
       };
};

long vdso_sgx_enter_enclave(unsigned int leaf, struct sgx_enclave_run *r);

No callback, no asm wrapper needed, no nastiness from the perspective
of the caller.

So here are my questions.  First, do people agree with me that this
would be better?  Second, could this be implemented in a way that
doesn't utterly suck?  The best I've come up with so far is abusing
WRFSBASE to shove a little data structure containing the real user RSP
or RBP along with the old FSBASE into FSBASE, do EENTER, and then undo
the FSBASE dance.  We'd also need some additional exception fixup
magic to prevent a signal or ptrace() from observing the intermediate
states and getting extremely confused.

--Andy