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]
Date:	Sun, 29 Apr 2007 00:51:09 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Bart Trojanowski <bart@...ie.net>
Cc:	fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Subject: Re: [Fastboot] restoring x86 BIOS state before reboot

Bart Trojanowski <bart@...ie.net> writes:

> Hi all,
>
> I am looking at a two stage boot where linux is loaded to do some system
> initialization before booting to Windows, which needs BIOS.
>
> I am interested in bypassing the BIOS on the second boot.
>
> I wanted to know if anyone has attempted to restore the BIOS memory such 
> that this could be attempted.  If not, I would love to get some pointers
> :)
>
> My plan right now is to backup the 128k of memory under 0x10000 to some
> staging memory under 0x90000, temporarily while in real mode, and then
> move it up somewhere higher once the kernel is running.
>
> Then on reboot I hope to undo the above and jump to 0x00007c00.
>
> Does this approach have any merit?

The primary problem isn't so much the BIOS memory.  That is usually
preserved.  But rather the BIOS gets confused at the massive change
in hardware state.  At least I think that is what happens.

On some BIOS/kernel configuration it isn't a problem I think I
got maybe a 20% success rate trying to use the 16bit linux entry
point that starts the new kernel from kexec when I was investigating
it.

You might get a little more success if you backup the BIOS memory
I don't know.

As long as you are not coming out of a panic situation there is
no theoretical reason why you shouldn't get the BIOS back and
working again, but the how of it is a challenge.

The possibility I keep playing with is to load the Bochs BIOS or
some other implementation of the basic boot services that I have
control over so that if it doesn't work the code can be fixed.
There has been some limited success with this technique in the
context of LinuxBIOS.

The ACPI tables should be reusable as is.

It may also be worth investigating if it is possible to bypass
the part of windows that uses BIOS calls.  I really don't have
a clue how a modern windows systems boots.

Eric
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ