linux-kernel - Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170907093631.GD533@jagdpanzerIV.localdomain>
Date:   Thu, 7 Sep 2017 18:36:31 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Helge Deller <deller@....de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Tony Luck <tony.luck@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
 usages

(Cc Tony, Fenghua, Benjamin, Paul, Michael)

a brief description:

original patch set:
  lkml.kernel.org/r/1504729681-3504-1-git-send-email-deller@....de

start of this discussion:
  lkml.kernel.org/r/20170907075653.GA533@...dpanzerIV.localdomain

basically we are looking at possibilities to make %pF/%pS differences
less disturbing. Helge has discovered a number of wrong usages in the
kernel and has fixed the currently existing call sites; the question
is what we can do to avoid this type of the patch sets in the future?
/* assuming that no one reads printk documentation */

Hopefully you guys can help.

On (09/07/17 11:12), Helge Deller wrote:
[..]
> > -		ptr = dereference_function_descriptor(ptr);
> > +		ptr = __dereference_function_descriptor(ptr);
> 
> This is not needed.
> All affected arches (ia64, ppc64, parisc64) already call  
> probe_kernel_address() inside their dereference_function_descriptor() function.
> So this patch just adds unnecessary overhead for all arches.

good, thanks. honestly, I obviously didn't check what each platform
does. guilty! sort of.

> > ... here is a question, does function descriptor belong to a special
> > section? can we check that supplied ptr belongs to a descriptor section
> > and avoid dereference_function_descriptor() if it doesn't? (just fall
> > through directly to symbol_string() in this case). is this possible?
> 
> I think theoretically yes.
> On parisc ptr does *not* point to any code segment, and most likely it
> points to the .data segment. I don't know if that's the case for ia64 and
> ppc64 too.
> I can look into adding such check-code, but even then the warning will
> only show up if you run on ia64, ppc64 and parisc64.

ok. personally I think that we need to start doing "does ptr belong to
descriptor segment/section/etc" thing and skip
dereference_function_descriptor() when it doesn't. [well, where possible.
hopefully on every affected platform... if this problem actually bothers
any one]. that seems like the way to fix the root cause of the problem.
because it's you, Petr and may be 7 more guys who knows the difference
between %pF/%pS. no one else has any idea at all. and no one actually
reads the printk() documentation, let's be real :)

	-ss