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: <20201007002357.GB139112@linux.intel.com>
Date:   Wed, 7 Oct 2020 03:23:57 +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 Wed, Oct 07, 2020 at 12:39:27AM +0300, Jarkko Sakkinen wrote:
> 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.

So what I could do is to grow the reserved area and based on my response
explain this in the changelog message but I need to make sure that I got
the reasoning right behind the size.

/Jarkko