linux-kernel - Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

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: <46385A8A.6070405@redhat.com>
Date:	Wed, 02 May 2007 11:31:54 +0200
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jeff Garzik <jeff@...zik.org>, patches@...-64.org,
	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for
 relocatable bzImage

Jeremy Fitzhardinge wrote:
> Eric W. Biederman wrote:
>> I have several ideas on how we can make this work but first I have to
>> ask what is it that you are trying to accomplish?
> 
> The requirements are:
> 
>    1. the domain builder needs to get various information about the
>       guest kernel by inspecting its ELF notes

Doesn't need to be ELF notes.  The current (3.0.5+) domain builder has 
pluggable binary parsers.  Right now there are two:  ELF (obviously ...) 
and binary (with a multiboot-like header).  Filling the informations 
such as virt_base is a function of the parser, so when adding one more 
parser to the domain builder for bzImage kernels the parser could do 
something completely different to gather the needed information ...

> That works OK for a kernel which is compiled to run under Xen and can't
> run in any other environment, but now that we can generate a single
> kernel which can run in any number of different environments, its
> unfortunate that we still need multiple variants of the kernel image.

Yep, although already much better than completely different kernels. 
Most space of a typical distro kernel is modules which are shared even 
with different kernel binaries.

> So, I have no problem in also building a boot protocol info structure,
> and passing that in %esi, so long as I can store a pointer to the
> Xen-specific info as well.

Yep, should work fine.

> I think I'd prefer to have the domain builder decompress/relocate the
> kernel from the bzImage and start it directly, rather than have it
> decompress/relocate itself,

I'd expect that work better too.

> It depends
> on how well it can deal with having paging enabled and being in ring 1. 

Xen direct paging mode requiring (leaf) page tables being mapped 
read-only makes page table manipulation a bit difficult.  Xen has to 
care whenever the memory it maps is a page table.  Native hasn't.

Also switching to a completely different set of page tables isn't easy 
under Xen.  My xen guest kexec patches have to perform some intresting 
tricks because of that ...

> Looks like it might just be a matter of starting up with "enough" memory
> mapped.

Doesn't solve the problem of having to switch from identity mapping to 
the 0xc0000000 one ...

cheers,
   Gerd

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/