Messages in this thread | | | Date | Mon, 3 Oct 2022 21:18:12 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v2 30/39] x86: Expose thread features status in /proc/$PID/arch_status |
| |
On Mon, Oct 03, 2022 at 03:45:50PM -0700, Andy Lutomirski wrote: > > > 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 :)
Ah, but that would be needed for compat things too in "arch_status", and could just as well live in "status".
How about moving both of these into "status", with appropriate names?
x86_64.Thread_features: ... i386.LDT_or_something: ...
?
Does anything consume arch_status yet? Looks like probably not: https://codesearch.debian.net/search?q=%5Cbarch_status%5Cb&literal=0&perpkg=1
-- Kees Cook
| |