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]
Message-ID: <91db305a-1d81-61a6-125b-3094e75b4b3e@criteo.com>
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,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ