Re: Patch 4/6 randomize the stack pointer

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Linus Torvalds wrote:
> 
> On Thu, 27 Jan 2005, John Richard Moser wrote:
> 
>>>Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT 
>>>ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues 
>>>with usable virtual memory areas etc.
>>
>>It never bothered me on my Barton core or Thoroughbred, or on the Duron,
>>or the Thoroughbred downstairs.
> 
> 
> Me, me, me, me! "I don't care about anybody else, if it works for me it 
> must work for everybody else too".
> 

"Me" happens to be "Me sitting at a desk top doing word processing, IRC,
some Quake3 and Doom, listening to music, playing with Gimp, watching
videos, and running firefox."  I'm assuming "me" == "99% of all desktop
users," and that we also can't predict what all specialized machines need.

> See a possible logical fallacy there somewhere?

I see you're trying to lead me into saying we should be more focused on
supplying exactly what works for 100% of everybody, which we can't do.

> 
> The fact is, different people have different needs. YOU only need to care
> about yourself. That's not true for a vendor. A single case that doesn't
> work ends up either (a) being ignored or (b) costing them money. See the 
> problem? They can't win. Except by taking small steps, where the breakage 
> is hopefully small too - and more importantly, because it's spread out 
> over time, you hopefully know what broke it.

Something I wrote once

http://en.wikipedia.org/wiki/PaX

- --CLIP--
A DoS attack (or its equivalent) is generally an annoyance, and may in
some situations cause loss of time or resources (e.g. lost sales for a
business whose website is affected): however, no data should be
compromised when PaX intervenes, as no information will be improperly
copied elsewhere. Nevertheless, the equivalent of a DoS attack is in
some environments unacceptable; some businesses have level of service
contracts or other conditions which make successful intruder entry a
less costly problem than loss of or reduction in service. The PaX
approach is thus not well suited to all circumstances; however, in many
cases, it is an acceptable method of protecting confidential information
by preventing successful security breaches.
- --CLIP--

This doesn't just apply to PaX or Gr or whatever you want to claim I'm
trying to get into the kernel right now; it applies to everything.  In
some cases anything can be bad.  The idea is to realize that these are
*specialized* cases, and make a design decision:  A) allow a quick way
to disable the stuff (finegrained runtime with executable flags, or
disable in kernel); B) let the 1/100000000000000 people who this bothers
write a patch to change it themselves (RTLinux for example).

> 
> And when I say RH, I mean "me". That's the reason I personally hate
> merging "D-day" things where a lot of things change. I much prefer merging
> individual changes in small pieces. When things go wrong - and they will -
> you can look at the individual pieces and say "ok, it's definitely not
> that one" or "Hmm.. unlikely, but let's ask the reporter to check that
> thing anyway" or "ok, that looks suspicious, let's start from there".
> 
> So for example, 3GB of virtual space is enough for most things. In fact, 
> just 1GB is plenty for 99% of all things. But some programs will break, 
> and they can break in surprising ways. Like "my email indexing stopped 
> working" - because my combined mailboxes are currently 2.8GB, and it 
> slurps them all in in one go to speed things up.
> 

This is true.  I however have something like 300M of e-mail and I'm
subscribed to something like 15 or 20 mailing lists for about a year
now.  You of course have a work-around:  Don't try to load 800 gigs of
e-mail into memory all at once.  If you need to *quickly* parse this,
this may not be an acceptable work-around (though reading ahead and
dumping after processing, i.e. buffering, may be a good middle-ground).

Like I said, it's not something you'll hit every day on every machine,
and it's something that can be quickly worked around.  In the worst
case, disable all enhancements on the binary (using chpax or execstack
or whatever for whatever ASLR/NX system and God knows what else you're
using) for that binary or the system, depending on how fine-grained you
can control it.

I sympathise, really, but you're that one in ten-jillion.  :)

> (That wasn't a made-up-example, btw. I had to write this stupid email
> searcher for the SCO subpoena, and the fastest way was literally to index
> everything in memory. Thank gods for 64-bit address spaces, because I
> ended up avoiding having to be incredibly careful by just doing it on
> another machine instead).
> 

The fastest way is ALWAYS in memory :)  (unless you have $12000 SATA
drives with 2G of on-board cache and 500 track read-ahead)

> 			Linus
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+Uo5hDd4aOud5P8RAr06AJsHU/vklnUxii8o7QZA78EFXy5lyACeJYIE
0M9rggfLgNHZMJGej8oLrbE=
=HN6I
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/