Re: [PATCH] lib/vsprintf: make-printk-non-secret printks all addresses as unhashed

From: Pavel Machek
Date: Thu Feb 04 2021 - 16:51:16 EST


Hi!

> Pavel Machek <pavel@xxxxxx> wrote:
>
> > > + pr_warn("** Kernel memory addresses are exposed, which may **\n");
> > > + pr_warn("** compromise security on your system. **\n");
> >
> > This is lies, right? And way too verbose.
>
> Not really. More of an exaggeration than a lie. And the verbosity is
> to

Well... security is _not_ compromised but robustness against kernel
bugs is reduced. It should not exaggerate.

> make sure it's noticed by those that shouldn't have it set. This works well
> for keeping trace_printk() out of production kernels. Why do you
> care

So if we want people to see it, we up the severity, right? Like
pr_err()... Distro kernels have quiet, anyway...

Lets take a look for what we say for _real_ problems:

[ 0.544757] Spectre V1 : Mitigation: usercopy/swapgs barriers and
__user pointer sanitiza
tion
[ 0.544876] Spectre V2 : Mitigation: Full generic retpoline
[ 0.544961] Spectre V2 : Spectre v2 / SpectreRSB mitigation:
Filling RSB on context switc
h
[ 0.545064] L1TF: System has more than MAX_PA/2 memory. L1TF
mitigation not effective.
[ 0.545163] L1TF: You may make it effective by booting the kernel
with mem=2147483648 par
ameter.
[ 0.545281] L1TF: However, doing so will make a part of your RAM
unusable.
[ 0.545374] L1TF: Reading
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html
might help you decide.

This machine is insecure. Yet I don't see ascii-art *** all around..

"Kernel memory addresses are exposed, which is bad for security."
would be quite enough, I'd say...

Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek

Attachment: signature.asc
Description: Digital signature