Hello Matt, On Wed, Jan 24, 2018 at 09:46:07AM +0000, Matt Redfearn <matt.redfearn@xxxxxxxx> wrote: > Hi Serge, > > On 23/01/18 19:10, Serge Semin wrote: > >Hello Matt, > > > >On Tue, Jan 23, 2018 at 03:35:14PM +0000, Matt Redfearn <matt.redfearn@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> > >>>>>> > >>>>>>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. > > > That was true until v4.15-rc2. The behavior of %pK was changed without that > being reflected in the documentation. A patch > (https://patchwork.kernel.org/patch/10124413/) is in progress to update > this. > > > > >> > >>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/ > > Yeah, again, the documentation is no longer correct, and %pK will always be > hashed, and before the RNG is initialized it does not even hash it, just > returning "(ptrval)". So I'd recommend guarding with CONFIG_DEBUG_KERNEL > and switching the format specifier to %px. > Oh, it isn't the bug then) I'll do as you suggest and replace %pK with %px closing the code by CONFIG_DEBUG_KERNEL macro. Regards, -Sergey > Thanks, > Matt > > > > >Regards, > >-Sergey > > > >>Thanks, > >>Matt > >> > >>> > >>>Regards, > >>>-Sergey > >>> > >>>> > >>>>Thanks, > >>>>Matt > >>>> > >>>>> > >>>>>>-- > >>>>>>Florian
