linux-kernel - Re: [PATCH] kvm: x86: Print "disabled by bios" only once per host

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:   Wed, 19 Feb 2020 12:19:01 +0100
From:   Erwan Velu <e.velu@...teo.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Erwan Velu <erwanaliasr1@...il.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kvm: x86: Print "disabled by bios" only once per host

On 18/02/2020 19:48, Sean Christopherson wrote:
[...]
> Fix userspace to only do the "add" on one CPU.
>
> Changing kvm_arch_init() to use pr_err_once() for the disabled_by_bios()
> case "works", but it's effectively a hack to workaround a flawed userspace.

I'll see with the user space tool to sort this out.

I'm also considering how "wrong" is what they do: udevadm trigger is 
generating 3500  "uevent add" on my system and I only noticed kvm to 
print this noisy message.

So as the print once isn't that "wrong" neither, this simple patch would 
avoid polluting the kernel logs.

So my proposal would be

- have this simple patch on the kernel side to avoid having userspace 
apps polluting logs

- contacting the udev people to see the rational & fix it too : I'll do that

As you said, once probed, there is no need reprinting the same message 
again as the situation cannot have changed.

As we are on the preliminary return code path (to make a EOPNOTSUPP), I 
would vote for protecting the print against multiple calls/prints.

The kernel patch isn't impacting anyone (in a regular case) and just 
avoid pollution.

Would you agree on that ?

Erwan,