Date: Wed, 25 Mar 2020 12:15:12 +0000 From: "Reshetova, Elena" <elena.reshetova@...el.com> To: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com> CC: Thomas Gleixner <tglx@...utronix.de>, the arch/x86 maintainers <x86@...nel.org>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Catalin Marinas <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>, Mark Rutland <mark.rutland@....com>, "Alexander Potapenko" <glider@...gle.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Linux-MM <linux-mm@...ck.org>, kernel list <linux-kernel@...r.kernel.org> Subject: RE: [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall > > Also, are you sure that it isn't possible to make the syscall that > > leaked its stack pointer never return to userspace (via ptrace or > > SIGSTOP or something like that), and therefore never realign its > > stack, while keeping some controlled data present on the syscall's > > stack? How would you reliably detect that a stack pointer has been leaked to userspace while it has been in a syscall? Does not seem to be a trivial task to me. Best Regards, Elena.
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.