linux-kernel - Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

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]

Date:	Sun, 20 Jan 2008 10:48:39 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Ian Campbell <ijc@...lion.org.uk>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native
 format.

Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 04:44:50PM +0000, Ian Campbell wrote:
>> Indeed it does. I don't have any non-PAE to test it but I turned the
>> failure case into a simple jmp to hlt_loop since we ought never to get
>> here in any case.
> 
> There are various loaders (kexec, elilo, ...) that skip the 16bit code
> and jump directly to 32bit head.S. So in theory those could hit it.
> But still having the loop only is probably fine.
> 

It's probably just as well, since we don't really know how to get a 
message out in such an environment anyway...

>>>> + * Since a paravirt guest will never come down this path we want
>>>> + * native style page table accessors here.
>>>> + */
>>>> +#undef CONFIG_PARAVIRT
>>> Seems quite fragile. I'm sure that would hurt later.
>> The problem here is that we explicitly want native accessors because
>> it's too early to use the pv ops since we are still running P==V. A PV
>> kernel boot will never come down this path -- it is diverted earlier in
>> head_32.S so using the native versions are appropriate.
> 
> Then i think it would be cleaner to just open code everything without
> any accessors.

I was thinking about this yesterday, and it seems to me that there are 
two cleaner options here...

- either we should put in the full machinery to be able to run C code 
compiled with -fPIC/-fPIE before paging is enabled.  Unfortunately gcc 
generates R_386_GOT32 relocations for external references even with 
-fPIE, so we'll have to put in some code to adjust the GOT (easy enough 
to do.)

As far as the native accessors are concerned, the right thing to do 
would is to use the native_ forms thereof, not #undef CONFIG_PARAVIRT.

- alternatively, we recognize that this isn't all that big of a piece of 
code and doing it in C really isn't necessary.  We can have a small 
assembly loop for PAE that matches the small assembly loop we already 
have for !PAE.

>> As hpa says we can't be above 4G at this point. Probably I can use some
>> variant of make_pte now though.
> 
> The 32bit cast still feels unclean. After all the PTE is not 32bit.

No, but (pte_t *) is 32 bits.  To be more "Linuxy" it probably should be 
(long) or (unsigned long) though.

	-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/