linux-kernel - Re: [PATCH 0/6] Introduce CET supervisor state support

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: <4bba0c20-0cd0-4c1a-abf0-511ba6940a57@intel.com>
Date: Thu, 11 Jul 2024 15:30:35 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "Yang, Weijiang" <weijiang.yang@...el.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>, "x86@...nel.org" <x86@...nel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>
Cc: "john.allen@....com" <john.allen@....com>,
 "peterz@...radead.org" <peterz@...radead.org>, "Gao, Chao"
 <chao.gao@...el.com>, "mlevitsk@...hat.com" <mlevitsk@...hat.com>
Subject: Re: [PATCH 0/6] Introduce CET supervisor state support

On 7/11/24 15:11, Edgecombe, Rick P wrote:
> On Thu, 2024-07-11 at 13:58 -0700, Dave Hansen wrote:
>> So we're down to choosing between
>>
>>  * $BYTES space in 'struct fpu' (on hardware supporting CET-S)
>>
>> or
>>
>>  * ~100 loc
>>
>> $BYTES is 24, right?  Did I get anything wrong?
> 
> Do we know what the actual memory use is? It would increases the size asked of
> of the allocator by 24 bytes, but what amount of memory actually gets reserved?
> 
> It is sometimes a slab allocated buffer, and sometimes a vmalloc, right? I'm not
> sure about slab sizes, but for vmalloc if the increase doesn't cross a page
> size, it will be the same size allocation in reality. Or if it is close to a
> page size already, it might use a whole extra 4096 bytes.

Man, I hope I don't have this all mixed up in my head.  Wouldn't be the
first time.  I _think_ you might be confusing thread_info and
thread_struct, though.  I know I've gotten them confused before.

But we get to the 'struct fpu' via:

	current->thread.fpu

Where current is a 'task_struct' which is in /proc/slabinfo and 'struct
thread_struct thread' and 'struct fpu' are embedded in 'task_struct',
not allocated on their own:

	task_struct         2958   3018  10048  3 8 ...

So my current task_struct is 10048 bytes and 3 of them fit in each
8-page slab, leaving 2624 bytes to spare.

I don't think we're too dainty about adding thing to task_struct.  Are we?

> So we might be looking at a situation where some tasks get an entire extra page
> allocated per task, and some get no difference. And only the average is 24 bytes
> increase.

I think you're right here, at least when it comes to large weirdly-sized
slabs.  But _so_ many things affect task_struct that I've never seen
anyone sweat it too much.