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]

Message-ID: <m1d4rqipex.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 24 Jan 2008 19:56:22 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Ian Campbell <ijc@...lion.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Mika Penttilä <mika.penttila@...umbus.fi>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

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

> Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>> No, if Xen wasn't an issue there wouldn't be anything to do for the PAE case
>>> at all (since the PGD is trivial.)
>>>
>>> Copying PMDs is more or less an analogous case of the !PAE case, once the
>>> allocation is already done.  The allocation should be trivial though, since
>>> this would be a one-time thing.
>>
>> I think we're in vehement agreement here.  In either case, its just a matter
>> of something like:
>>
>>    memcpy(pgd, &pgd[USER_PTRS_PER_PGD], sizeof(pgd_t) * KERNEL_PTRS_PER_PGD);
>>     which would work for both PAE and non-PAE.
>>
>>>> It would be easy enough to add some code on xen side to look for pmd aliases
>>>> when using/pinning a pagetable, and allocate'n'copy a new pmd page as
>>>> needed.  That way the core code can ignore the issue.
>>>
>>> As much as I'd rather see Xen fixing this than having it continue to impact
>>> the kernel, I presume it will take some time to flush the broken hypervisors
>>> out?
>>
>> Sorry, I was unclear.  I meant in the purely Xen-specific parts of the kernel
>> (arch/x86/xen).  It wouldn't require a hypervisor change.
>>
>
> Oh, that makes that option much more viable and probably preferrable.

Note.  I don't believe we use either trampoline (cpu startup or acpi wakeup)
in the hypervisor case (esp Xen).  So we should be able to completely ignore
Xen and do the memcpy of pgd entries.

I expect Xen gives us other cpus already in protected mode (which is overall
the sane thing to do).

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/