Hi,
This seems to be a bad start for me, because I missed to submit a file in my
first patch, and a comment got lost in my second. Hopefully nobody was
fooled by now. This time a complete submission of patch 1+2 is appended, tested
and verified on my box. Other corrections still pending.
Patch 1 and 2 deal with the interface BIOS loader/chainloader and stage 1,
getting rid of some assumptions GRUB stage 1 implicitely makes.
Wolf Lammen
--
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
This is the first in a series of patches that removes a bug and some glitches
from GRUB stage 1. This is against grub-0.94 (alpha)
Submitted by Wolf Lammen, ookami1<at>gmx<dot>de
I looked through the complete code of stage 1 and found some oddities.
This patch addresses one: The use of cli in the very beginning of the code.
I consider this instruction as pointless, so one should remove it. Impact:
Saves a valuable byte of code, without doing any harm.
A comment says, that we are not safe there (to allow interrupts). This
could be true only, if a sloppy chainloader or a buggy BIOS did not set
up a proper stack pointer *and* had enabled interrupts before jumping to
stage 1. In the rare case this holds true, then, indeed, if a hardware interrupt
occurs, while the CPU processes the very first instructions of stage 1, the
computer will inevitably crash.
But how could a CLI help about this? The jump instruction at address 0x7C00
has been executed unprotected before, so any pending interrupt would have occured
there latest, using the bogus stack pointer.
CLI protects only future instructions, thus narrowing the dangerous gap by
not even a micro second on old 386, before stage 1 sets up his own and valid stack.
Reordering the instructions, so that a valid stack pointer is set up first,
simply does what a CLI could do in such a messy situation.
--- grub-0.94/stage1/stage1.S 2003-07-09 13:45:51.000000000 +0200
+++ grub-latest/stage1/stage1.S 2004-02-06 12:35:21.000000000 +0100
@@ -105,7 +105,13 @@
after_BPB:
/* general setup */
- cli /* we're not safe here! */
+ xorw %ax, %ax
+ movw %ax, %ss /* automatically locks the following instruction */
+
+ /* set up the REAL stack */
+ movw $STAGE1_STACKSEG, %sp
+ sti /* just in case the BIOS or a chainloader disabled interrupts
*/
+
/*
* This is a workaround for buggy BIOSes which don't pass boot
@@ -124,15 +130,8 @@
real_start:
- /* set up %ds and %ss as offset from 0 */
- xorw %ax, %ax
+ /* set up %ds as offset from 0 */
movw %ax, %ds
- movw %ax, %ss
-
- /* set up the REAL stack */
- movw $STAGE1_STACKSEG, %sp
-
- sti /* we're safe again */
/*
* Check if we have a forced disk reference here
This is the first in a series of patches that removes a bug and some glitches
from GRUB stage 1. This is against grub-0.94 (alpha)
Submitted by Wolf Lammen, ookami1<at>gmx<dot>de
I looked through the complete code of stage 1 and found some oddities.
This patch addresses one: The use of cli in the very beginning of the code.
Grub patches an address within the code directly, so when you insert new
instructions, this address moves around. The way this patch modifies stage 1
requires patching the header file as well.
--- stage1.h 2004-02-08 16:59:49.000000000 +0100
+++ stage1.h.new 2004-02-08 16:53:19.000000000 +0100
@@ -52,7 +52,7 @@
#define STAGE1_STAGE2_SEGMENT 0x48
/* The offset of BOOT_DRIVE_MASK. */
-#define STAGE1_BOOT_DRIVE_MASK 0x4d
+#define STAGE1_BOOT_DRIVE_MASK 0x54
/* The offset of a magic number used by Windows NT. */
#define STAGE1_WINDOWS_NT_MAGIC 0x1b8
This is the second in a series of patches that removes a bug and some glitches
from GRUB stage 1. This is against grub-0.94 (alpha), my first patch applied.
Submitted by Wolf Lammen, ookami1<at>gmx<dot>de
I looked through the complete code of stage 1 and found some oddities.
This patch addresses one: The state of the direction flag (DF) is not initialized
when it is used. This may be seen as a minor bug. Impact: Increases the code by 1
byte, removes a precondition (DF is cleared, when stage1 is called) and several
invariants (all BIOS INT 13 calls preserve the DF). Robustness of the code is
increased. Prevents stage1 to print rubbish onto the screen, should DF be set.
Details: the message routine uses the LODS instruction, whose operation depends on
the direction flag, which is never initialized in stage 1. Thus it is still in a
state set by the BIOS/chainloader, when control is passed to stage1.
To my knowledge, specs do not say anything about the state of the flags register,
when the MBR is started. So it is unwise to assume something specific. In reality,
though, most loaders seem to clear DF, otherwise you would have been flooded with
bug reports.
The message routine is the only location where a string instruction (LODS,STOS etc.)
is used. We place our CLD there, so we get rid of some invariants as well. A BIOS
INT 13 call may clobber this flag now, it won't hurt us any longer.
This patch is orthogonal to my previous one and may be applied alone.
--- grub-patch.1/stage1/stage1.S 2004-02-07 08:46:45.000000000 +0100
+++ grub-patch.2/stage1/stage1.S 2004-02-07 09:10:35.000000000 +0100
@@ -416,6 +416,7 @@
movb $0xe, %ah
int $0x10 /* display a byte */
message:
+ cld
lodsb
cmpb $0, %al
jne 1b /* if not end of string, jmp to display */
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
