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: <20241126200624.GDZ0YqQF96hKZ99x_b@fat_crate.local>
Date: Tue, 26 Nov 2024 21:06:24 +0100
From: Borislav Petkov <bp@...en8.de>
To: Xin Li <xin@...or.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, seanjc@...gle.com, pbonzini@...hat.com,
	corbet@....net, tglx@...utronix.de, mingo@...hat.com,
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
	luto@...nel.org, peterz@...radead.org, andrew.cooper3@...rix.com
Subject: Re: [PATCH v3 09/27] KVM: VMX: Do not use
 MAX_POSSIBLE_PASSTHROUGH_MSRS in array definition

On Tue, Nov 26, 2024 at 11:22:45AM -0800, Xin Li wrote:
> It's still far from full in a bitmap on x86-64, but just that the
> existing use of MAX_POSSIBLE_PASSTHROUGH_MSRS tastes bad.

Far from full?

It is full:

static u32 vmx_possible_passthrough_msrs[MAX_POSSIBLE_PASSTHROUGH_MSRS] = {
        MSR_IA32_SPEC_CTRL,
        MSR_IA32_PRED_CMD,
        MSR_IA32_FLUSH_CMD,
        MSR_IA32_TSC,
#ifdef CONFIG_X86_64
        MSR_FS_BASE,
        MSR_GS_BASE,
        MSR_KERNEL_GS_BASE,
        MSR_IA32_XFD,
        MSR_IA32_XFD_ERR,
#endif
        MSR_IA32_SYSENTER_CS,
        MSR_IA32_SYSENTER_ESP,
        MSR_IA32_SYSENTER_EIP,
        MSR_CORE_C1_RES,
        MSR_CORE_C3_RESIDENCY,
        MSR_CORE_C6_RESIDENCY,
        MSR_CORE_C7_RESIDENCY,
};

I count 16 here.

If you need to add more, you need to increment MAX_POSSIBLE_PASSTHROUGH_MSRS.

> A better one?

Not really.

You're not explaining why MAX_POSSIBLE_PASSTHROUGH_MSRS becomes 64.

> Per the definition, a bitmap on x86-64 is an array of 'unsigned long',
> and is at least 64-bit long.
> 
> #define DECLARE_BITMAP(name,bits) \
> 	unsigned long name[BITS_TO_LONGS(bits)]
> 
> It's not accurate and error-prone to use a hard-coded possible size of
> a bitmap, Use ARRAY_SIZE with an overflow build check instead.

It becomes 64 because a bitmap has 64 bits?

Not because you need to add more MSRs to it and thus raise the limit?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ