On 5/15/20 7:51 PM, H.J. Lu wrote:

On Fri, May 15, 2020 at 4:56 PM Dave Hansen [off-list ref] wrote:

quoted

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".

quoted

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?

quoted

        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?

quoted

quoted

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.