linux-kernel - Re: [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size

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: <20210317104415.GA692070@gmail.com>
Date:   Wed, 17 Mar 2021 11:44:15 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     "Chang S. Bae" <chang.seok.bae@...el.com>
Cc:     bp@...e.de, tglx@...utronix.de, luto@...nel.org, x86@...nel.org,
        len.brown@...el.com, dave.hansen@...el.com, hjl.tools@...il.com,
        Dave.Martin@....com, jannh@...gle.com, mpe@...erman.id.au,
        carlos@...hat.com, tony.luck@...el.com, ravi.v.shankar@...el.com,
        libc-alpha@...rceware.org, linux-arch@...r.kernel.org,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Chang S. Bae <chang.seok.bae@...el.com> wrote:
> 
> > During signal entry, the kernel pushes data onto the normal userspace
> > stack. On x86, the data pushed onto the user stack includes XSAVE state,
> > which has grown over time as new features and larger registers have been
> > added to the architecture.
> > 
> > MINSIGSTKSZ is a constant provided in the kernel signal.h headers and
> > typically distributed in lib-dev(el) packages, e.g. [1]. Its value is
> > compiled into programs and is part of the user/kernel ABI. The MINSIGSTKSZ
> > constant indicates to userspace how much data the kernel expects to push on
> > the user stack, [2][3].
> > 
> > However, this constant is much too small and does not reflect recent
> > additions to the architecture. For instance, when AVX-512 states are in
> > use, the signal frame size can be 3.5KB while MINSIGSTKSZ remains 2KB.
> > 
> > The bug report [4] explains this as an ABI issue. The small MINSIGSTKSZ can
> > cause user stack overflow when delivering a signal.
> 
> >   uapi: Define the aux vector AT_MINSIGSTKSZ
> >   x86/signal: Introduce helpers to get the maximum signal frame size
> >   x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ
> >   selftest/sigaltstack: Use the AT_MINSIGSTKSZ aux vector if available
> >   x86/signal: Detect and prevent an alternate signal stack overflow
> >   selftest/x86/signal: Include test cases for validating sigaltstack
> 
> So this looks really complicated, is this justified?
> 
> Why not just internally round up sigaltstack size if it's too small? 
> This would be more robust, as it would fix applications that use 
> MINSIGSTKSZ but don't use the new AT_MINSIGSTKSZ facility.
> 
> I.e. does AT_MINSIGSTKSZ have any other uses than avoiding the 
> segfault if MINSIGSTKSZ is used to create a small signal stack?

I.e. if the kernel sees a too small ->ss_size in sigaltstack() it 
would ignore ->ss_sp and mmap() a new sigaltstack instead and use that 
for the signal handler stack.

This would automatically make MINSIGSTKSZ - and other too small sizes 
work today, and in the future.

But the question is, is there user-space usage of sigaltstacks that 
relies on controlling or reading the contents of the stack?

longjmp using programs perhaps?

Thanks,

	Ingo