qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VW ELF loader


From: Paolo Bonzini
Subject: Re: VW ELF loader
Date: Mon, 10 Feb 2020 12:25:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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).

>> 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.  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.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]