Message-ID: <f38b5b34-8432-9531-01b5-d0ae924ffafe@intel.com>
Date:   Thu, 23 Jul 2020 11:41:55 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Yu-cheng Yu <yu-cheng.yu@...el.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, 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>,
        "H.J. Lu" <hjl.tools@...il.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>,
        Weijiang Yang <weijiang.yang@...el.com>
Subject: Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack

On 7/23/20 9:56 AM, Sean Christopherson wrote:
> On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
>> On 7/23/20 9:25 AM, Sean Christopherson wrote:
>>> How would people feel about taking the above two patches (02 and 03 in the
>>> series) through the KVM tree to enable KVM virtualization of CET before the
>>> kernel itself gains CET support?  I.e. add the MSR and feature bits, along
>>> with the XSAVES context switching.  The feature definitons could use "" to
>>> suppress displaying them in /proc/cpuinfo to avoid falsely advertising CET
>>> to userspace.
>>>
>>> AIUI, there are ABI issues that need to be sorted out, and that is likely
>>> going to drag on for some time. 
>>>
>>> Is this a "hell no" sort of idea, or something that would be feasible if we
>>> can show that there are no negative impacts to the kernel?
>> Negative impacts like bloating every task->fpu with XSAVE state that
>> will never get used? ;)
> Gah, should have qualified that with "meaningful or measurable negative
> impacts".  E.g. the extra 40 bytes for CET XSAVE state seems like it would
> be acceptable overhead, but noticeably increasing the latency of XSAVES
> and/or XRSTORS would not be acceptable.

It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste.  It
would have no *chance* of being used.  It's also quite precisely
measurable on a given system:

	cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'

I don't expect it would do *much* to XSAVE/XRSTOR.  There's probably an
extra conditional and jump in the ucode, but that's probably in the
noise.  I assume that all the CET state has functioning init and
modified trackers and we don't do anything to spoil their state.  It
would be good to check that in practice, though it probably isn't the
end of the world either way.  We've had some bugs in the past where we
accidentally took things out of their init state.

It will make signal entry/return slower since we use a plain XSAVE
without the init optimization.  But, that's just a single cacheline on
average and some 0's to write.  Probably not noticeable, including the
40 bytes of extra userspace signal stack space.

I think that puts me in the "mildly annoyed" camp more than "hell no",
but "mildly annoyed" is pretty much my resting state, so it doesn't
really move the needle. :)

Why the urgency, though?

	https://windows-internals.com/cet-on-windows/

?

Powered by blists - more mailing lists