linux-kernel - Re: [GIT PULL] x86: add brk allocator for very early allocations

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: <49B84EF5.3090705@goop.org>
Date:	Wed, 11 Mar 2009 16:53:25 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86: add brk allocator for very early allocations

Eric W. Biederman wrote:
> extend_brk is the wrong way to go.  We already have a better mechanism.
> find_e820_early paired with reserve_early.
>   

No doubt that's a better option when available.  But I want to allocate 
earlier than that.

> Allocating the early page tables are a very special case.   There is
> a case for cleaning up that mechanism and making more comprehensible.
> We should not be generalizing it, and making the kernel more fragile.
>   

More fragile?  I don't see that extend_brk() is a particularly fragile 
mechanism.  I guess a user could start over-using it and running out of 
the initial space.  That would fail in a fairly unambiguous way (there's 
a BUG_ON checking for an attempt to extend beyond __brk_limit), and 
would definitely be an abuse of the call.

My motivation for this patch is to dynamically allocate things very 
early, before the e820 map is available.  Specifically, I want to 
dynamically allocate various Xen datastructures which would otherwise 
statically waste space in the bss (in the case where you're running a 
Xen-enabled kernel on a non-Xen system).  It also allows me to scale 
them according to the memory size, etc.  I need to do this before e820 
is available; indeed, I need to do it to synthesize an appropriate e820 
map for the kernel to consume.

It is also nice that it generalizes head_32.S's pagetable construction, 
and mops up the bespoke DMI allocator.  There may well be some other 
potential users.  I think any static data in bss is fair game, 
particularly if it is only used conditionally.

    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/