linux-kernel - Re: [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN

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]

Date:   Sun, 24 May 2020 23:07:15 -0700
From:   Joe Perches <joe@...ches.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Ondrej Mosnacek <omosnace@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] twist: allow converting pr_devel()/pr_debug() into
 printk(KERN_DEBUG)

On Mon, 2020-05-25 at 14:03 +0900, Tetsuo Handa wrote:
> On 2020/05/25 4:18, Ondrej Mosnacek wrote:
> > I'm also not sure if this is really worth it... It would help localize
> > the bug in this specific case, but there is nothing systematic about
> > it. Are there that many debug print statements that dereference
> > pointers that are later passed to functions, but not dereferenced
> > otherwise? Maybe yes, but it seems to be quite an optimistic
> > assumption... I don't consider it such a big problem that a bug in
> > function X only manifests itself deeper in the callchain. There will
> > always be such bugs, no matter how many moles you whack.
> 
> There are about 1400 pr_debug() callers. About 1000 pr_debug() callers seem
> to pass plain '%p' (which is now likely useless for debugging purpose due to
> default ptr_to_id() conversion inside pointer()), and about 400 pr_debug()
> callers seem to pass '%p[a-zA-Z]' (which does some kind of dereference inside
> pointer()). Thus, we might find some bugs by evaluating '%p[a-zA-Z]'.
> 
> 
> 
> On Sun, May 24, 2020 at 7:38 PM Joe Perches <joe@...ches.com> wrote:
> > While I think this is rather unnecessary,
> > what about dev_dbg/netdev_dbg/netif_dbg et al ?
> 
> Maybe a good idea, for there are about 24000 *dev_dbg() callers, and
> 479 callers pass '%p[a-zA-Z]'. But we can defer to another patch, in
> case this patch finds crashes before fuzz testing process starts.

There are a bunch more than that.
Some use other macros, some are functions.

$ grep-2.5.4 --include=*.[ch] -n -rP '\w+_dbg\s*\((?:[^,"]+,){0,3}\s*"[^"]+%p\w+\b[^"]*"' * | \
  perl -e 'local $/; while (<>) { s/\n\s+/ /g; print; }' | \
  grep -o -P '\w+_dbg' | \
  sort | uniq -c | sort -rn
    415 dev_dbg
    116 netdev_dbg
    100 batadv_dbg
     80 ath10k_dbg
     53 mwifiex_dbg
     49 ath11k_dbg
     29 brcmf_dbg
     28 ath_dbg
     26 ht_dbg
     20 ath6kl_dbg
     17 wcn36xx_dbg
     15 netif_dbg
     15 cifs_dbg
     14 tdls_dbg
     13 ibss_dbg
     11 mpl_dbg
     10 memblock_dbg
     10 bt_dev_dbg
      9 ps_dbg
      8 wiphy_dbg
      8 mps_dbg
      8 mlme_dbg
      8 mhwmp_dbg
      8 ipoib_dbg
      7 sta_dbg
      7 slave_dbg
      7 pci_dbg
      7 ibdev_dbg
      6 mpath_dbg
      6 en_dbg
      6 drm_dbg
      5 usnic_dbg
      5 mlx5_core_dbg
      4 vin_dbg
      4 msync_dbg
      3 rsi_dbg
      3 cal_dbg
      2 v4l2_dbg
      2 siw_dbg
      2 sdata_dbg
      2 ocb_dbg
      2 musb_dbg
      2 hw_dbg
      2 eeh_edev_dbg
      2 cifs_server_dbg
      2 at76_dbg
      1 rt2x00_eeprom_dbg
      1 pnp_dbg
      1 mthca_dbg
      1 mlx5_ib_dbg
      1 mlx4_dbg
      1 isp_dbg
      1 gfs2_print_dbg
      1 erofs_dbg
      1 dynamic_drbd_dbg
      1 ctx_dbg
      1 cs89_dbg