Re: kexec GRUB, multiboot port and qemu

[Ague Mill <ague@mailoo.org>]

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

On Wed, Sep 05, 2012 at 07:45:02AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Actually, after some long hours of hacking, it looks like GRUB could
> > be all what we needed to nail this issue. Have a look at the current
> > state of affairs [2] if you are interested in the details.
> 
> kexec'ing GRUB for this is an overkill it's much easier to have just a
> small loop for this. Also note that i386 GRUB is unable to access memory
> beyond 4G. It's not a problem for loading kernels but is a problem for
> your application.

Thanks for having a look. But I suggest you take 2 more minutes to check
<https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/grub/grub-wipe-memory-v2.patch>.
You will see that memory beyond 4G is zero'ed by setting up PAE and
moving a window of 32 MB all the way through.

That is why GRUB is of particular interest. It is a small framework that
gives some support to output a nice progress bar, room for page mapping
trickery, and APM, ACPI, EFI or other ways to halt the machine.

Similar paging tricks with only Linux userspace code may be doable with
advanced mmap() usage, but using GRUB looks to work quite well. :)

Adding a 'wipe_memory' command to upstream GRUB would allow users to put
that in front of their `grub.cfg` and have their memory erased on every
reboot, without having to care about which operating system they have
used. This might be a fringe use case, but I can imagine some people
doing it.

> > Here is how I start qemu after:
> > 
> >     qemu -kernel /tmp/multiboot.img -vga std -m 256
> > 
> > And I get the following error:
> > 
> >     Missing Multiboot memory information
> >     Aborted.
> > 
> > 
> 
> qemu has a bug of always putting mbi at 0x9500 even if this location is
> used by binary.

As GRUB itself will be loaded at 0x8200, I understand why I see a
corrupted MBI.

I have also noticed that grub4dos will refuse to load a multiboot image
with an entry point below 0x100000 (1 MB). 

How difficult do you think it would be to change the current multiboot
port to use such address instead of the current 0x8200? Would it be a
changed that could be accepted upstream? As I'd be happy to give it a
shot, would you have some guidance on which part of the code might need
to be adjusted?
 
Thanks for your time!

-- 
Ague

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]