Re: [PATCH v2 30/39] x86: Expose thread features status in /proc/$PID/arch_status

Andy Lutomirski
2022-10-03T22:46:23Z

On Mon, Oct 3, 2022, at 3:37 PM, Kees Cook wrote:
> On Thu, Sep 29, 2022 at 03:29:27PM -0700, Rick Edgecombe wrote:
>> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>>
>> Applications and loaders can have logic to decide whether to enable CET.
>> They usually don't report whether CET has been enabled or not, so there
>> is no way to verify whether an application actually is protected by CET
>> features.
>>
>> Add two lines in /proc/$PID/arch_status to report enabled and locked
>> features.
>>
>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> [Switched to CET, added to commit log]
>> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
>>
>> ---
>>
>> v2:
>> - New patch
>>
>> arch/x86/kernel/Makefile | 2 ++
>> arch/x86/kernel/fpu/xstate.c | 47 ---------------------------
>> arch/x86/kernel/proc.c | 63 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 65 insertions(+), 47 deletions(-)
>> create mode 100644 arch/x86/kernel/proc.c
>
> This is two patches: one to create proc.c, the other to add CET support.
>
> I found where the "arch_status" conversation was:
> https://lore.kernel.org/all/CALCETrUjF9PBmkzH1J86vw4ZW785DP7FtcT+gcSrx29=BUnjoQ@mail.gmail.com/
>
> Andy, what did you mean "make sure that everything in it is namespaced"?
> Everything already has a field name. And arch_status doesn't exactly
> solve having compat fields -- it still needs to be handled manually?
> Anyway... we have arch_status, so I guess it's fine.

I think I meant that, since it's "arch_status" not "x86_status", the fields should have names like "x86.Thread_features". Otherwise if another architecture adds a Thread_features field, then anything running under something like qemu userspace emulation could be confused.

Assuming that's what I meant, I think my comment still stands :)