On 5/15/20 7:51 PM, H.J. Lu wrote: > On Fri, May 15, 2020 at 4:56 PM Dave Hansen <dave.hansen@xxxxxxxxx> 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.
