> On Jun 19, 2018, at 3:38 PM, Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote: > > On Tue, 2018-06-19 at 13:47 -0700, Andy Lutomirski wrote: >>> >>> On Jun 19, 2018, at 1:12 PM, Kees Cook <keescook@xxxxxxxxxxxx> >>> wrote: >>> >>>> >>>> On Tue, Jun 19, 2018 at 10:20 AM, Andy Lutomirski <luto@amacapita >>>> l.net> wrote: >>>> >>>>> >>>>> On Jun 19, 2018, at 10:07 AM, Kees Cook <keescook@xxxxxxxxxxxx> >>>>> wrote: >>>>> >>>>> Does it provide anything beyond what PR_DUMPABLE does? >>>> What do you mean? >>> I was just going by the name of it. I wasn't sure what "ptrace CET >>> lock" meant, so I was trying to understand if it was another "you >>> can't ptrace me" toggle, and if so, wouldn't it be redundant with >>> PR_SET_DUMPABLE = 0, etc. >>> >> No, other way around. The valid CET states are on/unlocked, >> off/unlocked, on/locked, off/locked. arch_prctl can freely the state >> unless locked. ptrace can change it no matter what. The lock is to >> prevent the existence of a gadget to disable CET (unless the gadget >> involves ptrace, but I don’t think that’s a real concern). > > We have the arch_prctl now and only need to add ptrace lock/unlock. > > Back to the dlopen() "relaxed" mode. Would the following work? > > If the lib being loaded does not use setjmp/getcontext families (the > loader knows?), then the loader leaves shstk on. Will that actually work? Are there libs that do something like longjmp without actually using the glibc longjmp routine? What about compilers that statically match a throw to a catch and try to return through several frames at once? > Otherwise, if the > system-wide setting is "relaxed", the loader turns off shstk and issues > a warning. In addition, if (dlopen == relaxed), then cet is not locked > in any time. > > The system-wide setting (somewhere in /etc?) can be: > > dlopen=force|relaxed /* controls dlopen of non-cet libs */ > exec=force|relaxed /* controls exec of non-cet apps */ > > Why do we need a whole new mechanism here? Can’t all this use regular glibc tunables?
