linux-kernel - Re: [PATCH v10 01/26] Documentation/x86: Add CET description

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 May 2020 16:09:39 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "H.J. Lu" <hjl.tools@...il.com>
Cc:     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>,
        "open list:DOCUMENTATION" <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>,
        Weijiang Yang <weijiang.yang@...el.com>
Subject: Re: [PATCH v10 01/26] Documentation/x86: Add CET description

On 5/15/20 7:51 PM, H.J. Lu wrote:
> On Fri, May 15, 2020 at 4:56 PM Dave Hansen <dave.hansen@...el.com> wrote:
>> Let's say we have an app doing silly things like retpolines.  (Lots of
>> app do lots of silly things).  It gets compiled in a distro but never
>> runs on a system with CET.  The app gets run for the first time on a
>> system with CET.  App goes boom.  Not init, just some random app, say
>> /usr/bin/ldapsearch.
> 
> I designed and implemented CET toolchain and run-time in such a way
> for it very difficult to happen.   Basically, CET won't be enabled on such
> an app.

Would you care to share any specifics about how this is implemented?
That would be great information to include in the kernel documentation
because it informs us about the reasons why we don't need a kernel-based
"kill switch".

>> What's my recourse as an end user?  I want to run my app and turn off
>> CET for that app.  How can I do that?
> 
> The CET OS I designed turns CET off for you and you don't have to do
> anything.

OK, cool!  Could you share some of the specifics about how it does that?

>>         Is it possible with the patches in this series to run a single-
>>         threaded binary which was has GNU_PROPERTY_X86_FEATURE_1_SHSTK
>>         unset to run with shadow stack protection?
> 
> Yes, you can.  I added such capabilities for testing purpose.  But
> you application will crash as soon as there is a CET violation.  My
> CET software design is very flexible. 

Yu-cheng speficially referred to the:

	GLIBC_TUNABLES=glibc.tune.hwcaps=-SHSTK,-IBT

option.  Is that the option you're talking about?

>>> I have a quick test that checks shadow stack and ibt in both main program and in
>>> signals.  Currently it is public on Github.  If that is desired, I can submit it
>>> to the mailing list.
>>
>> Yes, that is desired.  It must accompany this submission.  It must also
>> exercise all of the new ABIs.
> 
> Our CET smoke test is for quick validation of CET OS, not just
> kernel. It requires the complete CET implementation.   It does
> nothing if your OS isn't CET enabled.
I think requiring the complete CET implementation to be present for this
test to work is a mistake.  We don't require anything other than an
enabled kernel and the selftests that ship with that kernel.

MPX required toolchain, library and compiler changes.  Yet, we had a
totally standalone kernel test that found real bugs.  It sounds like
this smoke test as it stands wouldn't be a great fit.  But, that
shouldn't discourage us from finding something that _is_ a good fit for
the kernel-shipped selftests.