Hi!

> Pavel Machek <[email protected]> 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

Reply via email to