On Tue, 25 Feb 2025, Christophe Leroy wrote: > > was suddenly lost from the kernel log, the access to which unprivileged > > users can be denied if so desired according to the site policy. Whereas > > running the kernel such as to have all output from plain `%p' exposed just > > to cope with this proposed change, now that seems like a security risk. > > The purpose of hashed addresses is to avoid kernel addresses to leak to the > kernel log. Here you have function names, if you get real function addresses > at the same time, then you know everything about kernel addresses and for > instance KASLR becomes just pointless.
Why is it so important not to have kernel addresses in the kernel log? This defeats the purpose of having diagnostics for such fatal events. If your site policy so requires, you can disable access to the kernel log for unprivileged users, in which case once you do have one you can poke at /dev/mem too and have a thousand other ways to do harm. And if you are a sloppy admin and have /var/log/messages world-readable where you really ought not to, then well, what can I say? From the description of `%pK' I infer it's been meant for /proc files and the like that may be readable to unprivileged users, and I can certainly understand the security implications here. > By the way, why do you need the addresses at all in addition to function names > ? When I look at x86 dump stack, they only print function name, using %pBb They can be handed over to GDB, `objdump' and similar debug tools when working with `vmlinux'. Function names do help, giving you assistance to make sure you work with matching `vmlinux'. NB I don't know what x86 does, I've done little in that area in the recent ~20 years, mostly taking care about my legacy 32-bit i486/i586 stuff. Maciej
