linux-kernel - Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow

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] [day] [month] [year] [list]

Message-ID: <ZBhE9m9qTT/wKeRQ@arm.com>
Date:   Mon, 20 Mar 2023 11:35:18 +0000
From:   Szabolcs Nagy <szabolcs.nagy@....com>
To:     Deepak Gupta <debug@...osinc.com>, Mike Rapoport <rppt@...nel.org>
Cc:     Rick Edgecombe <rick.p.edgecombe@...el.com>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Balbir Singh <bsingharora@...il.com>,
        Borislav Petkov <bp@...en8.de>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Florian Weimer <fweimer@...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>,
        Weijiang Yang <weijiang.yang@...el.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        John Allen <john.allen@....com>, kcc@...gle.com,
        eranian@...gle.com, jamorris@...ux.microsoft.com,
        dethoma@...rosoft.com, akpm@...ux-foundation.org,
        Andrew.Cooper3@...rix.com, christina.schimpe@...el.com,
        david@...hat.com, nd@....com, al.grant@....com
Subject: Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow_stack syscall

The 03/16/2023 12:30, Deepak Gupta wrote:
> On Tue, Mar 14, 2023 at 12:19 AM Mike Rapoport <rppt@...nel.org> wrote:
> > As for the userspace convenience, it is anyway required to add special
> > code for creating the shadow stack and it wouldn't matter if that code
> > would use mmap(NEW_FLAG) or map_shadow_stack().
> 
> Yes *strictly* from userspace convenience, it doesn't matter which option.

everybody seems to assume that the new syscall only matters for
the code allocating the shadow stack.

there are tools like strace, seccomp,.. that need to learn
about the new syscall and anything that's built on top of them
as well as libc api interposers like address sanitizer need to
learn about the related new libc apis (if there are any.. which
will be another long debate on the userspace side, delaying the
usability of shadow stacks even more). such tools already know
about mmap and often can handle new flags without much change.

i agree that too much special logic in mmap is not ideal and
using an mmap flag limits future extensions of both mmap and
shadow map functionality. but i disagree that a new syscall is
generally easy for userspace to deal with. in this case the
cost seems acceptable to me, but it's not free at all.