linux-kernel - Re: [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support

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: <0a83e174db16e15cb0f0d3ac37d6717c918ee78d.camel@infradead.org>
Date: Fri, 22 Mar 2024 14:27:22 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Rob Herring <robh@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, "Landge, Sudan"
	 <sudanl@...zon.co.uk>, Sudan Landge <sudanl@...zon.com>, tytso@....edu, 
	Jason@...c4.com, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, 
	sathyanarayanan.kuppuswamy@...ux.intel.com, thomas.lendacky@....com, 
	dan.j.williams@...el.com, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, graf@...zon.de, bchalios@...zon.es, 
	xmarcalx@...zon.co.uk, ardb@...nel.org, benh <benh@...nel.crashing.org>
Subject: Re: [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support

On Fri, 2024-03-22 at 08:22 -0500, Rob Herring wrote:
> 
> > > What stops you from passing fw_cfg not to UEFI FW? BTW, no actual VM
> > > name was used in your posting, but now suddenly it is a talk about QEMU.

(Forgot to address the second part of that last time. No specific VMM
was mentioned in the first place because this isn't VMM-specific)

> > That would be possible. But not ideal.
> 
> Why not ideal?
> 
> To rephrase the question, why is it fine for UEFI to read the vmgenid
> from fw_cfg, but the kernel can't use the same mechanism?

Because fw_cfg an incestuous way to get data from the VMM into the BIOS
(both SeaBIOS and UEFI). It's the way we pass the ACPI tables and
things like that.

It *isn't* designed as a general-purpose way of doing device discovery
for use by various operating systems.

I'm also not sure Firecracker, which is the VMM Sudan is working on,
even *has* fw_cfg. Especially on ARM. If we're going to be forced to
add some complicated device with MMIO and DMA just to be able to
advertise the existence of a simple memory region, that's just as bad
as being forced to expose it as an emulated PCI device.

This is what DT is *for*.

> The response
> that you'd have to use UEFI to use fw_cfg makes no sense to me. The
> only reason I can think of is just being lazy and wanting to have
> minimal changes to some existing driver. It looks to me like you could
> implement this entirely in userspace already with zero kernel or
> binding changes. From a quick look, we already have a fw_cfg driver
> exposing UUID (that's the same thing as vmgenid AIUI) to userspace,
> and you can feed that back into the random pool.
> 
> I am concerned that we already have a mechanism and you want to add a
> second way. When do we ever think that's a good idea? What happens 
> on the next piece of fw_cfg data? We add yet another binding?

No, because fw_cfg is a way for the VMM to give configuration
information to the firmware. There's a clue in the name. The firmware
then sets up ACPI tables or DT to pass information in a more coherent
and structured fashion to general-purpose operating systems.

And some VMMs *don't* use fw_cfg at all because for the minimal microvm
case it's overkill.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)