linux-kernel - Re: brk patches..

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49AB1FE6.8030300@goop.org>
Date:	Sun, 01 Mar 2009 15:53:10 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: brk patches..

Yinghai Lu wrote:
>> But its no different from what i386 does now to allocate its initial
>> pagetables.  How does this not break now?
>>
>>     
>
> it will try to use initial page table af first, and it is not big
> enough, it will according to e820 and other reserved_early areas to
> find good positions.
>   

head_32.S has no such logic.  It just starts building the kernel 
mappings directly after _end, starting at pg0, and uses as much space as 
it needs.  For a !PSE CPU with a large kernel, that can be quite a lot 
of space.  Only later, when its creating the linear memory mappings, 
does it search around in the e820 tables (which it now has access to) 
for space.

The whole point of the brk segment was to have a way of allocating some 
memory very early, before e820 is even available.  If you really think 
this is dangerous, then we can easily extend the bss in the linker 
script to include the brk memory, and release any leftover when we do 
the normal bootmem freeup.  That would also give us a well-defined upper 
limit on how much brk memory can be allocated; its a bit undefined at 
the moment, as it depends on how much slop there is after the kernel 
mapping.

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