linux-kernel - Re: [PATCH V2 03/15] x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node

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] [day] [month] [year] [list]

Message-ID: <78a1bdf6-a5f0-0305-5e43-c1f9290d9b79@intel.com>
Date:   Fri, 29 Oct 2021 12:03:32 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>, <jarkko@...nel.org>,
        <linux-sgx@...r.kernel.org>, <shuah@...nel.org>,
        <dave.hansen@...ux.intel.com>
CC:     <seanjc@...gle.com>, <linux-kselftest@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 03/15] x86/sgx: Add an attribute for the amount of SGX
 memory in a NUMA node

Hi Dave,

On 10/29/2021 11:06 AM, Dave Hansen wrote:
> On 10/28/21 1:37 PM, Reinette Chatre wrote:
>> The amount of SGX memory on the system is determined by the BIOS and it
>> varies wildly between systems.  It can be from dozens of MB's on desktops
>> or VM's, up to many GB's on servers.  Just like for regular memory, it is
>> sometimes useful to know the amount of usable SGX memory in the system.
>>
>> Add an attribute for the amount of SGX memory in bytes to each NUMA
>> node. The path is /sys/devices/system/node/node[0-9]*/sgx/size.
>> Calculate these values by summing up EPC section sizes for each node
>> during the driver initalization.
> 
> For now, can we just make the selftests read the SGX CPUID section
> leaves?  It's not as precise as knowing how much the kernel actually
> decided to use, but it's good enough for a selftest.  It also means we
> can merge something without having to worry about long-term ABI.

Yes, we can do that.

> 
> This is also why I once suggested that we first make the selftests
> depend on some debugfs file that would be short-lived.  But, if we use
> CPUID, we don't even need to mess with debugfs.

My apologies, this was not intended to avoid your suggestion. V1 did use 
the debugfs solution as you suggested as placeholder but after the 
debufs solution evolved the tests were adapted to follow those changes 
instead of sticking with the debugfs solution as proposed in
https://lore.kernel.org/lkml/6f3cc681e10877e639b882eaabf1a5e21bd2fc94.camel@kernel.org/

> You can even just steal the code from sgx_page_cache_init() to do it.
> 
> Would that work, or am I missing something?
> 

I do think that will work. The selftests are only interested in the 
total SGX memory (as opposed to memory per numa node as exposed with the 
current interface) and that can be obtained via CPUID. I will adapt the 
oversubscription test case to obtain its needed info via CPUID.

Thank you very much

Reinette