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]

Message-ID: <eeeb51049e894a70b40013ec18a9fa65@intel.com>
Date:   Tue, 21 Sep 2021 20:50:11 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     "Hansen, Dave" <dave.hansen@...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

>>  	section->phys_addr = phys_addr;
>> +	section->end_phys_addr = phys_addr + size - 1;
>> +	xa_store_range(&epc_page_ranges, section->phys_addr,
>> +		       section->end_phys_addr, section, GFP_KERNEL);
>
> 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" :-).

-Tony