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

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

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

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Eric W. Biederman wrote:
>> Using 0x40 as a stack would be ok.
>>   
>
> OK.
>
>> There are issues with CONFIG_RELOCATABLE and V!=P that I'm not
>> comfortable with yet, because we can't tell the difference.
>
> But it doesn't matter in this case, does it?  It just needs to find the
> current address, whether it be virtual or physical, of the bss.  It
> doesn't assume any particular offset.

For the bss that sounds correct.

> When does the relocation happen?   Does the bzImage loader do it as part
> of decompression?  Or does the kernel do it to itself?  (Not that it
> makes any difference here.)

Currently right after compression just before we jump to startup_32.
But if the usage of vmlinux continues to increase we should really
move it to just after startup_32.  Which is where we run into problems
with supporting virtual addresses at our normal kernel entry point.

The relocation doesn't live just after startup_32 now because it is
hard to put there.

The practical challenge is that we need to compute the delta between
where we are at and where we were compiled for, and with possibility of
virtual address and physical address I don't know how we would compute
where we are at, in a way we could compare to our compile time physical
or virtual addresses.

Xen when it comes it at a completely isolated entry point is fine
because there is no pretence of code reuse, and we don't have to auto-detect
how we were started.

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/