Re: VW ELF loader

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]

On Mon, Feb 10, 2020 at 12:25:39PM +0100, Paolo Bonzini wrote:
> On 10/02/20 08:30, David Gibson wrote:
> >> Anything you put in the host is potential attack surface.
> > Ok, it is attack surface you're concerned about.  That wasn't totally
> > clear before this point.
> 
> Part that, part having to add backend hooks that weren't needed so far.
> 
> >> Plus, you're not doing a different thing than anyone else and as
> >> you've found out it may be easy for block device but not for
> >> everything else.
> >
> > Uh.. was that supposed to be "we *are* doing a different thing than
> > anyone else"?
> 
> Alexey's question was "what is exactly the benefit", so "not doing a
> different thing" is the answer (one of them).

Ah, right, I see.

> >> Every platform that QEMU supports is just using a firmware to do
> >> firmware things; it can be U-Boot, EDK-2, SLOF, SeaBIOS, qboot, with
> >> varying level of complexity.  Some are doing -kernel in QEMU rather than
> >> firmware, but that's where things end.
> >
> > Well, yeah, but AIUI those platforms actually have a defined hardware
> > environment on which the firmware is running.  For PAPR we don't, we
> > *only* have a specification for the "hardware"+"firmware" environment
> > as seen by the OS together.
> 
> PAPR is a specification for the environment as seen by the OS.  But "-M
> pseries" is already a defined hardware environment on which SLOF is
> running.

"defined" might be a bit strong.  We have on multiple occasions
required synchronized SLOF and qemu updates in order to keep
presenting the same guest environment.

> There's nothing that prevents you from defining more of that
> environment in order to run Linux (for petitboot) or your own
> pseudo-OpenFirmware driver provider inside it.

Well, sure, but we don't want that definition to introduce lots of
complexity we have to maintain on top of the existing HV and firmware
interfaces that are defined.

I realized what I said about the firmware interfaces requiring HV
privilege was a bit misleading.  For the boot time firmware
components, such as the OF client interface, that's mostly not true
(with the big and hairy exception of the
ibm,client-architecture-support feature negotiation mechanism).

It is, however, true of the runtime RTAS interfaces.  In fact it's
true to the point that, at least for most of the RTAS interfaces we
care about, it's hard to imagine an in-guest implementation doing
anything much other than repackaging the information it gets and
forwarding it to the hypervisor.  For most purposes RTAS is pretty
much an alternative hypercall mechanism.  So, I think implementing the
RTAS entirely in qemu was the right choice.

Where it gets complicated is that a number of RTAS calls need to match
IDs with stuff from the boot time firmware.  Particularly phandles of
device nodes, and some other IDs.

Which would be fine if the boot time firmware took the device tree
from qemu and used it unmodified.  But.. it doesn't, quite.  In
particular it assigns its own phandles, because it uses them as an
internal index.  And worse, clients can alter the device tree, and
this is used to a small extent - grub pokes a few values in there for
use later.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]