kexec GRUB, multiboot port and qemu

kexec GRUB, multiboot port and qemu

[Ague Mill]

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

Hi!

As a developer working on Tails [1], a live distribution aimed at
protecting its users' privacy, I am trying to tackle one of our
long-standing issue: we need to properly overwrite the system memory
with zeros on shutdown in order to erase traces of the user activity.

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.

[1] https://tails.boum.org/
[2] https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/grub/


I am currently stuck on how to obtain a standalone GRUB image that could
be kexec'ed from Linux.

When building an ELF image with the 'pc' port, kexec replies:

    Base address: 8200 is not page aligned

The next candidate looked like the 'multiboot' port. But I can't get an
image that will work in qemu. I have tried to build a strictly minimal
boot image using the following commands:

    ./configure --with-platform=multiboot --target=i386
    make -j4
    ./grub-mkimage -O i386-multiboot -C xz -d ./grub-core \
        -o /tmp/multiboot.img

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.


Is there any known working way to test multiboot images?
Is there a better path to be able to use kexec to load and execute GRUB?


I would very much like to offer the `wipe_memory` command for inclusion
in GRUB (and do the necessary refinements on the patch) once we have
something that works from one end to the other for Tails.

Thanks for your help,
-- 
Ague

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

Re: kexec GRUB, multiboot port and qemu

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 27.08.2012 01:30, Ague Mill wrote:

> Hi!
> 
> As a developer working on Tails [1], a live distribution aimed at
> protecting its users' privacy, I am trying to tackle one of our
> long-standing issue: we need to properly overwrite the system memory
> with zeros on shutdown in order to erase traces of the user activity.
> 
> 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.

> [1] https://tails.boum.org/
> [2] https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/grub/
> 
> 
> I am currently stuck on how to obtain a standalone GRUB image that could
> be kexec'ed from Linux.
> 
> When building an ELF image with the 'pc' port, kexec replies:
> 
>     Base address: 8200 is not page aligned
> 
> The next candidate looked like the 'multiboot' port. But I can't get an
> image that will work in qemu. I have tried to build a strictly minimal
> boot image using the following commands:
> 
>     ./configure --with-platform=multiboot --target=i386
>     make -j4
>     ./grub-mkimage -O i386-multiboot -C xz -d ./grub-core \
>         -o /tmp/multiboot.img
> 
> 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.

> Is there any known working way to test multiboot images?
> Is there a better path to be able to use kexec to load and execute GRUB?
> 
> 
> I would very much like to offer the `wipe_memory` command for inclusion
> in GRUB (and do the necessary refinements on the patch) once we have
> something that works from one end to the other for Tails.
> 
> Thanks for your help,
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: kexec GRUB, multiboot port and qemu

[Ague Mill]

[-- 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 --]