-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Sun, 2006-06-04 at 14:35 -0400, John Richard Moser wrote:
>
>> Stack and mmap() VMA alignment is based on PAGE_SIZE.
>
> which breaks ppc64 for hugetlbs at least.
>
>> Explain "randomization within each region." I thought mmap()
>> randomization just shifted the mmap() base around at process start?
>
> ia64 and iirc also ppc64 have different regions in the VA space for
> different types of mmaps. Hugetlb, executable, non-cachable etc etc.
>
Whoa.
Looks like I need a little education on this subject before I can come
up with a solution to this one.
>
>>>> - Less code to maintain
>>> we're talking less than a handful lines of code again, most of which is
>>> NOT shareable.
>>>
>> The relevant parts are sharable. I just moved this stuff out into
>> fs/exec.c:
>
> ... and made it a lot more complex.
>
My mm.h macros are a lot more complex, probably. Although it would help
if you pointed out where "complexity" shows up; honestly for the most
part it looks clean and neat to me, besides a few rough edges and
excessive commenting.
>> Yes, this is the same solution as with TASK_SIZE (which is about 3 lines
>> above this...)
>
> the rules for mmap_base vary per architecture, and even per binary time.
> In fact the meaning of it is very much free for the architecture to
> determine/use.
So the base can't just be randomized once?
>>>> 2. I can get away with exactly 1 arch_align_stack() function, instead
>>>> of 1 per architecture.
>>> I don't think that that is fundamentally possible, see above.
>> Did it already, for any STACK_ALIGN, any PAGE_SIZE, any level of
>> entropy, and for stacks that grow up and down. The only situations that
>> I haven't handled are stacks that grow up and down at the same time,
>
> ok so you haven't dealt with ia64 yet ;)
>
So far IA-64 sounds like "we designed this while on acid," but fair
enough. Explain.
>> and
>> stacks that teleport data to other dimensional planes.
>
> and with stacks that need different alignment based on binary type (mips
> has 4 or so of those) or .. or ..
Use the same solution as TASK_SIZE, although 4 binary types is going to
become painful yes. You can do it with a #define but I'm getting the
feeling that these parts may need per-architecture and per-binary-type
functions to sort it out (in the same way that there was an mmap_base()
for IA-32 and x86-64 in x86-64).
>
>
>> The level of stack entropy was definitely not per-architecture;
>
> no but it COULD be. I haven't looked at the ia64 randomization, but I'd
> not be surprised if it was different
VMA stack entropy was in fs/binfmt_elf.c and rather hard coded.
>
>
>>>> Part of the bulk stems from the fact that I didn't do randomization
>>>> based on range, but based on bits of entropy.
>>> I don't understand why you want to do that. It will make code a lot more
>>> complex, and at the same time it limits you to powers-of-two in
>>> practice.
>>>
>> In practice if you can assume an attacker can reasonably break 17 bits
>> of entropy, then you can assume that he can possibly (but unlikely)
>> double his attack efficiency and break 18 bits. You would want to step
>> it up to 20 bits or so to get a few steps beyond "unlikely" into "we are
>> pretty confident this is impossible."
>
> I think you totally missed the point. *I DON'T CARE ABOUT "BITS OF
> ENTROPY" IN THE CODE*. The code cares about how much it is in actual
> bytes. Sure when talking about it in documents or analysis it may make
> sense to do the bits math. BUT NOT IN THE CODE.
I was only addressing the "it limits you to powers-of-two" part, not
code complexity. The point was that strictly speaking it's not that
great to be able to do it more fine-grained. This doesn't mean people
wouldn't want to (hey I may want my stack and mmap() to move around by a
gig on i386, it'll barely work and X will break half the time, but WHY
would I want to?).
>
> That was my point, and all there was to it. You add complexity and
> limitations TO THE CODE for no good reason at all.
>
I'll address those in the next pass. It will involve a little integer
multiplication/division to provide proper sub-page alignment for the
stack; VMA alignment can use PAGE_ALIGN().
>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRIMwPws1xW0HCTEFAQK5aQ//W9m6h2DbSXP0yrNRKGgv7SCzZDbacsds
eXubeG8l1OAnMmsDaAYgnX5g/aAb0md7xNi39CT5x4dgQiM+dyCX7TYIG/TaaN5+
lLLKt/xQZm73hUxk7s4pKiBN7OY8n5YwaEiP5JpfZZi/27KxV0DR8s1VDsRj8xGz
3uuEF6hsZXZZKIuG46pG6nwHphJNQkCZp6G8tZdQWC+LuclulB50PNxNMzUxe31S
13M7q81icGcbHnOvUvA7EHexa1Ru22VCl8NjTwogTwP/eIVcN/acE17EO/m/xfIz
g9JXCgeF+soIk3SQTydR70CZwGENxs/mrYTXksWMDRsGmOK2qg5pSo7sr4V98g5P
jF6x/044JAKWB/fmlEr5QxFCGFHuPSDSqeZHPiRWQnbn8nH2VB9aSRGK/mpx+rpJ
/xIZrJLndFc06CdLe71inrjlBIhAQ58XuSd5pGGmLiKmwXiOGCDaWS5Qb0YChV2i
hujNZ4AhuuPT9TiMhi842NR3Dd8NTy/mY1JlqUtao8ofnhQqf6GndDuwTrIn3TOL
lm6X7EBuVbhXggsnjnQiaK10k90qU5Pgy9eqJYL8vybbuLu5uOwlxsuBM4ceIUya
oyVxOYnySND2FpxhH55IfAnxTC2I1avd+V4vvuIc3hJEWUbugf6iUzX72/0rYo88
HL5S4HK8UbQ=
=zZEn
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
