[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMe9rOrzrXORQgcAwzGn+=PBvxCEgc5Km_TQq+P7uoqwiacJSA@mail.gmail.com>
Date: Mon, 9 Mar 2020 16:11:03 -0700
From: "H.J. Lu" <hjl.tools@...il.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Andy Lutomirski <luto@...capital.net>,
Yu-cheng Yu <yu-cheng.yu@...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>,
LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Andy Lutomirski <luto@...nel.org>,
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>,
Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Nadav Amit <nadav.amit@...il.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
Peter Zijlstra <peterz@...radead.org>,
Randy Dunlap <rdunlap@...radead.org>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>,
Dave Martin <Dave.Martin@....com>, x86-patch-review@...el.com
Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description
On Mon, Mar 9, 2020 at 3:19 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 3/9/20 2:12 PM, H.J. Lu wrote:
> >> But what are the rules for clone()? Should there be rules for
> >> mismatches for CET enabling between threads if a process (not child
> >> processes)?
> > What did you mean? A threaded application is either CET enabled or not
> > CET enabled. A new thread from clone makes no difference.
>
> Stacks are fundamentally thread-local resources. The registers that
> point to them and MSRs that manage shadow stacks are all CPU-thread
> local. Nothing is fundamentally tied to the address space shared across
> the process.
>
> A thread might also share *no* control flow with its child. It might
> ask the thread to start in code that the parent can never even reach.
>
> It sounds like you've picked a Linux implementation that has
> restrictions on top of the fundamentals. That's not wrong per se, but
> it does deserve explanation and deliberate, not experimental design.
>
> Could you go back to the folks at Intel and try to figure out what this
> was designed to *do*? Yes, I'm probably one of those folks. You know
> where to find me. :)
A threaded application is loaded from disk. The object file on disk is
either CET enabled or not CET enabled.
--
H.J.
Powered by blists - more mailing lists