linux-kernel - Re: Writable module parameters in KVM

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-next>] [day] [month] [year] [list]

Message-ID: <35fe7a86-d808-00e9-a6aa-e77b731bd4bf@redhat.com>
Date:   Wed, 26 May 2021 12:49:11 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Ben Gardon <bgardon@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Jim Mattson <jmattson@...gle.com>,
        Junaid Shahid <junaids@...gle.com>,
        Peter Xu <peterx@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>
Subject: Re: Writable module parameters in KVM

On 26/05/21 01:45, Ben Gardon wrote:
> 
> At Google we have an informal practice of adding sysctls to control some 
> KVM features. Usually these just act as simple "chicken bits" which 
> allow us to turn off a feature without having to stall a kernel rollout 
> if some feature causes problems. (Sysctls were used for reasons specific 
> to Google infrastructure, not because they're necessarily better.)
> 
> We'd like to get rid of this divergence with upstream by converting the 
> sysctls to writable module parameters, but I'm not sure what the general 
> guidance is on writable module parameters. Looking through KVM, it seems 
> like we have several writable parameters, but they're mostly read-only.

Sure, making them writable is okay.  Most KVM parameters are read-only 
because it's much simpler (the usecase for introducing them was simply 
"test what would happen on old processors").  What are these features 
that you'd like to control?

> I also don't see central documentation of the module parameters. They're 
> mentioned in the documentation for other features, but don't have their 
> own section / file. Should they?

They probably should, yes.

Paolo