linux-kernel - Re: [PATCH 0/3] KVM: x86: Fix supported VM

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: <CABgObfYvkT39Msd11uJMZMquOsvNKBa=Z548JQZGfOmCF=TPaA@mail.gmail.com>
Date: Tue, 7 May 2024 19:20:51 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Kai Huang <kai.huang@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps

On Mon, Apr 29, 2024 at 5:56 PM Sean Christopherson <seanjc@...gle.com> wrote:
> > Perhaps we can make the kvm.ko as a dummy module which only keeps the module
> > parameters for backward compatibility?
>
> Keeping parameters in a dummy kvm.ko would largely defeat the purpose of linking
> everything into vendor modules, i.e. would make it possible for the parameters to
> hold a stale value.

We have the following read-write params:

parm:           nx_huge_pages:bool
parm:           nx_huge_pages_recovery_ratio:uint
parm:           nx_huge_pages_recovery_period_ms:uint
parm:           flush_on_reuse:bool
parm:           ignore_msrs:bool
parm:           report_ignored_msrs:bool
parm:           min_timer_period_us:uint
parm:           tsc_tolerance_ppm:uint
parm:           lapic_timer_advance_ns:int
parm:           force_emulation_prefix:int
parm:           pi_inject_timer:bint
parm:           eager_page_split:bool
parm:           halt_poll_ns:uint
parm:           halt_poll_ns_grow:uint
parm:           halt_poll_ns_grow_start:uint
parm:           halt_poll_ns_shrink:uint

Vendor modules do not muck with them (the only one that is exported is
report_ignored_msrs for which permanency is obviously harmless).

And the following read-only params:

parm:           tdp_mmu:bool
parm:           mmio_caching:bool
parm:           kvmclock_periodic_sync:bool
parm:           vector_hashing:bool
parm:           enable_vmware_backdoor:bool
parm:           enable_pmu:bool
parm:           mitigate_smt_rsb:bool

The only really bad one is tdp_mmu, which can change depending on the
ept/npt parameters of kvm-intel/kvm-amd; everything else is okay to
have in a common module.

mitigate_smt_rsb could (should?) move to kvm-amd.ko if the modules
were unified with kvm.ko as a dummy one.

Paolo