linux-kernel - Re: [PATCH 06/10] x86/cet: Add arch

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]

Message-Id: <13E3C29A-3295-4A7F-90EC-A84CF34F3E1A@amacapital.net>
Date:   Tue, 19 Jun 2018 17:50:49 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>,
        "H. J. Lu" <hjl.tools@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
        Linux-MM <linux-mm@...ck.org>,
        linux-arch <linux-arch@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        "Shanbhogue, Vedvyas" <vedvyas.shanbhogue@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        mike.kravetz@...cle.com, Florian Weimer <fweimer@...hat.com>
Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack



> On Jun 19, 2018, at 3:38 PM, Yu-cheng Yu <yu-cheng.yu@...el.com> wrote:
> 
> On Tue, 2018-06-19 at 13:47 -0700, Andy Lutomirski wrote:
>>> 
>>> On Jun 19, 2018, at 1:12 PM, Kees Cook <keescook@...omium.org>
>>> wrote:
>>> 
>>>> 
>>>> On Tue, Jun 19, 2018 at 10:20 AM, Andy Lutomirski <luto@...capita
>>>> l.net> wrote:
>>>> 
>>>>> 
>>>>> On Jun 19, 2018, at 10:07 AM, Kees Cook <keescook@...omium.org>
>>>>> 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?