Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread Linus Torvalds
On Tue, Nov 28, 2017 at 10:04 AM, Linus Torvalds wrote: > > If we really get failures, we can do that. Anyway, it's pushed out now so people can test whatever workflows they have. As mentioned, I doubt anybody cares. That file is already conditional on CONFIG_STACKTRACE, and while that may be so

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread Linus Torvalds
On Tue, Nov 28, 2017 at 9:41 AM, Joe Perches wrote: > > Perhaps if there are really tools that parse this > the [] should be kept the same too. If we really get failures, we can do that. But since the width is already different on 32-bit and 64-bit, I seriously doubt there are any tools that wou

RE: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread David Laight
From: Linus Torvalds > Sent: 28 November 2017 17:33 > > On Mon, Nov 27, 2017 at 10:26 PM, Eric W. Biederman > wrote: > >> > >> Oh well, I just did /proc//stack by making it just print 0 > >> unconditionally rather than the hex number. > > > > Patch? > > Oh, apparently I never pushed out yesterda

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread Joe Perches
On Tue, 2017-11-28 at 09:33 -0800, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 10:26 PM, Eric W. Biederman > wrote: > > > > > > Oh well, I just did /proc//stack by making it just print 0 > > > unconditionally rather than the hex number. > > > > Patch? > > Oh, apparently I never pushed out y

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread Linus Torvalds
On Mon, Nov 27, 2017 at 10:26 PM, Eric W. Biederman wrote: >> >> Oh well, I just did /proc//stack by making it just print 0 >> unconditionally rather than the hex number. > > Patch? Oh, apparently I never pushed out yesterday. The patch literally just affects the (useless) hex number. So: c

RE: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-28 Thread David Laight
From: Eric W. Biederman > Sent: 28 November 2017 06:27 > Linus Torvalds writes: > > > On Mon, Nov 27, 2017 at 4:03 PM, Linus Torvalds > > wrote: > >> > >> So the big remaining ones for me are the /proc//stack (stack > >> pointers) and the /proc/net/* ones. > >> > >> I'm a bit disappointed that t

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-27 Thread Eric W. Biederman
Linus Torvalds writes: > On Mon, Nov 27, 2017 at 4:03 PM, Linus Torvalds > wrote: >> >> So the big remaining ones for me are the /proc//stack (stack >> pointers) and the /proc/net/* ones. >> >> I'm a bit disappointed that those haven't been fixed already and >> aren't even in this series.. > > O

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-27 Thread Tobin C. Harding
On Mon, Nov 27, 2017 at 04:57:18PM -0800, Kees Cook wrote: > On Mon, Nov 27, 2017 at 3:40 PM, Tobin C. Harding wrote: > > Linus, > > > > I know you are bored of this patch set already and this pits your vast > > experience against my eight months kernel dev experience ;) > > > > I humbly maintain

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-27 Thread Linus Torvalds
On Mon, Nov 27, 2017 at 4:03 PM, Linus Torvalds wrote: > > So the big remaining ones for me are the /proc//stack (stack > pointers) and the /proc/net/* ones. > > I'm a bit disappointed that those haven't been fixed already and > aren't even in this series.. Oh well, I just did /proc//stack by mak

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-27 Thread Kees Cook
On Mon, Nov 27, 2017 at 3:40 PM, Tobin C. Harding wrote: > Linus, > > I know you are bored of this patch set already and this pits your vast > experience against my eight months kernel dev experience ;) > > I humbly maintain that hashing %p and suggesting people use %x > _correctly_ isn't a WIN so

Re: [PATCH 0/5] add printk specifier %px, unique identifier

2017-11-27 Thread Linus Torvalds
On Mon, Nov 27, 2017 at 3:40 PM, Tobin C. Harding wrote: > Finally, with this patch set in place, we have the added benefit that > newbies (me) can quietly go around the kernel 'sweeping up' after > leaking addresses. This as apposed to using a hammer and hashing all > %p. And if this is deemed to