[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44F3555F.6060306@zytor.com>
Date: Mon, 28 Aug 2006 13:43:11 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Matt Domsch <Matt_Domsch@...l.com>
CC: Alon Bar-Lev <alon.barlev@...il.com>, Andi Kleen <ak@...e.de>,
Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
johninsd@....rr.com
Subject: Re: [PATCH] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
(ping)
Matt Domsch wrote:
> On Mon, Aug 28, 2006 at 12:00:37PM -0700, H. Peter Anvin wrote:
>> Matt Domsch wrote:
>>> No reason. I was just trying to be careful, not leaving data in the
>>> upper bits of those registers going uninitialized. If we know they're
>>> not being used ever, then it's not a problem. But I don't think
>>> that's the source of the command line size concern, is it?
>>>
>> No, it's treating the command line as a fixed buffer, as opposed to a
>> null-terminated string. This was always a bug, by the way.
>
> OK, I'll look at fixing that, and using %esi throughout.
>
There is a lot of weirdness in this code; it's broken in an enormous
amount of ways (sorry, Matt). This comment, for example:
pushl %esi
cmpl $0, %cs:cmd_line_ptr
jz done_cl
movl %cs:(cmd_line_ptr), %esi
# ds:esi has the pointer to the command line now
... doesn't handle the old boot protocol, and doesn't at all deal with
the fact that cmd_line_ptr is an absolute address, and not at all
relative to SETUPSEG, which is the normal value for %ds at this point.
For the old protocol, this is a 16-bit pointer which is relative to
INITSEG (not SETUPSEG), but this code just completely ignores it.
I'll hack up a patch for this.
-hpa
-
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