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  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 <>
To:     "H.J. Lu" <>
Cc:     Yu-cheng Yu <>,
        the arch/x86 maintainers <>,
        "H. Peter Anvin" <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,
        LKML <>,
        "open list:DOCUMENTATION" <>,
        Linux-MM <>,
        linux-arch <>,
        Linux API <>,
        Arnd Bergmann <>,
        Andy Lutomirski <>,
        Balbir Singh <>,
        Borislav Petkov <>,
        Cyrill Gorcunov <>,
        Dave Hansen <>,
        Eugene Syromiatnikov <>,
        Florian Weimer <>,
        Jann Horn <>, Jonathan Corbet <>,
        Kees Cook <>,
        Mike Kravetz <>,
        Nadav Amit <>,
        Oleg Nesterov <>, Pavel Machek <>,
        Peter Zijlstra <>,
        Randy Dunlap <>,
        "Ravi V. Shankar" <>,
        Vedvyas Shanbhogue <>,
        Dave Martin <>,
        Weijiang Yang <>
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 <> 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:


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.

Powered by blists - more mailing lists