From: Borislav Petkov <bp@alien8.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: "Bae, Chang Seok" <chang.seok.bae@intel.com>,
Andy Lutomirski <luto@kernel.org>,
"Cooper, Andrew" <andrew.cooper3@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
"Gross, Jurgen" <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>, X86 ML <x86@kernel.org>,
"Brown, Len" <len.brown@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"H. J. Lu" <hjl.tools@gmail.com>,
Dave Martin <Dave.Martin@arm.com>, Jann Horn <jannh@google.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Carlos O'Donell <carlos@redhat.com>,
"Luck, Tony" <tony.luck@intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
libc-alpha <libc-alpha@sourceware.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow
Date: Mon, 3 May 2021 13:17:02 +0200 [thread overview]
Message-ID: <YI/brhlCsKd4PTDP@zn.tnic> (raw)
In-Reply-To: <877dkg8jv6.fsf@oldenburg.str.redhat.com>
On Mon, May 03, 2021 at 07:30:21AM +0200, Florian Weimer wrote:
> Just to be clear, I'm worried about the case where an application
> installs a stack overflow handler, but stack overflow does not regularly
> happen at run time. GNU m4 is an example. Today, for most m4 scripts,
> it's totally fine to have an alternative signal stack which is too
> small. If the kernel returned an error for the sigaltstack call, m4
> wouldn't start anymore, independently of the script. Which is worse
> than memory corruption with some scripts, I think.
Oh lovely.
>
> > Or is this use case obsolete and this is not what people do at all?
>
> It's widely used in currently-maintained software. It's the only way to
> recover from stack overflows without boundary checks on every function
> call.
>
> Does the alternative signal stack actually have to contain the siginfo_t
> data? I don't think it has to be contiguous. Maybe the kernel could
> allocate and map something behind the processes back if the sigaltstack
> region is too small?
So there's an attempt floating around to address this:
https://lkml.kernel.org/r/20210422044856.27250-1-chang.seok.bae@intel.com
esp patch 3.
I'd appreciate having a look and sanity-checking this whether it makes
sense and could be useful this way...
> And for the stack overflow handler, the kernel could treat SIGSEGV with
> a sigaltstack region that is too small like the SIG_DFL handler. This
> would make m4 work again.
/me searches a bit about SIG_DFL...
Do you mean that the default action in this case should be what SIGSEGV
does by default - to dump core?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-05-03 11:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 6:52 [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size Chang S. Bae
2021-03-16 6:52 ` [PATCH v7 1/6] uapi: Define the aux vector AT_MINSIGSTKSZ Chang S. Bae
2021-03-16 6:52 ` Chang S. Bae
2021-03-16 6:52 ` [PATCH v7 2/6] x86/signal: Introduce helpers to get the maximum signal frame size Chang S. Bae
2021-03-16 6:52 ` [PATCH v7 3/6] x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ Chang S. Bae
2021-03-16 6:52 ` [PATCH v7 4/6] selftest/sigaltstack: Use the AT_MINSIGSTKSZ aux vector if available Chang S. Bae
2021-03-16 6:52 ` [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow Chang S. Bae
2021-03-16 11:52 ` Borislav Petkov
2021-03-16 18:26 ` Bae, Chang Seok
2021-03-25 16:20 ` Borislav Petkov
2021-03-25 17:21 ` Bae, Chang Seok
2021-03-25 20:14 ` Florian Weimer
2021-03-25 18:13 ` Andy Lutomirski
2021-03-25 18:54 ` Borislav Petkov
2021-03-25 21:11 ` Bae, Chang Seok
2021-03-25 21:27 ` Borislav Petkov
2021-03-26 4:56 ` Andy Lutomirski
2021-03-26 10:30 ` Borislav Petkov
2021-04-12 22:30 ` Bae, Chang Seok
2021-04-14 10:12 ` Borislav Petkov
2021-04-14 11:30 ` Florian Weimer
2021-04-14 12:06 ` Borislav Petkov
2021-05-03 5:30 ` Florian Weimer
2021-05-03 11:17 ` Borislav Petkov [this message]
2021-03-26 4:58 ` Andy Lutomirski
2021-03-16 6:52 ` [PATCH v7 6/6] selftest/x86/signal: Include test cases for validating sigaltstack Chang S. Bae
2021-03-17 10:06 ` [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size Ingo Molnar
2021-03-17 10:44 ` Ingo Molnar
2021-03-19 18:12 ` Len Brown
2021-03-20 17:32 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YI/brhlCsKd4PTDP@zn.tnic \
--to=bp@alien8.de \
--cc=Dave.Martin@arm.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=carlos@redhat.com \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@intel.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=jannh@google.com \
--cc=jgross@suse.com \
--cc=len.brown@intel.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ravi.v.shankar@intel.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.