From: Kees Cook <keescook@chromium.org> To: Will Deacon <will.deacon@arm.com>, Greg KH <gregkh@linuxfoundation.org> Cc: Peter Zijlstra <peterz@infradead.org>, Elena Reshetova <elena.reshetova@intel.com>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Arnd Bergmann <arnd@arndb.de>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <h.peter.anvin@intel.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Date: Thu, 10 Nov 2016 13:01:41 -0800 [thread overview] Message-ID: <CAGXu5jL0m8_x-eBPQPBvj_O_JRXmh=nc87L0rpPkYUEo+jK97A@mail.gmail.com> (raw) In-Reply-To: <20161110204838.GE17134@arm.com> On Thu, Nov 10, 2016 at 12:48 PM, Will Deacon <will.deacon@arm.com> wrote: > On Thu, Nov 10, 2016 at 09:37:49PM +0100, Peter Zijlstra wrote: >> On Thu, Nov 10, 2016 at 10:24:35PM +0200, Elena Reshetova wrote: >> > This series brings the PaX/Grsecurity PAX_REFCOUNT >> > feature support to the upstream kernel. All credit for the >> > feature goes to the feature authors. >> > >> > The name of the upstream feature is HARDENED_ATOMIC >> > and it is configured using CONFIG_HARDENED_ATOMIC and >> > HAVE_ARCH_HARDENED_ATOMIC. >> > >> > This series only adds x86 support; other architectures are expected >> > to add similar support gradually. >> > >> > More information about the feature can be found in the following >> > commit messages. >> >> No, this should be here. As it stands this is completely without >> content. >> >> In any case, NAK on this approach. Its the wrong way around. >> >> _IF_ you want to do a non-wrapping variant, it must not be the default. >> >> Since you need to audit every single atomic_t user in the kernel anyway, >> it doesn't matter. But changing atomic_t to non-wrap by default is not >> robust, if you forgot one, you can then trivially dos the kernel. > > Completely agreed. > > Whilst I understand that you're addressing an important and commonly > exploited vulnerability, this really needs to be opt-in rather than > opt-out given the prevalence of atomic_t users in the kernel. Having a > "hardened" kernel that does the wrong thing is useless. I (obviously) disagree. It's not useless. Such a kernel is totally safe against refcount errors and would be exposed to DoS issues only where mistakes were made. This is the fundamental shift here: - we already have exploitable privilege escalation refcount flaws on a regular basis - this changes things to have zero exploitable refcount flaws now and into the future - the risk is bugs leading to DoS instead of the risk of exploitable flaws That's the real trade. >> That said, I still don't much like this. >> >> I would much rather you make kref useful and use that. It still means >> you get to audit all refcounts in the kernel, but hey, you had to do >> that anyway. > > What needs to happen to kref to make it useful? Like many others, I've > been guilty of using atomic_t for refcounts in the past. That's the point: expecting everyone to get this right and not miss mistake from now into the future is not a solution. This solves the privilege escalation issue for refcounts now and forever. -Kees -- Kees Cook Nexus Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Will Deacon <will.deacon@arm.com>, Greg KH <gregkh@linuxfoundation.org> Cc: Peter Zijlstra <peterz@infradead.org>, Elena Reshetova <elena.reshetova@intel.com>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Arnd Bergmann <arnd@arndb.de>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <h.peter.anvin@intel.com>, LKML <linux-kernel@vger.kernel.org> Subject: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Date: Thu, 10 Nov 2016 13:01:41 -0800 [thread overview] Message-ID: <CAGXu5jL0m8_x-eBPQPBvj_O_JRXmh=nc87L0rpPkYUEo+jK97A@mail.gmail.com> (raw) In-Reply-To: <20161110204838.GE17134@arm.com> On Thu, Nov 10, 2016 at 12:48 PM, Will Deacon <will.deacon@arm.com> wrote: > On Thu, Nov 10, 2016 at 09:37:49PM +0100, Peter Zijlstra wrote: >> On Thu, Nov 10, 2016 at 10:24:35PM +0200, Elena Reshetova wrote: >> > This series brings the PaX/Grsecurity PAX_REFCOUNT >> > feature support to the upstream kernel. All credit for the >> > feature goes to the feature authors. >> > >> > The name of the upstream feature is HARDENED_ATOMIC >> > and it is configured using CONFIG_HARDENED_ATOMIC and >> > HAVE_ARCH_HARDENED_ATOMIC. >> > >> > This series only adds x86 support; other architectures are expected >> > to add similar support gradually. >> > >> > More information about the feature can be found in the following >> > commit messages. >> >> No, this should be here. As it stands this is completely without >> content. >> >> In any case, NAK on this approach. Its the wrong way around. >> >> _IF_ you want to do a non-wrapping variant, it must not be the default. >> >> Since you need to audit every single atomic_t user in the kernel anyway, >> it doesn't matter. But changing atomic_t to non-wrap by default is not >> robust, if you forgot one, you can then trivially dos the kernel. > > Completely agreed. > > Whilst I understand that you're addressing an important and commonly > exploited vulnerability, this really needs to be opt-in rather than > opt-out given the prevalence of atomic_t users in the kernel. Having a > "hardened" kernel that does the wrong thing is useless. I (obviously) disagree. It's not useless. Such a kernel is totally safe against refcount errors and would be exposed to DoS issues only where mistakes were made. This is the fundamental shift here: - we already have exploitable privilege escalation refcount flaws on a regular basis - this changes things to have zero exploitable refcount flaws now and into the future - the risk is bugs leading to DoS instead of the risk of exploitable flaws That's the real trade. >> That said, I still don't much like this. >> >> I would much rather you make kref useful and use that. It still means >> you get to audit all refcounts in the kernel, but hey, you had to do >> that anyway. > > What needs to happen to kref to make it useful? Like many others, I've > been guilty of using atomic_t for refcounts in the past. That's the point: expecting everyone to get this right and not miss mistake from now into the future is not a solution. This solves the privilege escalation issue for refcounts now and forever. -Kees -- Kees Cook Nexus Security
next prev parent reply other threads:[~2016-11-10 21:01 UTC|newest] Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-10 20:24 [kernel-hardening] [RFC v4 PATCH 00/13] HARDENED_ATOMIC Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 01/13] Add architecture independent hardened atomic base Elena Reshetova 2016-11-10 20:41 ` [kernel-hardening] " David Windsor 2016-11-10 21:09 ` Peter Zijlstra 2016-11-10 21:35 ` Peter Zijlstra 2016-11-11 9:06 ` Reshetova, Elena 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 02/13] percpu-refcount: leave atomic counter unprotected Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 03/13] kernel: identify wrapping atomic usage Elena Reshetova 2016-11-10 21:58 ` [kernel-hardening] " Peter Zijlstra 2016-11-11 8:49 ` [kernel-hardening] " Reshetova, Elena 2016-11-19 13:28 ` [kernel-hardening] " Paul E. McKenney 2016-11-19 21:39 ` Kees Cook 2016-11-21 20:13 ` Paul E. McKenney 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 04/13] mm: " Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 05/13] fs: " Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 06/13] net: " Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 07/13] net: atm: " Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 08/13] security: " Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 09/13] drivers: identify wrapping atomic usage (part 1/2) Elena Reshetova 2016-11-10 21:48 ` [kernel-hardening] " Will Deacon 2016-11-11 8:57 ` [kernel-hardening] " Reshetova, Elena 2016-11-11 12:35 ` Mark Rutland 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 10/13] drivers: identify wrapping atomic usage (part 2/2) Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 11/13] x86: identify wrapping atomic usage Elena Reshetova 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 12/13] x86: implementation for HARDENED_ATOMIC Elena Reshetova 2016-11-10 20:40 ` [kernel-hardening] " Peter Zijlstra 2016-11-10 21:04 ` Kees Cook 2016-11-10 21:16 ` Peter Zijlstra 2016-11-10 21:32 ` Kees Cook 2016-11-10 21:46 ` Peter Zijlstra 2016-11-10 22:50 ` Peter Zijlstra 2016-11-10 23:07 ` Kees Cook 2016-11-10 23:30 ` Peter Zijlstra 2016-11-11 9:32 ` [kernel-hardening] " Reshetova, Elena 2016-11-11 10:29 ` [kernel-hardening] " Peter Zijlstra 2016-11-11 18:00 ` Kees Cook 2016-11-11 20:19 ` Peter Zijlstra 2016-11-10 21:33 ` Peter Zijlstra 2016-11-11 9:20 ` [kernel-hardening] " Reshetova, Elena 2016-11-10 20:24 ` [kernel-hardening] [RFC v4 PATCH 13/13] lkdtm: add tests for atomic over-/underflow Elena Reshetova 2016-11-10 20:37 ` [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra 2016-11-10 20:37 ` [kernel-hardening] " Peter Zijlstra 2016-11-10 20:48 ` Will Deacon 2016-11-10 20:48 ` [kernel-hardening] " Will Deacon 2016-11-10 21:01 ` Kees Cook [this message] 2016-11-10 21:01 ` Kees Cook 2016-11-10 21:23 ` David Windsor 2016-11-10 21:27 ` Kees Cook 2016-11-10 21:27 ` Kees Cook 2016-11-10 21:39 ` David Windsor 2016-11-10 21:39 ` David Windsor 2016-11-10 21:39 ` Peter Zijlstra 2016-11-10 21:13 ` Peter Zijlstra 2016-11-10 21:13 ` [kernel-hardening] " Peter Zijlstra 2016-11-10 21:23 ` Kees Cook 2016-11-10 21:23 ` [kernel-hardening] " Kees Cook 2016-11-11 4:25 ` Rik van Riel 2016-11-10 22:27 ` Greg KH 2016-11-10 23:15 ` Kees Cook 2016-11-10 23:15 ` Kees Cook 2016-11-10 23:38 ` Greg KH 2016-11-10 23:38 ` Greg KH 2016-11-11 7:50 ` David Windsor 2016-11-11 17:43 ` Kees Cook 2016-11-11 17:46 ` Peter Zijlstra 2016-11-11 18:04 ` Kees Cook 2016-11-11 20:17 ` Peter Zijlstra 2016-11-14 20:31 ` Kees Cook 2016-11-15 8:01 ` Peter Zijlstra 2016-11-15 16:50 ` Rik van Riel 2016-11-15 17:23 ` Kees Cook 2016-11-16 17:09 ` Rik van Riel 2016-11-16 17:32 ` Peter Zijlstra 2016-11-16 17:41 ` Rik van Riel 2016-11-16 17:34 ` Reshetova, Elena 2016-11-17 8:37 ` Peter Zijlstra 2016-11-17 9:04 ` Reshetova, Elena 2016-11-17 9:36 ` Peter Zijlstra 2016-11-17 9:36 ` Julia Lawall 2016-11-17 10:16 ` Peter Zijlstra 2016-11-17 11:19 ` Mark Rutland 2016-11-17 11:32 ` Julia Lawall 2016-11-17 12:59 ` Julia Lawall 2016-11-11 18:47 ` Mark Rutland 2016-11-11 19:39 ` Will Deacon 2016-11-11 18:31 ` Mark Rutland 2016-11-11 20:05 ` Peter Zijlstra 2016-11-15 10:36 ` Mark Rutland 2016-11-15 11:21 ` Peter Zijlstra 2016-11-15 18:02 ` Mark Rutland 2016-11-10 23:57 ` Peter Zijlstra 2016-11-10 23:57 ` Peter Zijlstra 2016-11-11 0:29 ` Colin Vidal 2016-11-11 12:41 ` Mark Rutland 2016-11-11 12:47 ` Peter Zijlstra 2016-11-11 13:00 ` Peter Zijlstra 2016-11-11 14:39 ` Thomas Gleixner 2016-11-11 14:48 ` Peter Zijlstra 2016-11-11 23:07 ` Peter Zijlstra 2016-11-13 11:03 ` Greg KH 2016-11-13 11:03 ` Greg KH 2016-11-10 20:56 ` Kees Cook 2016-11-10 20:56 ` [kernel-hardening] " Kees Cook 2016-11-11 3:20 ` David Windsor
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='CAGXu5jL0m8_x-eBPQPBvj_O_JRXmh=nc87L0rpPkYUEo+jK97A@mail.gmail.com' \ --to=keescook@chromium.org \ --cc=arnd@arndb.de \ --cc=elena.reshetova@intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=h.peter.anvin@intel.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ /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: linkBe 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.