From: John Richard Moser <nigelenki@comcast.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: Patch 4/6 randomize the stack pointer
Date: Thu, 27 Jan 2005 13:49:36 -0500 [thread overview]
Message-ID: <41F937C0.4050803@comcast.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0501271010130.2362@ppc970.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>What the hell?
>
>
> John. Stop frothing at the mouth already!
>
I'm coarse, I'm not angry.
> 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. Then again, I cut a gig and a half out
on top of that too with SEGMEXEC, so I'm probably answering "most people
are afraid of firecrackers" with "I stood through an atomic explosion
and it didn't bother me."
If it's simply not acceptable to do more than a few megs of
randomization, then randomization is simply not acceptable. Brute
forcing respawning/forking daemons is possible, and gets faster as your
entropy decreases.
I should probably test this, but in theory it'd also be possible to just
spew in a bunch of no-ops or aligned relative jumps and make a 64k or so
wide buffer that lets you jump to the same address regardless of
randomization and just wind up executing an extra N=rand(0,64k/ALIGN)
set of instructions before your actual shellcode. It becomes
infeasible, then impossible, as the randomization gap gets bigger; if
your stack is 10 megs, you can't inject 256M of no-ops to get around a
random stack alignment.
>>Red Hat is all smoke and mirrors anyway when it comes to security, just
>>like Microsoft. This just reaffirms that.
>
>
> No. This just re-affirms that you are an inflexible person who cannot see
> the big picture. You concentrate on your issues to the point where
> everybody elses issues don't matter to you at all. That's a bad thing, in
> case you haven't realized.
>
> Intelligent people are able to work constructively in a world with many
> different (and often contradictory) requirements.
>
Of course. I understand this, but I've come into the opinion that since
certain things are generally useful, they should be generally deployed.
If they become a problem, the option to disable them becomes very
useful. Even Exec Shield has PT_GNU_STACK AND a sysctl setting or 3 IIRC.
> A person who cannot see outside his own sphere of interest can be very
> driven, and can be very useful - in the "please keep uncle Fred tinkering
> in the basement, but don't show him to any guests" kind of way.
>
I'm actually very broad-minded; my opinions do change, when I see
something that changes my opinions. Normally, though, my opinions are
developed from an analysis of facts; so you have to change the facts
(i.e. make one thing better and overtake the quality of the other) to
change my opinions.
I've been wrong before, on rare occasions. Rare, but not impossible.
When it's displayed to me in a way that I actually understand that
certain facts I'm relying on are wrong, then I'm prone to re-evaluate my
decisions.
In the end, I've figured out that "not everybody likes pepsi," but also
that "diet soda is flavored with a dangerous neurotoxin and is bad for
EVERYBODY." Until you pick another flavoring, I'm not going to have
good things to say about your product. I do, however, know the
difference between "It's toxic to everyone" and "some people are alergic
to peanuts."
Not that that makes any connection to any existing system similar or
dissimilar to ES/PaX/W^X/etc (it intentionally does not).
> I have a clue for you: until PaX people can work with the rest of the
> world, PaX is _never_ going to matter in the real world. Rigidity is a
> total failure at all levels.
>
I'm not trying to get PaX in mainline, I'm just focused on the basic
concepts.
> Real engineering is about doing a good job balancing different issues.
>
> Please remove me from the Cc when you start going off the deep end, btw.
>
Sorry Linus, I normally don't read the CC list. I'll be mindful in the
future of that.
This will likely be the last CC you get from me.
> 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+Te/hDd4aOud5P8RAmMdAJ0cRImvV0YGkBPMpaOAaTCyQkCWXACaAj1d
JRfUcY+9UPTe3ZVn517MUbU=
=WbU8
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2005-01-27 18:49 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 10:11 Patch 0/6 virtual address space randomisation Arjan van de Ven
2005-01-27 10:12 ` Patch 1/6 introduce sysctl Arjan van de Ven
2005-01-27 10:36 ` Andi Kleen
2005-01-27 11:13 ` Arjan van de Ven
2005-01-27 18:16 ` Pavel Machek
2005-01-27 19:11 ` Ingo Molnar
2005-01-27 19:46 ` Dave Jones
2005-01-27 19:53 ` Ingo Molnar
2005-01-27 19:53 ` Arjan van de Ven
2005-02-04 21:27 ` Benoit Boissinot
2005-01-27 10:12 ` Patch 2/6 introduce helper infrastructure Arjan van de Ven
2005-01-27 10:41 ` Andi Kleen
2005-01-27 11:58 ` Arjan van de Ven
2005-01-27 12:27 ` Andi Kleen
2005-01-27 12:43 ` Arjan van de Ven
2005-02-01 21:14 ` Matt Mackall
2005-01-27 10:12 ` Patch 3/6 per process flag Arjan van de Ven
2005-01-27 10:13 ` Patch 4/6 randomize the stack pointer Arjan van de Ven
2005-01-27 10:21 ` Christoph Hellwig
2005-01-27 17:38 ` John Richard Moser
2005-01-27 17:47 ` Arjan van de Ven
2005-01-27 18:04 ` John Richard Moser
2005-01-27 18:09 ` Arjan van de Ven
2005-01-27 18:12 ` Christoph Hellwig
2005-01-27 18:16 ` Linus Torvalds
2005-01-27 18:28 ` Linus Torvalds
2005-01-27 18:55 ` John Richard Moser
2005-01-27 18:49 ` John Richard Moser [this message]
2005-01-27 19:30 ` Linus Torvalds
2005-01-27 19:48 ` Arjan van de Ven
2005-01-27 19:59 ` Linus Torvalds
2005-01-27 20:04 ` Arjan van de Ven
2005-01-27 20:08 ` John Richard Moser
2005-01-27 19:19 ` linux-os
2005-01-27 19:52 ` Julien TINNES
2005-01-27 20:02 ` Arjan van de Ven
2005-01-27 20:13 ` John Richard Moser
2005-01-27 21:33 ` jnf
2005-01-28 17:22 ` Paulo Marques
2005-01-28 17:51 ` John Richard Moser
2005-01-28 18:42 ` Ingo Molnar
2005-01-29 6:04 ` John Richard Moser
2005-01-27 20:37 ` linux-os
2005-01-27 20:45 ` John Richard Moser
2005-01-27 21:39 ` John Richard Moser
2005-01-27 21:53 ` Arjan van de Ven
2005-01-27 22:34 ` John Richard Moser
2005-01-29 2:50 ` Rik van Riel
2005-01-29 6:31 ` John Richard Moser
2005-01-29 8:10 ` Arjan van de Ven
[not found] ` <41FBB821.3000403@comcast.net>
2005-01-29 16:42 ` Arjan van de Ven
2005-01-29 16:59 ` John Richard Moser
2005-01-29 16:46 ` Arjan van de Ven
2005-01-29 17:04 ` John Richard Moser
2005-01-29 17:37 ` Jakub Jelinek
2005-01-29 17:49 ` John Richard Moser
2005-01-29 17:55 ` Christoph Hellwig
2005-01-29 18:10 ` John Richard Moser
2005-01-29 18:12 ` Rik van Riel
2005-01-29 18:16 ` Christoph Hellwig
2005-01-29 7:46 ` John Richard Moser
2005-01-27 18:40 ` Felipe Alfaro Solana
2005-01-27 22:31 ` Jirka Kosina
2005-01-28 5:58 ` Ingo Molnar
2005-01-28 19:02 ` David Lang
2005-01-28 7:33 ` Arjan van de Ven
2005-01-27 19:43 ` Julien TINNES
2005-01-28 0:10 ` H. Peter Anvin
2005-01-28 0:23 ` Roland Dreier
2005-01-28 1:06 ` H. Peter Anvin
2005-01-28 2:03 ` Horst von Brand
2005-01-28 8:45 ` Julien TINNES
2005-01-27 20:23 ` Christoph Hellwig
2005-01-27 20:27 ` Arjan van de Ven
2005-01-27 20:32 ` Christoph Hellwig
2005-01-27 20:35 ` Arjan van de Ven
2005-01-27 20:40 ` Rik van Riel
2005-01-27 20:42 ` Christoph Hellwig
2005-01-27 20:56 ` Arjan van de Ven
2005-01-27 21:13 ` Linus Torvalds
2005-01-27 10:13 ` Patch 5/6 randomize mmap addresses Arjan van de Ven
2005-01-27 10:14 ` Patch 6/6 default enable randomisation for -mm Arjan van de Ven
2005-01-27 11:45 ` Patch 0/6 virtual address space randomisation Julien TINNES
2005-01-27 11:57 ` Arjan van de Ven
2005-01-27 17:42 ` John Richard Moser
2005-01-27 19:34 ` Julien TINNES
2005-01-27 19:57 ` John Richard Moser
2005-01-27 20:13 ` Arjan van de Ven
2005-01-28 8:45 ` David Weinehall
-- strict thread matches above, loose matches on Subject: below --
2005-01-31 10:55 Patch 4/6 randomize the stack pointer linux
2005-01-31 17:28 ` John Richard Moser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41F937C0.4050803@comcast.net \
--to=nigelenki@comcast.net \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox