lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 4 Jun 2018 18:39:13 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Pavel Machek <pavel@....cz>
Cc:     kernel list <linux-kernel@...r.kernel.org>,
        torvalds@...ux-foundation.org, joel@....id.au, me@...in.cc,
        corbet@....net
Subject: Re: ptrval hiding -- first kernel messages look rather
 "interesting"

On Fri, 1 Jun 2018 12:31:44 +0200
Pavel Machek <pavel@....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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ