linux-kernel - Re: [PATCH v2] x86/hyperv: add noop functions to x86

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: <23749756-022a-5574-af4d-a4a03d9542e1@intel.com>
Date:   Tue, 13 Jun 2023 10:33:07 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Saurabh Sengar <ssengar@...ux.microsoft.com>, kys@...rosoft.com,
        haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org,
        mikelley@...rosoft.com, linux-kernel@...r.kernel.org,
        linux-hyperv@...r.kernel.org, hpa@...or.com
Subject: Re: [PATCH v2] x86/hyperv: add noop functions to x86_init mpparse
 functions

On 6/13/23 00:13, Saurabh Sengar wrote:
> In certain configurations, VTL0 and VTL2 can share the same VM
> partition and hence share the same memory address space. In such
> systems VTL2 has visibility of all of the VTL0 memory space.

FWIW, this is pretty much gibberish to me.  The way I suggest avoiding
producing gibberish is avoiding acronyms:

	Hyper-V can run VMs at different privilege "levels".  Sometimes,
	it chooses to run two different VMs at different levels but
	they share some of their address space.  This <insert reason
	that someone might want to do this>.

That's not gibberish.

> When CONFIG_X86_MPPARSE is enabled for VTL2, the kernel performs
> a scan of low memory to search for MP tables. However, in systems
> where VTL0 controls the low memory and may contain valid tables
> specific to VTL0, this scanning process can lead to confusion
> within the VTL2 kernel.

What is the end-user-visible effect of this "confusion"?  A crash?  A
warning?  An error message?  What is the impact on end users?

This information will help the maintainers decide how to disposition
your patch.  Should we send it upstream immediately because it's
impacting millions of users?  Or can we do it in a bit more leisurely
fashion because nobody cares?

> In !ACPI system, there is no way to disable CONFIG_X86_MPPARSE
> hence add the noop function instead.

This makes zero sense to me.

Like I told you before, we don't compile things out just because they
don't work on one weirdo system.  If we did that, we'd have a billion
incompatible x86 kernel images that can't boot across systems.