linux-kernel - Re: [RFC PATCH v6 00/26] Control-flow Enforcement: Shadow Stack

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: <35b33f293bc392df71710102f38fa6a40d0bb996.camel@intel.com>
Date:   Mon, 26 Nov 2018 09:38:49 -0800
From:   Yu-cheng Yu <yu-cheng.yu@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Carlos O'Donell <carlos@...hat.com>,
        Rich Felker <dalias@...c.org>
Cc:     X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Balbir Singh <bsingharora@...il.com>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        "H. J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        "Shanbhogue, Vedvyas" <vedvyas.shanbhogue@...el.com>
Subject: Re: [RFC PATCH v6 00/26] Control-flow Enforcement: Shadow Stack

On Thu, 2018-11-22 at 08:53 -0800, Andy Lutomirski wrote:
> [cc some more libc folks]
> 
> I have a general question about this patch set:
> 
> If I'm writing a user program, and I write a signal handler, there are
> two things I want to make sure I can still do:
> 
> 1. I want to be able to unwind directly from the signal handler
> without involving sigreturn() -- that is, I want to make sure that
> siglongjmp() works.  How does this work?  Is INCSSP involved?  How

Yes, siglongjmp() works by doing INCSSP.

> exactly does the user program know how much to increment SSP by?  (And
> why on Earth does INCSSP only consider the low 8 bits of its argument?
>  That sounds like a mistake.  Can Intel still fix that?  On the other

GLIBC calculates how many frames to be unwound and breaks into 255 batches when
necessary.

> hand, what happens if you INCSSP off the end of the shadow stack
> entirely?  I assume the next access will fault as long as there's an
> appropriate guard page.)

Yes, that is the case.

> 
> 2. I want to be able to modify the signal context from a signal
> handler such that, when the signal handler returns, it will return to
> a frame higher up on the call stack than where the signal started and
> to a different RIP value.  How can I do this?  I guess I can modify
> the shadow stack with WRSS if WR_SHSTK_EN=1, but how do I tell the
> kernel to kindly skip the frames I want to skip when I do sigreturn()?
> 
> The reason I'm asking #2 is that I think it's time to resurrect my old
> vDSO syscall cancellation helper series here:
> 
> https://lwn.net/Articles/679434/

If tools/testing/selftests/x86/unwind_vdso.c passes, can we say the kernel does
the right thing?  Or do you have other tests that I can run?

> 
> and it's not at all clear to me that __vdso_abort_pending_syscall()
> can work without kernel assistance when CET is enabled.  I want to
> make sure that it can be done, or I want to come up with some other
> way to allow a signal handler to abort a syscall while CET is on.  I
> could probably change __vdso_abort_pending_syscall() to instead point
> RIP to __kernel_vsyscall's epilogue so that we con't change the depth
> of the call stack.  But I could imagine that other user programs might
> engage in similar shenanigans and want to have some way to unwind a
> signal's return context without actually jumping there a la
> siglongjmp().
> 
> Also, what is the intended setting of WR_SHSTK_EN with this patch set applied?

This bit enables WRSS instruction, which writes to kernel SHSTK.  This patch set
uses only WRUSS and WR_SHSTK_EN is not be set.

> 
> (I suppose we could just say that 32-bit processes should not use CET,
> but that seems a bit sad.)

They work in compat mode.  Should anything break, we can fix it.

Yu-cheng