[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Feb 2019 09:23:43 -0800
From: Kees Cook <keescook@...omium.org>
To: "Perla, Enrico" <enrico.perla@...el.com>
Cc: Andy Lutomirski <luto@...capital.net>, "Reshetova, Elena" <elena.reshetova@...el.com>,
Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"tytso@....edu" <tytso@....edu>
Subject: Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon
system call
On Thu, Feb 21, 2019 at 1:35 AM Perla, Enrico <enrico.perla@...el.com> wrote:
> > It does seem that using a flaw to attack one's own registers is rather
> > pointless. Maybe we'll eat our words, but for now, I'd agree.
> >
>
> You don't attack your own registers, you use them to load controlled data to the kernel and emulate structures or similar at any stage of an exploit, bypassing SMAP and co.
Given all the rewriting of the syscall entry code over the last few
years, perhaps I'm missing something. My understanding was that at
syscall entry we do effectively this:
- save pt_regs
- clear all registers not needed for a syscall
- run syscall
- restore pt_regs (excepting syscall return value)
I didn't think pt_regs got used during the syscall? In looking more
closely, I see some current_pt_regs() in some paths, but again: what's
the attack you're thinking of that isn't directly overlapped with
existing control over registers at entry or via ptrace?
--
Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
