From: Kees Cook <keescook@chromium.org> To: Peter Zijlstra <peterz@infradead.org>, Greg KH <gregkh@linuxfoundation.org> Cc: 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>, Will Deacon <will.deacon@arm.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Date: Thu, 10 Nov 2016 12:56:09 -0800 [thread overview] Message-ID: <CAGXu5j+4uod4UFAZNj5K=At3x2MUODstfUVMbDFguh5FM_S7cA@mail.gmail.com> (raw) In-Reply-To: <20161110203749.GV3117@twins.programming.kicks-ass.net> On Thu, Nov 10, 2016 at 12:37 PM, Peter Zijlstra <peterz@infradead.org> 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. Unfortunately, we have to do it this way because there are so many misuses of atomic_t, and they just keep appearing. We can't do opt-in protections for the kernel -- we need to protect atomic_t and opt OUT of the protection where it's not needed. We must change the kernel culture to making things secure-by-default. Without this, we're wasting our time and continuing to leave people vulnerable every time some new driver lands that refcounts with atomic_t. Since education is proven to not work, we have to harden the _infrastructure_ of the kernel, of which atomic_t is a part. > 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. Correct: everything must be audited in either case. However, making a mistake using opt-out means a DoS. Making a mistake using opt-in means an exploitable kernel escalation. We must have the courage to recognize this distinction. Right now, every refcount mistake is an exploitable kernel flaw. Reducing this to a DoS is a giant improvement. > 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. This has already been suggested in the past, and suffers from the same opt-in problem. I'll let Greg comment on it, though, as he's agreed with going opt-out in the past when reviewing this work. -Kees -- Kees Cook Nexus Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Peter Zijlstra <peterz@infradead.org>, Greg KH <gregkh@linuxfoundation.org> Cc: 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>, Will Deacon <will.deacon@arm.com>, LKML <linux-kernel@vger.kernel.org> Subject: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Date: Thu, 10 Nov 2016 12:56:09 -0800 [thread overview] Message-ID: <CAGXu5j+4uod4UFAZNj5K=At3x2MUODstfUVMbDFguh5FM_S7cA@mail.gmail.com> (raw) In-Reply-To: <20161110203749.GV3117@twins.programming.kicks-ass.net> On Thu, Nov 10, 2016 at 12:37 PM, Peter Zijlstra <peterz@infradead.org> 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. Unfortunately, we have to do it this way because there are so many misuses of atomic_t, and they just keep appearing. We can't do opt-in protections for the kernel -- we need to protect atomic_t and opt OUT of the protection where it's not needed. We must change the kernel culture to making things secure-by-default. Without this, we're wasting our time and continuing to leave people vulnerable every time some new driver lands that refcounts with atomic_t. Since education is proven to not work, we have to harden the _infrastructure_ of the kernel, of which atomic_t is a part. > 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. Correct: everything must be audited in either case. However, making a mistake using opt-out means a DoS. Making a mistake using opt-in means an exploitable kernel escalation. We must have the courage to recognize this distinction. Right now, every refcount mistake is an exploitable kernel flaw. Reducing this to a DoS is a giant improvement. > 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. This has already been suggested in the past, and suffers from the same opt-in problem. I'll let Greg comment on it, though, as he's agreed with going opt-out in the past when reviewing this work. -Kees -- Kees Cook Nexus Security
next prev parent reply other threads:[~2016-11-10 20:56 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 2016-11-10 21:01 ` [kernel-hardening] " 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 [this message] 2016-11-10 20:56 ` 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='CAGXu5j+4uod4UFAZNj5K=At3x2MUODstfUVMbDFguh5FM_S7cA@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.