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

Message-ID: <YK66ymMQQawfgQUD@google.com>
Date:   Wed, 26 May 2021 21:16:58 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Ben Gardon <bgardon@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Maxim Levitsky <mlevitsk@...hat.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 Wed, May 26, 2021, Ben Gardon wrote:
> I don't know if there's a great way to formally encode this distinction, but
> I see two major classes of writable params in terms of complexity:
>
> 1. parameters that are captured on VM creation and follow the life of
> the VM e.g. the TDP MMU
>
> 2. parameters which have an effect on all VMs on the system when
> changed e.g. internally we have sysctls to change NX reclaim
> parameters
> 
> I think class 1 is substantially easier to reason about from a code
> perspective, but might be more confusing to userspace, as the current
> value of the parameter has no bearing on the value captured by the VM.
> Class 2 will probably be more complex to implement, require
> synchronization, and need a better justification.

That assessement isn't universally true, e.g. 'npt' and 'ept' could be snapshotted
and put into (1), but as discussed, the fallout would be spectactular.  And on
the other side, the flush/sync on reuse flag is fully dynamic and falls into (2),
yet is trivial to implement.

That said, I don't think it matters because I don't think classifying params
will change anyone's behavior.  Each param would still need to be justified and
reviewed on a case-by-case basis.