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 18:39:38 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Ian Campbell <ijc@...lion.org.uk>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

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.

> > > + * 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.

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

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ