|
Message-ID: <58FF3273.5306.1C99E565@pageexec.freemail.hu> Date: Tue, 25 Apr 2017 13:26:43 +0200 From: "PaX Team" <pageexec@...email.hu> To: Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org> CC: linux-kernel@...r.kernel.org, Eric Biggers <ebiggers3@...il.com>, Christoph Hellwig <hch@...radead.org>, "axboe@...nel.dk" <axboe@...nel.dk>, James Bottomley <James.Bottomley@...senpartnership.com>, Elena Reshetova <elena.reshetova@...el.com>, Hans Liljestrand <ishkamiel@...il.com>, David Windsor <dwindsor@...il.com>, x86@...nel.org, Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jann Horn <jann@...jh.net>, davem@...emloft.net, linux-arch@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling On 25 Apr 2017 at 12:23, Peter Zijlstra wrote: > So what avoids this: simple, you noted it yourself in your previous mail: > Well, your setup (panic_on_warn et al) would have it panic the box. That > will effectively stop the exploit by virtue of stopping everything. with that in mind the actual code looks like this: > CPU0 CPU1 > > > lock inc %[val]; # 0x7fffffff > jo 2f >1: ... > > lock dec %[val]; # 0x80000000 > jo 2f > 1: ... > > > > >2: mov $0x7fffffff, %[val] panic() > jmp 1b > > 2: mov $0x80000000, %[val] panic() > jmp 1b > ... and we never get this far.
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.