linux-kernel - Re: [PATCH 4/5] selftests/sgx: Ensure expected enclave data buffer size and placement.

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:   Fri, 18 Aug 2023 18:11:39 -0700
From:   Jo Van Bulck <jo.vanbulck@...kuleuven.be>
To:     "Huang, Kai" <kai.huang@...el.com>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 4/5] selftests/sgx: Ensure expected enclave data buffer
 size and placement.

On 18.08.23 06:07, Huang, Kai wrote:
> Could we use "used" attribute?
> 
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
> 
> used
> 
> 	This attribute, attached to a variable with static storage, means that
> 	the variable must be emitted even if it appears that the variable is
> 	not referenced.
> 
> 	When applied to a static data member of a C++ class template, the
> 	attribute also means that the member is instantiated if the class
> 	itself is instantiated.

Thank you for pointing this out! I was not aware of this attribute, but 
it is indeed exactly what we need in this case and works as expected.

>>
>> 2. adding _attribute__((section(".data.encl_buffer"))) ensures that we
>> can control the expected location at the start of the .data section. I
>> think this is optional, as encl_buf always seems to be placed at the
>> start of .data in all my tests. But afaik this is not guaranteed as per
>> the C standard and such constraints on exact placement should better be
>> explicitly controlled in the linker script(?)
> 
> This looks sane.

Thanks, applying this in a separate commit as discussed.

Best,
Jo