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]
Date:   Wed, 30 Mar 2022 23:40:56 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Reinette Chatre <reinette.chatre@...el.com>
Cc:     Shuah Khan <skhan@...uxfoundation.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Shuah Khan <shuah@...nel.org>,
        "open list:INTEL SGX" <linux-sgx@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] selftests/sgx: Use rip relative addressing for
 encl_stack

On Wed, 2022-03-30 at 13:05 -0700, Reinette Chatre wrote:
> 
> 
> On 3/30/2022 12:03 PM, Jarkko Sakkinen wrote:
> > On Wed, 2022-03-30 at 10:40 -0700, Reinette Chatre wrote:
> > > Could you please elaborate how the compiler will fix it up?
> > 
> > Sure.
> > 
> > Here's the disassembly of the RBX version:
> > 
> > [0x000021a9]> pi 1
> > lea rax, [rbx + loc.encl_stack]
> > 
> > Here's the same with s/RBX/RIP/:
> > 
> > [0x000021a9]> pi 5
> > lea rax, loc.encl_stack
> > 
> > Compiler will substitute correct offset relative to the RIP,
> > well, because it can and it makes sense.
> 
> It does not make sense to me because, as proven with my test,
> the two threads end up sharing the same stack memory.

I see, I need to correct my patch, thanks!

RBX gives correct results because of the binary organization,
i.e. TCS's are placed to zero offset and forward, and 
unrelocated symbol is just compiled in as an untranslated
offset.

RPI is given correct results but how the semantics work
right now is incompatible.

Still, even for kselftest, I would consider a switch
because that way:

1. You can layout binary however you wan and things
   won't break.
2. You can point to any symbol not just stack, if
   ever need.
   
I admit it works semantically but it just super
unrobust.

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ