linux-kernel - Re: [PATCH] i386: always clear bss

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: <m1ejlwr036.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 04 May 2007 11:05:17 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i386: always clear bss

"H. Peter Anvin" <hpa@...or.com> writes:

> Jeremy Fitzhardinge wrote:
>> 
>> Yes, that's more or less the same code, aside from using 0x40(%esi) as a
>> stack.  Would that be OK here?
>> 
>
> I saw the 0x40(%esi) stack stuff, and I'm utterly puzzled by it.  There
> is no reason one can't set up %esp to point to a hunk in ordinary memory
> and use it?

That is what we are doing, remind me to make certain we have this
field of the boot protocol documented as permanently reserved for
this.

This comes from the relocatable kernel patches where we run the
kernel where the bootloader chooses to put it assuming we are >= 1M.

The problem is that we don't have any IP relative data access
instructions, we don't have a stack, and so the only valid address
that we know is valid is %esi.  Once we compute where we are running
we can setup a base address register and a stack and everything is
easy, but the bootstrap to figure out where we are is just a little
tricky.

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/