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
pgpFLakQ5MDs0.pgp
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel