linux-kernel - Re: [PATCH] Make bootsector stub 16-bit-only (i386)

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]

Message-ID: <20070508183232.GA13225@mailshack.com>
Date:	Tue, 8 May 2007 20:32:32 +0200
From:	Alexander van Heukelum <heukelum@...lshack.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	"Antonino A. Daplas" <adaplas@...il.com>
Cc:	Andi Kleen <ak@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Make bootsector stub 16-bit-only (i386)

On Tue, May 08, 2007 at 03:28:17AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 12:44:52 +0200 Alexander van Heukelum <heukelum@...lshack.com> wrote:
> > --- a/arch/i386/boot/bootsect.S
> > +++ b/arch/i386/boot/bootsect.S
> > @@ -44,7 +44,7 @@ #endif
> >  _start:
> >  
> >  	# Normalize the start address
> > -	jmpl	$BOOTSEG, $start2
> > +	jmpw	$BOOTSEG, $start2
> 
> Sigh, another blow struck in the ongoing struggle between my Vaio and the
> rest of the world.
> 
> Stone-cold black-screen lockup immediately upon boot.
> 
> Stock FC5 install, config at
> http://userweb.kernel.org/~akpm/config-sony.txt

Sigh... sounds impossible.

I assume this is repeatable? And this patch changes behaviour? What do
you mean by immediate? Before or after decompression?

Fishy... As Andi and Peter have mentioned, this code is not executed.
There is only one user of the same memory area this early... video.S
uses it to store some collected data, but as far as I can see only the
'CONFIG_VIDEO_RETAIN' code also reads it back. If it happens before
decompression, could you see if changing
	#define CONFIG_VIDEO_RETAIN -> #undef CONFIG_VIDEO_RETAIN
in arch/i386/boot/video.S changes anything?

Do you select a non-standard textmode? Does vga=ask show up?

*looks around some*

Oh! A padding hole in a struct! That could be a problem. If the freeze
is after decompression, could you test if this makes it work again?

Greetings,
	Alexander

---

Commit 89ec4c238e7a3d7e660291f3f1a8181381baad77 introduced a discrepancy
between the struct screen_info which is used by the C code, and the
PARAM_* offsets which are used in the real-mode kernel. This is an
attempt to rectify the situation, but I have no way to test it.

Signed-off-by: Alexander van Heukelum <heukelum@...lshack.com>

---

diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
index 8143c95..8e404cb 100644
--- a/arch/i386/boot/video.S
+++ b/arch/i386/boot/video.S
@@ -95,7 +95,8 @@ #define PARAM_VESAPM_SEG	0x2e
 #define PARAM_VESAPM_OFF	0x30
 #define PARAM_LFB_PAGES		0x32
 #define PARAM_VESA_ATTRIB	0x34
-#define PARAM_CAPABILITIES	0x36
+#define PARAM_VESA_PAD		0x36
+#define PARAM_CAPABILITIES	0x38
 
 /* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
 #ifdef CONFIG_VIDEO_RETAIN
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index b02308e..0a2e892 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -41,8 +41,8 @@ struct screen_info {
 	u16 vesapm_off;		/* 0x30 */
 	u16 pages;		/* 0x32 */
 	u16 vesa_attributes;	/* 0x34 */
-	u32 capabilities;       /* 0x36 */
-				/* 0x3a -- 0x3b reserved for future expansion */
+	u16 vesa_pad;		/* 0x36 */
+	u32 capabilities;       /* 0x38 */
 				/* 0x3c -- 0x3f micro stack for relocatable kernels */
 };
 
-
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/