linux-kernel - [PATCH] save registers around VESA BIOS calls

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070831161746.GA5459@ele.uri.edu>
Date:	Fri, 31 Aug 2007 12:18:57 -0400
From:	Will Simoneau <simoneau@....uri.edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] save registers around VESA BIOS calls

On 11:05 Fri 31 Aug     , Will Simoneau wrote:
> On 23:41 Thu 30 Aug     , H. Peter Anvin wrote:
> > H. Peter Anvin wrote:
> >> Will Simoneau wrote:
> >>> While trying to put together a new kernel for my laptop (Dell I5150, as
> >>> in subject) I found that recent kernels just don't boot. Right after
> >>> grub loads the kernel, before the "Uncompressing Linux" message is
> >>> shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
> >>> keyboard lock LEDs respond). It seems to be caused by the new x86 setup
> >>> code.
> >>>
> >>> My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
> >>> I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
> >>> triggers a non-functioning boot.
> >>>
> >>> This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
> >>>
> >>> What should I do next to debug this problem?
> >> Can you put in some printf's in the code and see how far it gets?
> >
> > Specifically, the places to add printf's are to main() in main.c and 
> > go_to_protected_mode() in pm.c.
> >
> > 	-hpa
> 
> It dies in vesa_probe() right after calling int10 with ax=4f01 and
> checking the return status, which was 0x004f (success). This happens on
> the third iteration of the loop; the first two modes it finds are
> framebuffer modes. This would be just after line 72 in video-vesa.c .
> 
> I have CONFIG_VIDEO_VESA=y and CONFIG_FB=y, but am not passing the
> kernel options that would use vesafb as the console.

Apparently some VESA BIOS implementations clobber our registers when called.
Tell gcc about it.

This makes my Dell Inspiron 5150 boot correctly instead of hanging.

Signed-off-by: Will Simoneau <simoneau@....uri.edu>

---

--- linux-2.6/arch/i386/boot/video-vesa.c.old	2007-08-31 11:51:40.478575122 -0400
+++ linux-2.6/arch/i386/boot/video-vesa.c	2007-08-31 11:51:10.980602450 -0400
@@ -39,9 +39,11 @@
 
 	vginfo.signature = VBE2_MAGIC;
 
-	/* Optimistically assume a VESA BIOS is register-clean... */
 	ax = 0x4f00;
-	asm("int $0x10" : "+a" (ax), "=m" (vginfo) : "D" (&vginfo));
+	asm("int $0x10"
+	    : "+a" (ax), "=m" (vginfo)
+	    : "D" (&vginfo)
+	    : "ebx", "ecx", "edx", "esi");
 
 	if (ax != 0x004f ||
 	    vginfo.signature != VESA_MAGIC ||
@@ -66,7 +68,8 @@
 		ax = 0x4f01;
 		asm("int $0x10"
 		    : "+a" (ax), "=m" (vminfo)
-		    : "c" (mode), "D" (&vminfo));
+		    : "c" (mode), "D" (&vminfo)
+		    : "ebx", "edx", "esi");
 
 		if (ax != 0x004f)
 			continue;

Content of type "application/pgp-signature" skipped