linux-kernel - Re: [PATCH 11/14] MIPS: memblock: Print out kernel virtual mem layout

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Jan 2018 22:10:51 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Matt Redfearn <matt.redfearn@...s.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>, ralf@...ux-mips.org,
        miodrag.dinic@...s.com, jhogan@...nel.org, goran.ferenc@...s.com,
        david.daney@...ium.com, paul.gortmaker@...driver.com,
        paul.burton@...s.com, alex.belits@...ium.com,
        Steven.Hill@...ium.com, alexander.sverdlin@...ia.com,
        kumba@...too.org, marcin.nowakowski@...s.com, James.hogan@...s.com,
        Peter.Wotton@...s.com, Sergey.Semin@...latforms.ru,
        linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/14] MIPS: memblock: Print out kernel virtual mem layout

Hello Matt,

On Tue, Jan 23, 2018 at 03:35:14PM +0000, Matt Redfearn <matt.redfearn@...s.com> wrote:
> Hi Serge,
> 
> On 19/01/18 14:27, Serge Semin wrote:
> >On Fri, Jan 19, 2018 at 07:59:43AM +0000, Matt Redfearn <matt.redfearn@...s.com> wrote:
> >
> >Hello Matt,
> >
> >>Hi Serge,
> >>
> >>
> >>
> >>On 18/01/18 20:18, Serge Semin wrote:
> >>>On Thu, Jan 18, 2018 at 12:03:03PM -0800, Florian Fainelli <f.fainelli@...il.com> wrote:
> >>>>On 01/17/2018 02:23 PM, Serge Semin wrote:
> >>>>>It is useful to have the kernel virtual memory layout printed
> >>>>>at boot time so to have the full information about the booted
> >>>>>kernel. In some cases it might be unsafe to have virtual
> >>>>>addresses freely visible in logs, so the %pK format is used if
> >>>>>one want to hide them.
> >>>>>
> >>>>>Signed-off-by: Serge Semin <fancer.lancer@...il.com>
> >>>>
> >>>>I personally like having that information because that helps debug and
> >>>>have a quick reference, but there appears to be a trend to remove this
> >>>>in the name of security:
> >>>>
> >>>>https://patchwork.kernel.org/patch/10124007/
> >>>>
> >>>>maybe hide this behind a configuration option?
> >>>
> >>>Yeah, arm code was the place I picked the function up.) But in my case
> >>>I've used %pK so the pointers would disappear from logging when
> >>>kptr_restrict sysctl is 1 or 2.
> >>>I agree, that we might need to make the printouts optional. If there is
> >>>any kernel config, which for instance increases the kernel security we
> >>>could also use it or anything else to discard the printouts at compile
> >>>time.
> >>
> >>
> >>Certainly, when KASLR is active it would be preferable to hide this
> >>information, so you could use CONFIG_RELOCATABLE. The existing KASLR stuff
> >>additionally hides this kind of information behind CONFIG_DEBUG_KERNEL, so
> >>that only people actively debugging the kernel see it:
> >>
> >>http://elixir.free-electrons.com/linux/v4.15-rc8/source/arch/mips/kernel/setup.c#L604
> >
> >Ok. I'll hide the printouts behind both of that config macros in the next patchset
> >version.
> 
> 
> Another thing to note - since ad67b74d2469d ("printk: hash addresses printed
> with %p") %pK at this time in the boot process is useless since the RNG is
> not sufficiently initialised and all prints end up being "(ptrval)". Hence
> after v4.15-rc2 we end up with output like:
> 
> [    0.000000] Kernel virtual memory layout:
> [    0.000000]     lowmem  : 0x(ptrval) - 0x(ptrval)  ( 256 MB)
> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)  (7374 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)  (1901 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)  (1600 kB)
> [    0.000000]       .bss  : 0x(ptrval) - 0x(ptrval)  ( 415 kB)
> [    0.000000]     vmalloc : 0x(ptrval) - 0x(ptrval)  (1023 MB)
> [    0.000000]     fixmap  : 0x(ptrval) - 0x(ptrval)  (  68 kB)
> 

It must be some bug in the algo. What point in the %pK then? According to
the documentation the only way to see the pointers is when (kptr_restrict == 0).
But if it is we don't get into the restricted_pointer() method at all:
http://elixir.free-electrons.com/linux/v4.15-rc9/source/lib/vsprintf.c#L1934
In this case the vsprintf() executes the method ptr_to_id(), which of course
default to _not_ leak addresses, and hash it before printing.

Really %pK isn't supposed to be dependent from RNG at all since kptr_restrict
doesn't do any value randomization.

> 
> The %px format specifier was added for cases such as this, where we really
> want to print the unmodified address. And as long as this function is
> suitably guarded to only do this when KASLR is deactivated /
> CONFIG_DEBUG_KERNEL is activated, etc, then we are not unwittingly leaking
> information - we are deliberately making it available.
> 

If %pK would work as it's stated by the kernel documentation:
https://www.kernel.org/doc/Documentation/printk-formats.txt
then the only change I'd suggest to have here is to close the kernel memory
layout printout method by the CONFIG_DEBUG_KERNEL ifdef-macro. The kptr_restrict
should default to 1/2 if the KASLR is activated:
https://lwn.net/Articles/444556/

Regards,
-Sergey

> Thanks,
> Matt
> 
> >
> >Regards,
> >-Sergey
> >
> >>
> >>Thanks,
> >>Matt
> >>
> >>>
> >>>>-- 
> >>>>Florian