linux-kernel - Re: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

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: <20201006213927.GA117517@linux.intel.com>
Date:   Wed, 7 Oct 2020 00:39:27 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     x86@...nel.org, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Andy Lutomirski <luto@...capital.net>,
        Jethro Beekman <jethro@...tanix.com>,
        Cedric Xing <cedric.xing@...el.com>, akpm@...ux-foundation.org,
        andriy.shevchenko@...ux.intel.com, asapek@...gle.com, bp@...en8.de,
        chenalexchen@...gle.com, conradparker@...gle.com,
        cyhanish@...gle.com, dave.hansen@...el.com, haitao.huang@...el.com,
        kai.huang@...el.com, kai.svahn@...el.com, kmoy@...gle.com,
        ludloff@...gle.com, luto@...nel.org, nhorman@...hat.com,
        npmccallum@...hat.com, puiterwijk@...hat.com, rientjes@...gle.com,
        tglx@...utronix.de, yaozhangx@...gle.com, mikko.ylinen@...el.com
Subject: Re: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX
 enclave call

On Mon, Oct 05, 2020 at 07:57:05PM -0700, Sean Christopherson wrote:
> On Sat, Oct 03, 2020 at 07:50:56AM +0300, Jarkko Sakkinen wrote:
> > +	__u16 exception_vector;
> > +	__u16 exception_error_code;
> > +	__u64 exception_addr;
> > +	__u8  reserved[24];
> 
> I also think it's a waste of space to bother with multiple reserved fields.
> 24 bytes isn't so much that it guarantees we'll never run into problems in
> the future.  But I care far less about this than I do about exit_reason.

For me the real problem is that there has not been "no brainer" basis
for any size, so a one cache line worth of data is just something that
makes sense, because would neither make much sense to have less.

I'll throw an argument to have it a bit bigger amount of reserved space
for future use.

First, there is always some amount of unknown unknowns when it comes to
run-time structures, given the evolution of microarchitectures. So yes,
some more "state" might be needed in the future.

Secondly, this is a bigger problem for the vDSO than it is for ioctl's
because we can have only one. With ioctl's, in the absolute worst case,
we can have a second version of the same ioctl.

At least 256 bytes would be probably a good number, if we want to
increase it. The reserved space zero validation that I implemented to
this version probably does not add much to the overhead anyway.

I'm not sure why care about one struct field more than making sure that
the run-time structure can stand time.

/Jarkko