All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	PaX Team <pageexec@freemail.hu>, Jann Horn <jannh@google.com>,
	Eric Biggers <ebiggers3@gmail.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Hans Liljestrand <ishkamiel@gmail.com>,
	David Windsor <dwindsor@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	arozansk@redhat.com, Manfred Spraul <manfred@colorfullife.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	"x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"David S. Miller" <davem@davemloft.net>,
	Rik van Riel <riel@redhat.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v5 0/3] Implement fast refcount overflow protection
Date: Wed, 31 May 2017 05:27:32 -0700	[thread overview]
Message-ID: <20170531122732.GA24923@linux-80c1.suse> (raw)
In-Reply-To: <1496180392-98718-1-git-send-email-keescook@chromium.org>

On Tue, 30 May 2017, Kees Cook wrote:

>A new patch has been added at the start of this series to make the default
>refcount_t implementation just use an unchecked atomic_t implementation,
>since many kernel subsystems want to be able to opt out of the full
>validation, since it includes a small performance overhead. When enabling
>CONFIG_REFCOUNT_FULL, the full validation is used.
>
>The other two patches provide overflow protection on x86 without incurring
>a performance penalty. The changelog for patch 3 is reproduced here for
>details:

To be sure I'm getting this right, after this all archs with the exception
of x86 will use the regular atomic_t ("unsecure") flavor, right?

Thanks,
Davidlohr

WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	PaX Team <pageexec@freemail.hu>, Jann Horn <jannh@google.com>,
	Eric Biggers <ebiggers3@gmail.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Hans Liljestrand <ishkamiel@gmail.com>,
	David Windsor <dwindsor@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	arozansk@redhat.com, Manfred Spraul <manfred@colorfullife.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v5 0/3] Implement fast refcount overflow protection
Date: Wed, 31 May 2017 05:27:32 -0700	[thread overview]
Message-ID: <20170531122732.GA24923@linux-80c1.suse> (raw)
In-Reply-To: <1496180392-98718-1-git-send-email-keescook@chromium.org>

On Tue, 30 May 2017, Kees Cook wrote:

>A new patch has been added at the start of this series to make the default
>refcount_t implementation just use an unchecked atomic_t implementation,
>since many kernel subsystems want to be able to opt out of the full
>validation, since it includes a small performance overhead. When enabling
>CONFIG_REFCOUNT_FULL, the full validation is used.
>
>The other two patches provide overflow protection on x86 without incurring
>a performance penalty. The changelog for patch 3 is reproduced here for
>details:

To be sure I'm getting this right, after this all archs with the exception
of x86 will use the regular atomic_t ("unsecure") flavor, right?

Thanks,
Davidlohr

WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	PaX Team <pageexec@freemail.hu>, Jann Horn <jannh@google.com>,
	Eric Biggers <ebiggers3@gmail.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Hans Liljestrand <ishkamiel@gmail.com>,
	David Windsor <dwindsor@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	arozansk@redhat.com, Manfred Spraul <manfred@colorfullife.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	"x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"David S. Miller" <davem@davemloft.net>,
	Rik van Riel <riel@redhat.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v5 0/3] Implement fast refcount overflow protection
Date: Wed, 31 May 2017 05:27:32 -0700	[thread overview]
Message-ID: <20170531122732.GA24923@linux-80c1.suse> (raw)
Message-ID: <20170531122732.Rqsji3NMCszjbNfCUu2l1qrkWlJye115MpORNvZPihY@z> (raw)
In-Reply-To: <1496180392-98718-1-git-send-email-keescook@chromium.org>

On Tue, 30 May 2017, Kees Cook wrote:

>A new patch has been added at the start of this series to make the default
>refcount_t implementation just use an unchecked atomic_t implementation,
>since many kernel subsystems want to be able to opt out of the full
>validation, since it includes a small performance overhead. When enabling
>CONFIG_REFCOUNT_FULL, the full validation is used.
>
>The other two patches provide overflow protection on x86 without incurring
>a performance penalty. The changelog for patch 3 is reproduced here for
>details:

To be sure I'm getting this right, after this all archs with the exception
of x86 will use the regular atomic_t ("unsecure") flavor, right?

Thanks,
Davidlohr

  parent reply	other threads:[~2017-05-31 12:27 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-30 21:39 [kernel-hardening] [PATCH v5 0/3] Implement fast refcount overflow protection Kees Cook
2017-05-30 21:39 ` Kees Cook
2017-05-30 21:39 ` Kees Cook
2017-05-30 21:39 ` [kernel-hardening] [PATCH v5 1/3] refcount: Create unchecked atomic_t implementation Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-05-31 10:45   ` [kernel-hardening] " Reshetova, Elena
2017-05-31 10:45     ` Reshetova, Elena
2017-05-31 10:45     ` Reshetova, Elena
2017-05-31 11:09     ` [kernel-hardening] " Peter Zijlstra
2017-05-31 11:09       ` Peter Zijlstra
2017-05-31 11:09       ` Peter Zijlstra
2017-06-01 14:43       ` [kernel-hardening] " Kees Cook
2017-06-01 14:43         ` Kees Cook
2017-06-01 14:43         ` Kees Cook
2017-05-30 21:39 ` [kernel-hardening] [PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-05-31 11:13   ` [kernel-hardening] " Peter Zijlstra
2017-05-31 11:13     ` Peter Zijlstra
2017-05-31 11:13     ` Peter Zijlstra
2017-05-31 13:17     ` [kernel-hardening] " Kees Cook
2017-05-31 13:17       ` Kees Cook
2017-05-31 13:17       ` Kees Cook
2017-05-31 14:03       ` [kernel-hardening] " Peter Zijlstra
2017-05-31 14:03         ` Peter Zijlstra
2017-05-31 14:03         ` Peter Zijlstra
2017-05-31 16:09         ` [kernel-hardening] " Kees Cook
2017-05-31 16:09           ` Kees Cook
2017-05-31 16:09           ` Kees Cook
2017-05-30 21:39 ` [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-05-30 21:39   ` Kees Cook
2017-06-29  4:13   ` [kernel-hardening] " Li Kun
2017-06-29  4:13     ` Li Kun
2017-06-29  4:13     ` Li Kun
2017-06-29 22:05     ` Kees Cook
2017-06-29 22:05       ` Kees Cook
2017-06-30  2:42       ` [kernel-hardening] " Li Kun
2017-06-30  2:42         ` Li Kun
2017-06-30  2:42         ` Li Kun
2017-06-30  3:58         ` [kernel-hardening] " Kees Cook
2017-06-30  3:58           ` Kees Cook
2017-05-31 12:27 ` Davidlohr Bueso [this message]
2017-05-31 12:27   ` [PATCH v5 0/3] " Davidlohr Bueso
2017-05-31 12:27   ` Davidlohr Bueso
2017-05-31 13:20   ` [kernel-hardening] " Kees Cook
2017-05-31 13:20     ` Kees Cook
2017-05-31 13:20     ` Kees Cook

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=20170531122732.GA24923@linux-80c1.suse \
    --to=dave@stgolabs.net \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=arozansk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=davem@davemloft.net \
    --cc=dwindsor@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=ebiggers3@gmail.com \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=ishkamiel@gmail.com \
    --cc=jannh@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pageexec@freemail.hu \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=serge@hallyn.com \
    --cc=x86@kernel.org \
    /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: link
Be 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.