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:   Tue, 19 Jul 2022 17:44:03 -0300
From:   "Guilherme G. Piccoli" <>
To:     Arjan van de Ven <>,,,,
Cc:,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, Cong Wang <>,
        Sebastian Andrzej Siewior <>,
        Valentin Schneider <>,
        Xiaoming Ni <>
Subject: Re: [PATCH v2 09/13] notifier: Show function names on notifier
 routines if DEBUG_NOTIFIERS is set

On 19/07/2022 17:33, Arjan van de Ven wrote:
> On 7/19/2022 12:53 PM, Guilherme G. Piccoli wrote:
>> Currently we have a debug infrastructure in the notifiers file, but
>> it's very simple/limited. Extend it by:
>> (a) Showing all registered/unregistered notifiers' callback names;
> I'm not yet convinced that this is the right direction.
> The original intent for this "debug" feature was to be lightweight enough that it could run in production, since at the time, rootkits
> liked to clobber/hijack notifiers and there were also some other signs of corruption at the time.
> By making something print (even at pr_info) for what are probably frequent non-error operations, you turn something that is light
> into something that's a lot more heavy and generally that's not a great idea... it'll be a performance surprise.

Is registering/un-registering notifiers a hot path, or performance
sensitive usually? For me, this patch proved to be very useful, and once
enabled, shows relatively few entries in dmesg, these operations aren't
so common thing it seems.

Also, if this Kconfig option was meant to run in production, maybe the
first thing would be have some sysfs tuning or anything able to turn it
on - I've worked with a variety of customers and the most terrifying
thing in servers is to install a new kernel and reboot heh

My understanding is that this debug infrastructure would be useful for
notifiers writers and people playing with the core notifiers
code...tracing would be much more useful in the context of checking if
some specific notifier got registered/executed in production environment
I guess.



Powered by blists - more mailing lists