[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2017 12:57:42 -0800
From: Kees Cook <keescook@...omium.org>
To: Greg KH <gregkh@...uxfoundation.org>, Peter Zijlstra <peterz@...radead.org>
Cc: Elena Reshetova <elena.reshetova@...el.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <h.peter.anvin@...el.com>, Will Deacon <will.deacon@....com>,
David Windsor <dwindsor@...il.com>
Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage
On Wed, Jan 18, 2017 at 12:35 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Wed, Jan 18, 2017 at 12:06:19PM -0800, Kees Cook wrote:
>> On Wed, Jan 18, 2017 at 2:30 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> > On Wed, Jan 18, 2017 at 11:11:29AM +0200, Elena Reshetova wrote:
>> >> Changes since v1:
>> >> - kref INIT fixes are moved to a proper separate commit
>> >> - Peter's commits are now properly integrated into series
>> >> - various small fixes are incorporated based on testing
>> >> results and feedback
>> >>
>> >> This patch series is build on top of Peter's Zijlstra patches
>> >> that provide refcount_t type and API definition.
>> >> The rest of patches convert various places of kernel subsystems
>> >> where atomic_t was used for reference counting to new refcount_t type and API.
>> >> By doing this, we make sure that underflows and overflows
>> >> cannot occur in these places and therefore no use-after-free situation
>> >> can be created and misused by an attacker.
>> >
>> > Your first 7 patches are fine, and most of them are already in the tip
>> > tree and getting use in linux-next now. I'd recommend submitting the
>>
>> Where do you see this? I haven't seen refcount_t land in -next yet.
>
> The patches leading up to refcount_t are in the tip tree.
Ah, I see it here:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=locking/core
I wonder why it hasn't appeared in -next.
>> Should I carry these in the KSPP tree, or who should take them?
>
> I think the refcount_t patch should also go to tip given it depends on
> the kref patches. But that's up to Peter, he would know best...
Yeah, agreed. Peter, can you add that to tip? Then we can base more work off it.
Thanks!
-Kees
--
Kees Cook
Nexus Security
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.
