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:	Mon, 7 Feb 2011 21:09:50 -0800
From:	Yinghai Lu <>
To:	Jeremy Fitzhardinge <>
Cc:	Stefano Stabellini <>,
	"H. Peter Anvin" <>,
	"" <>,
	"" <>,
	"" <>,
	Konrad Rzeszutek Wilk <>,
	Jan Beulich <>
Subject: Re: [PATCH] x86/mm/init: respect memblock reserved regions when
 destroying mappings

On Mon, Feb 7, 2011 at 8:56 PM, Jeremy Fitzhardinge <> wrote:
> On 02/07/2011 07:12 PM, Yinghai Lu wrote:
>> On 02/07/2011 01:56 PM, Jeremy Fitzhardinge wrote:
>>> On 02/07/2011 11:00 AM, Yinghai Lu wrote:
>>>> On 02/07/2011 10:58 AM, Stefano Stabellini wrote:
>>>>> On Mon, 7 Feb 2011, Yinghai Lu wrote:
>>>>>> On 02/07/2011 08:50 AM, Stefano Stabellini wrote:
>>>>>>> On Sun, 6 Feb 2011, Yinghai Lu wrote:
>>>>>>>> On 02/05/2011 11:30 PM, H. Peter Anvin wrote:
>>>>>>>>> On 02/05/2011 11:02 PM, Yinghai Lu wrote:
>>>>>>>>>> why not just move calling cleanup_highmap down?
>>>>>>>>>> something like attached patch.
>>>>>>>>> This patch looks very clean and looks on the surface of it like it is
>>>>>>>>> removing some ugly ad hoc code, but (as always) it needs a description
>>>>>>>>> about the problem it solves and why it is correct.
>>>>>>>> Sure.
>>>>>>>> Jeremy and xen guys, can you please check if it works well with xen ?
>>>>>>> Actually this patch makes things worse on xen, because before
>>>>>>> cleanup_highmap() wasn't called at all on xen (on purpose) and now it
>>>>>>> is, fully destroying all the mappings we have at _end.
>>>>>>> Can we add a check on memblock reserved regions in cleanup_highmap()?
>>>>>>> Otherwise could we avoid calling cleanup_highmap() at all on xen?
>>>>>> why DO xen need over-mapped kernel initial mapping?
>>>>>> what is in that range after _end to 512M?
>>>>> The mfn list that is the list of machine frame numbers assigned to this
>>>>> domain; it is used across the kernel to convert pfns into mfns.
>>>>> It passed to us at that address by the domain builder.
>>>> is it possible for you to pass physical address, and then map it in kernel?
>>> That is possible in principle, but very difficult in practice.
>>> What's wrong with honouring reserved memory ranges under all circumstances?
>> why punishing native path with those checking?
> Why is it punishing anyone to expect memory reservations to be observed?
>> please check if
>> +      * max_pfn_mapped is set to KERNEL_IMAGE_SIZE >> PAGE_SHIFT in
>> +      *   head64.c::x86_start_kernel(), aka native path
>> +      */
>> +     if (max_pfn_mapped != (KERNEL_IMAGE_SIZE >> PAGE_SHIFT))
>> +             return;
>> could be used to skip clear highmap for xen path?
> Seems pretty ad-hoc.

then what is size for mfn-list after _end...

could be copied or move to BRK.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists