Re: VW ELF loader

On Mon, Feb 10, 2020 at 12:26:07PM +0100, Paolo Bonzini wrote: > On 10/02/20 08:28, David Gibson wrote: > > On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote: > >> On 05/02/20 07:06, David Gibson wrote: > >>> On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > >> I'm really

Re: VW ELF loader

On Fri, Feb 14, 2020 at 11:01:26AM +1100, Alexey Kardashevskiy wrote: > > > On 13/02/2020 21:17, Paolo Bonzini wrote: > > On 13/02/20 02:43, Alexey Kardashevskiy wrote: > >> > >> Ok. So, I have made a small firmware which does OF CI, loads GRUB and > >> instantiates RTAS: > >> https://github.com/

Re: VW ELF loader

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 t

Re: VW ELF loader

On 13/02/2020 21:17, Paolo Bonzini wrote: > On 13/02/20 02:43, Alexey Kardashevskiy wrote: >> >> Ok. So, I have made a small firmware which does OF CI, loads GRUB and >> instantiates RTAS: >> https://github.com/aik/of1275 >> Quite raw but gives the idea. >> >> It does not contain drivers and sti

Re: VW ELF loader

On 13/02/20 02:43, Alexey Kardashevskiy wrote: > > Ok. So, I have made a small firmware which does OF CI, loads GRUB and > instantiates RTAS: > https://github.com/aik/of1275 > Quite raw but gives the idea. > > It does not contain drivers and still relies on QEMU to hook an OF path > to a backend.

Re: Restrictions of libnet (was: Re: VW ELF loader)

On Mon, Feb 10, 2020 at 10:39:52AM +0100, Michal Suchánek wrote: > On Mon, Feb 10, 2020 at 06:55:16PM +1100, David Gibson wrote: > > On Wed, Feb 05, 2020 at 07:24:04AM +0100, Thomas Huth wrote: > > > On 05/02/2020 06.30, David Gibson wrote: > > > > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas H

Re: VW ELF loader

On 10/02/2020 11:31, Alexey Kardashevskiy wrote: > > > On 07/02/2020 10:46, Paolo Bonzini wrote: >> On 07/02/20 00:23, Alexey Kardashevskiy wrote: Right, not unlike what you get with vof=on. :) I'm not against at all that idea. I just don't understand what you refer to below as (2)

Re: VW ELF loader

On 10/02/20 08:28, David Gibson wrote: > On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote: >> On 05/02/20 07:06, David Gibson wrote: >>> On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: >> I'm really sorry if what I am saying is stupid; but I was thinking of a >> firmware

Re: VW ELF loader

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

Re: VW ELF loader

On Mon, 10 Feb 2020 at 07:56, David Gibson wrote: > On Fri, Feb 07, 2020 at 12:45:20AM +0100, Paolo Bonzini wrote: > > 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 ar

Re: Restrictions of libnet (was: Re: VW ELF loader)

On Mon, Feb 10, 2020 at 06:55:16PM +1100, David Gibson wrote: > On Wed, Feb 05, 2020 at 07:24:04AM +0100, Thomas Huth wrote: > > On 05/02/2020 06.30, David Gibson wrote: > > > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: > > >> On 04/02/2020 09.54, Cornelia Huck wrote: > > >>> On Tu

Re: Restrictions of libnet (was: Re: VW ELF loader)

On Wed, Feb 05, 2020 at 07:24:04AM +0100, Thomas Huth wrote: > On 05/02/2020 06.30, David Gibson wrote: > > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: > >> On 04/02/2020 09.54, Cornelia Huck wrote: > >>> On Tue, 4 Feb 2020 07:16:46 +0100 > >>> Thomas Huth wrote: > >>> > On 0

Re: VW ELF loader

On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote: > On 05/02/20 07:06, David Gibson wrote: > > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > >> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: > >>> Speaking seriously, what would I put into the guest? > >>

Re: VW ELF loader

On Fri, Feb 07, 2020 at 12:45:20AM +0100, Paolo Bonzini wrote: > On 07/02/20 00:17, Alexey Kardashevskiy wrote: > > This is a lot and what is exactly the benefit? My alternative does not > > need drivers at all. > > Anything you put in the host is potential attack surface. Ok, it is attack surfac

Re: VW ELF loader

On 07/02/2020 10:46, Paolo Bonzini wrote: > On 07/02/20 00:23, Alexey Kardashevskiy wrote: >>> Right, not unlike what you get with vof=on. :) I'm not against at all >>> that idea. I just don't understand what you refer to below as (2). >>> Does petitboot not have the problem because it kexecs

Re: VW ELF loader

On 07/02/20 00:23, Alexey Kardashevskiy wrote: >> Right, not unlike what you get with vof=on. :) I'm not against at all >> that idea. I just don't understand what you refer to below as (2). >> Does petitboot not have the problem because it kexecs the new kernel? > > Petitboot does not have this

Re: VW ELF loader

On 07/02/20 00:17, Alexey Kardashevskiy wrote: > This is a lot and what is exactly the benefit? My alternative does not > need drivers at all. Anything you put in the host is potential attack surface. Plus, you're not doing a different thing than anyone else and as you've found out it may be easy

Re: VW ELF loader

On 06/02/2020 19:29, Paolo Bonzini wrote: > On 05/02/20 06:58, David Gibson wrote: >>> Yes, SLOF is big and slow. petitboot is not petit at all either, and >>> has the disadvantage that you have to find a way to run GRUB afterwards. >> Well, not usually. Petitboot parses grub configuration its

Re: VW ELF loader

On 06/02/2020 19:27, Paolo Bonzini wrote: > On 05/02/20 07:06, David Gibson wrote: >> On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: >>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: Speaking seriously, what would I put into the guest? >>> >>> Only things that w

Re: VW ELF loader

On 05/02/20 06:58, David Gibson wrote: >> Yes, SLOF is big and slow. petitboot is not petit at all either, and >> has the disadvantage that you have to find a way to run GRUB afterwards. > Well, not usually. Petitboot parses grub configuration itself, which > means that generally from the OS / in

Re: VW ELF loader

On 05/02/20 07:06, David Gibson wrote: > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: >> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: >>> Speaking seriously, what would I put into the guest? >> >> Only things that would be considered drivers. Ignore the partitions is

Re: VW ELF loader

On Wed, Feb 05, 2020 at 10:28:30AM +0100, Cornelia Huck wrote: > On Wed, 5 Feb 2020 17:06:34 +1100 > David Gibson wrote: > > > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > > > > You can generalize and reuse the s390 code. All you have to write is the > > > PCI scan and virtio

Re: VW ELF loader

On Wed, 5 Feb 2020 17:06:34 +1100 David Gibson wrote: > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > > You can generalize and reuse the s390 code. All you have to write is the > > PCI scan and virtio-pci setup. > > If we assume virtio only. In any case it sounds like the

Re: Restrictions of libnet (was: Re: VW ELF loader)

On 05/02/2020 06.30, David Gibson wrote: > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: >> On 04/02/2020 09.54, Cornelia Huck wrote: >>> On Tue, 4 Feb 2020 07:16:46 +0100 >>> Thomas Huth wrote: >>> On 04/02/2020 00.26, Paolo Bonzini wrote: > > > Il mar 4 feb 2020,

Re: VW ELF loader

On Mon, Feb 03, 2020 at 04:08:54PM +0100, Paolo Bonzini wrote: > On 03/02/20 11:58, Alexey Kardashevskiy wrote: > >>> So really, the question isn't whether we implement things in firmware > >>> or in qemu. It's whether we implement the firmware functionality as > >>> guest cpu code, which needs to

Re: VW ELF loader

On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: > > > > > > > Speaking seriously, what would I put into the guest? > > Only things that would be considered drivers. Ignore the partitions issue > for now so that you can ju

Re: Restrictions of libnet (was: Re: VW ELF loader)

On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: > On 04/02/2020 09.54, Cornelia Huck wrote: > > On Tue, 4 Feb 2020 07:16:46 +0100 > > Thomas Huth wrote: > > > >> On 04/02/2020 00.26, Paolo Bonzini wrote: > >>> > >>> > >>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy >>>

Re: VW ELF loader

On 04/02/2020 10:26, Paolo Bonzini wrote: > > > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy > ha scritto: > > > > Speaking seriously, what would I put into the guest? > > > Only things that would be considered drivers. Ignore the partitions > issue for now so

Re: VW ELF loader

On Tue, 4 Feb 2020 07:16:46 +0100 Thomas Huth wrote: > On 04/02/2020 00.26, Paolo Bonzini wrote: > > > > > > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy > > ha scritto: > > > > Speaking seriously, what would I put into the guest? > > > > Only things that would be

Re: VW ELF loader

On 01.02.20 20:04, Paolo Bonzini wrote: > On 01/02/20 14:39, Alexey Kardashevskiy wrote: >> QEMU needs to load GRUB from the disk. The current workaround is to read >> it from qcow2, save in a file and then call load_elf(). Not nice. >> >> 2 problems with that. >> >> 1. when load_elf calls addre

Re: Restrictions of libnet (was: Re: VW ELF loader)

Hello, On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: > > So IMHO the s390x world should move towards grub2, too. We could e.g. > link it initially into the s390-ccw bios bios ... and if that works out > well, later also use it as normal bootloader instead of zipl (not sure > if th

Re: Restrictions of libnet (was: Re: VW ELF loader)

On 04/02/2020 10.20, Thomas Huth wrote: [...] > So IMHO the s390x world should move towards grub2, too. We could e.g. > link it initially into the s390-ccw bios bios ... and if that works out > well, later also use it as normal bootloader instead of zipl I meant to say "use it as normal bootloader

Restrictions of libnet (was: Re: VW ELF loader)

On 04/02/2020 09.54, Cornelia Huck wrote: > On Tue, 4 Feb 2020 07:16:46 +0100 > Thomas Huth wrote: > >> On 04/02/2020 00.26, Paolo Bonzini wrote: >>> >>> >>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy >> > ha scritto: >>> >>> Speaking seriously, what would I put into

Re: VW ELF loader

On 04/02/2020 00.26, Paolo Bonzini wrote: > > > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy > ha scritto: > > Speaking seriously, what would I put into the guest? > > Only things that would be considered drivers. Ignore the partitions > issue for now so that you ca

Re: VW ELF loader

Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: > > > Speaking seriously, what would I put into the guest? > Only things that would be considered drivers. Ignore the partitions issue for now so that you can just pass the device tree services to QEMU with hypercalls. Netboot's dhcp/tft

Re: VW ELF loader

On 04/02/2020 09:56, Paolo Bonzini wrote: > > > Il lun 3 feb 2020, 23:36 Alexey Kardashevskiy > ha scritto: > > > > What partition formats would have to be supported? > > MBR, GPT, is there anything else? "Support" is limited to converting a > number afte

Re: VW ELF loader

Il lun 3 feb 2020, 23:36 Alexey Kardashevskiy ha scritto: > > > What partition formats would have to be supported? > > MBR, GPT, is there anything else? "Support" is limited to converting a > number after command to [start, size] couple. I am not going for file > systems. > > > But honestly I'm >

Re: VW ELF loader

On 04/02/2020 02:08, Paolo Bonzini wrote: > On 03/02/20 11:58, Alexey Kardashevskiy wrote: So really, the question isn't whether we implement things in firmware or in qemu. It's whether we implement the firmware functionality as guest cpu code, which needs to be coded to work wit

Re: VW ELF loader

On 03/02/20 11:58, Alexey Kardashevskiy wrote: >>> So really, the question isn't whether we implement things in firmware >>> or in qemu. It's whether we implement the firmware functionality as >>> guest cpu code, which needs to be coded to work with a limited >>> environment, built with a special

Re: VW ELF loader

On 3/2/20 8:12 pm, Paolo Bonzini wrote: > On 03/02/20 02:28, David Gibson wrote: >> But "pseries" is different. We're implementing the PAPR platform, >> which describes an OS environment that's presented by a combination of >> a hypervisor and firmware. The features it specifies *require* >> c

Re: VW ELF loader

On Mon, Feb 03, 2020 at 10:12:02AM +0100, Paolo Bonzini wrote: > On 03/02/20 02:28, David Gibson wrote: > > But "pseries" is different. We're implementing the PAPR platform, > > which describes an OS environment that's presented by a combination of > > a hypervisor and firmware. The features it s

Re: VW ELF loader

On 03/02/20 02:28, David Gibson wrote: > But "pseries" is different. We're implementing the PAPR platform, > which describes an OS environment that's presented by a combination of > a hypervisor and firmware. The features it specifies *require* > collaboration between the firmware and the hypervi

Re: VW ELF loader

On Sun, Feb 02, 2020 at 06:38:59PM +0100, Paolo Bonzini wrote: > Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy ha scritto: > > > > QEMU must not load GRUB from disk, that's the firmware's task. If you > > > want to kill SLOF, you can rewrite it, but loading the kernel GRUB from > > > disk within

Re: VW ELF loader

On Sat, Feb 01, 2020 at 08:04:25PM +0100, Paolo Bonzini wrote: > On 01/02/20 14:39, Alexey Kardashevskiy wrote: > > QEMU needs to load GRUB from the disk. The current workaround is to read > > it from qcow2, save in a file and then call load_elf(). Not nice. > > > > 2 problems with that. > > > >

Re: VW ELF loader

Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy ha scritto: > > QEMU must not load GRUB from disk, that's the firmware's task. If you > > want to kill SLOF, you can rewrite it, but loading the kernel GRUB from > > disk within QEMU is a bad idea: the next feature you'll be requested to > > implemen

Re: VW ELF loader

On 02/02/2020 06:04, Paolo Bonzini wrote: On 01/02/20 14:39, Alexey Kardashevskiy wrote: QEMU needs to load GRUB from the disk. The current workaround is to read it from qcow2, save in a file and then call load_elf(). Not nice. 2 problems with that. 1. when load_elf calls address_space_writ

Re: VW ELF loader

On 01/02/20 14:39, Alexey Kardashevskiy wrote: > QEMU needs to load GRUB from the disk. The current workaround is to read > it from qcow2, save in a file and then call load_elf(). Not nice. > > 2 problems with that. > > 1. when load_elf calls address_space_write() - I need to know where and > how

VW ELF loader

Hi! In my effort to "kill SLOF" (the PPC pseries guest firmware), I proceeded to the stage when QEMU needs to load GRUB from the disk. The current workaround is to read it from qcow2, save in a file and then call load_elf(). Not nice. 2 problems with that. 1. when load_elf calls address_space