From: Kees Cook <keescook@chromium.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Sami Tolvanen <samitolvanen@google.com>,
Jann Horn <jannh@google.com>
Subject: Re: x86/irq: Make run_on_irqstack_cond() typesafe
Date: Wed, 23 Sep 2020 12:19:57 -0700 [thread overview]
Message-ID: <202009231209.F5F3999D@keescook> (raw)
In-Reply-To: <87pn6eb5tv.fsf@nanos.tec.linutronix.de>
On Tue, Sep 22, 2020 at 09:58:52AM +0200, Thomas Gleixner wrote:
> -void asm_call_on_stack(void *sp, void *func, void *arg);
> +void asm_call_on_stack(void *sp, void (*func)(void), void *arg);
> +void asm_call_sysvec_on_stack(void *sp, void (*func)(struct pt_regs *regs),
> + struct pt_regs *regs);
> +void asm_call_irq_on_stack(void *sp, void (*func)(struct irq_desc *desc),
> + struct irq_desc *desc);
Eeeh, err. So, this is nice for the CFI case, but can we instead just
inline asm_call_on_stack() instead? Having any of these as distinct
functions in the kernel is really not safe: it provides a trivial
global stack-pivot[1] function for use in ROP attacks, which is one
of the central requirements for mounting such attacks. This allows a
completely arbitrary sp argument, function, and first argument. :(
Much better would be to keep asm_call_on_stack() as an inline so the
stack pointer is always coming from percpu variables, and to have the
irq_count actually checked (i.e. freak out if it falls below zero to
catch jumps into the middle of a function when an attempt to bypass the
load from the percpu area happens). I would expect this form to be much
robust:
inc
load sp from per-cpu
pivot sp
make call
restore sp
WARN(dec_and_test)
-Kees
[1] https://security.stackexchange.com/questions/44418/return-oriented-programming-how-to-find-a-stack-pivot
--
Kees Cook
next prev parent reply other threads:[~2020-09-23 19:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 7:58 x86/irq: Make run_on_irqstack_cond() typesafe Thomas Gleixner
2020-09-22 18:45 ` Sami Tolvanen
2020-09-22 20:38 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2020-09-23 19:19 ` Kees Cook [this message]
2020-09-23 19:36 ` Jann Horn
2020-09-25 16:36 ` kernel test robot
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=202009231209.F5F3999D@keescook \
--to=keescook@chromium.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tglx@linutronix.de \
--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.