linux-kernel - Re: [PATCH v2 1/2] selftests/sgx: Use rip relative addressing for encl

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 14:29:21 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
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

Hi Jarkko,

On 3/30/2022 1:40 PM, Jarkko Sakkinen wrote:
> 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.

I do not think that we need an exceptionally flexible
runtime as part of the SGX selftests but instead something
that is easy(*) to understand while also sufficient to support
the tests.

Reinette

* I do not actually consider the existing enclave test binary
  easy to understand (this thread is proof) but keeping its
  complexity to be minimal would benefit folks needing to
  ramp up on SGX and/or debug kselftest failures.