ptrval hiding -- first kernel messages look rather "interesting"

ptrval hiding -- first kernel messages look rather "interesting"

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Hi!

v4.17 on n900:

[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xd0000000 - 0xff800000   ( 760 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xcff00000   ( 255 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
[    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 309 kB)
[    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 333 kB)
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16

I mean -- security is nice, but perhaps we should adjust the messages
so this does not look like we are making fun of the user?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ptrval hiding -- first kernel messages look rather "interesting"

[Andy Shevchenko]

On Fri, Jun 1, 2018 at 1:31 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> v4.17 on n900:
>
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xd0000000 - 0xff800000   ( 760 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xcff00000   ( 255 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 309 kB)
> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 333 kB)
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>
> I mean -- security is nice, but perhaps we should adjust the messages
> so this does not look like we are making fun of the user?

Colleague of mine (perhaps you even know him) wrote recently a small
patch that improves kernel by 400% by removing ptr_to_id() completely.

Okay, joking is joking, but it was a proposal to have some command
line option to enforce no-hash pointers.
I would rather enable it when one of the existing option is present
(like 'debug'), though it might alter the output in user space or
something else.
So, I have no strong opinion here.

-- 
With Best Regards,
Andy Shevchenko

Re: ptrval hiding -- first kernel messages look rather "interesting"

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On Fri 2018-06-01 13:49:41, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 1:31 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > v4.17 on n900:
> >
> > [    0.000000] Virtual kernel memory layout:
> > [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> > [    0.000000]     vmalloc : 0xd0000000 - 0xff800000   ( 760 MB)
> > [    0.000000]     lowmem  : 0xc0000000 - 0xcff00000   ( 255 MB)
> > [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> > [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> > [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
> > [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
> > [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 309 kB)
> > [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 333 kB)
> > [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> >
> > I mean -- security is nice, but perhaps we should adjust the messages
> > so this does not look like we are making fun of the user?
> 
> Colleague of mine (perhaps you even know him) wrote recently a small
> patch that improves kernel by 400% by removing ptr_to_id() completely.
> 
> Okay, joking is joking, but it was a proposal to have some command
> line option to enforce no-hash pointers.
> I would rather enable it when one of the existing option is present
> (like 'debug'), though it might alter the output in user space or
> something else.
> So, I have no strong opinion here.

I guess my proposal would be replacing the four lines with single line:

.text (8160 kB) .init (1024 kB) .data ( 309 kB) .bss ( 333 kB)

I'm not sure if exact addresses are normally useful, and having big
table saying "redacted!" looks strange.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ptrval hiding -- first kernel messages look rather "interesting"

[Steven Rostedt]

On Fri, 1 Jun 2018 12:31:44 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> v4.17 on n900:
> 
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xd0000000 - 0xff800000   ( 760 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xcff00000   ( 255 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)

Looks like the above is pointer values. Grant it, they are dynamic, but
still.


> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 309 kB)
> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 333 kB)
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> 
> I mean -- security is nice, but perhaps we should adjust the messages
> so this does not look like we are making fun of the user?

Hmm, do we hash even when the kernel isn't relocatable? Seems rather
pointless if a kernel will always load in the same memory locations to
hash the pointer values that address them.

-- Steve