[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202210032114.BECA56BFF@keescook>
Date: Mon, 3 Oct 2022 21:18:12 -0700
From: Kees Cook <keescook@...omium.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Rick P Edgecombe <rick.p.edgecombe@...el.com>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-doc@...r.kernel.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, Linux API <linux-api@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Balbir Singh <bsingharora@...il.com>,
Borislav Petkov <bp@...en8.de>,
Cyrill Gorcunov <gorcunov@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Eugene Syromiatnikov <esyr@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
"H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
Jonathan Corbet <corbet@....net>,
Mike Kravetz <mike.kravetz@...cle.com>,
Nadav Amit <nadav.amit@...il.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Randy Dunlap <rdunlap@...radead.org>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
Weijiang Yang <weijiang.yang@...el.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
"Moreira, Joao" <joao.moreira@...el.com>,
"john.allen@....com" <john.allen@....com>,
"kcc@...gle.com" <kcc@...gle.com>,
"Eranian, Stephane" <eranian@...gle.com>,
Mike Rapoport <rppt@...nel.org>, jamorris@...ux.microsoft.com,
dethoma@...rosoft.com
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@...ux.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@...ux.intel.com>
> >> [Switched to CET, added to commit log]
> >> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@...el.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
Powered by blists - more mailing lists