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
| ||
|
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/
Powered by blists - more mailing lists