linux-kernel - Re: [PATCH v5 2/7] x86/sgx: Add infrastructure to identify SGX EPC pages

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:   Tue, 21 Sep 2021 15:32:14 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Matthew Wilcox <willy@...radead.org>
Cc:     "Zhang, Cathy" <cathy.zhang@...el.com>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/7] x86/sgx: Add infrastructure to identify SGX EPC
 pages

On 9/21/21 1:50 PM, Luck, Tony wrote:
>> Did we ever figure out how much space storing really big ranges in the
>> xarray consumes?
> No. Willy said the existing xarray code would be less than optimal with
> this usage, but that things would be much better when he applied some
> maple tree updates to the internals of xarray.
> 
> If there is some easy way to measure the memory backing an xarray I'm
> happy to get the data. Or if someone else can synthesize it ... the two
> ranges on my system that are added to the xarray are:
> 
> $ dmesg | grep -i sgx
> [    8.496844] sgx: EPC section 0x8000c00000-0x807f7fffff
> [    8.505118] sgx: EPC section 0x10000c00000-0x1007fffffff
> 
> I.e. two ranges of a bit under 2GB each.
> 
> But I don't think the overhead can be too hideous:
> 
> $ grep MemFree /proc/meminfo
> MemFree:        1048682016 kB
> 
> I still have ~ 1TB free. Which is much greater that the 640 KB which should
> be "enough for anybody" :-).

There is a kmem_cache_create() for the xarray nodes.  So, you should be
able to see the difference in /proc/meminfo's "Slab" field.  Maybe boot
with init=/bin/sh to reduce the noise and look at meminfo both with and
without SGX your patch applied, or just with the xarray bits commented out.

I don't quite know how the data structures are munged, but xas_alloc()
makes it look like 'struct xa_node' is allocated from
radix_tree_node_cachep.  If that's the case, you should also be able to
see this in even more detail in:

# grep radix /proc/slabinfo
radix_tree_node   432305 482412    584   28    4 : tunables    0    0
 0 : slabdata  17229  17229      0

again, on a system with and without your new code enabled.