11:11 p.m.
Hi,
On Tue, May 25, 2010 at 11:45:44PM -0400, Kyle McMartin wrote:
On Tue, May 25, 2010 at 04:37:13PM -0700, Kees Cook wrote:
> Hi Kyle,
>
> Here's my linux-2.6 branch with 3 NX-emulation patches stacked on top:
>
> http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary
>
> I think all three should be merged, but I kept them separate for your
> review.
Can I pull this tree from somewhere?
Yes, the git URL for this is:
git://kernel.ubuntu.com/kees/linux-2.6.git
In looking at how "exec-shield" is used, I was thinking that maybe the
"nonexec" flag should be used instead. It could have multiple settings,
maybe. It seems like it could be used for:
off
hw-only
emu-if-needed
There also seems to be the "2" setting which ignores the stack-exec
markings, but that seems like it should be a separate feature. If we can
clean it up a little more, I'd really like to try to for upstream
inclusion. I know there has been resistance to it in the past, but
nearly every distro includes this patch set now; it's silly not to have it
upstream.
The second commit "x86: clean up nx-emu for ia32-only" adds a bunch more
#ifdef CONFIG_X86_32 around things, mostly I think the primary change in
behavior that would be visible to Fedora would be having the "exec-shield"
sysctl vanish on x86_64, and to fall back to mainline ASLR in the non-emu
case.
> Is there a better place (public Fedora mailing list?) for me to
send these?
>
fedora-kernel-list(a)redhat.com if you want.
Done! :)
-Kees
--
Kees Cook
Ubuntu Security Team
11:37 p.m.
New subject: NX emulation
On Tue, May 25, 2010 at 09:11:09PM -0700, Kees Cook wrote:
Yes, the git URL for this is:
git://kernel.ubuntu.com/kees/linux-2.6.git
Doesn't appear to work?
kyle@dreadnought ~/src/linux-2.6 $ git remote
add kees-execshield git://kernel.ubuntu.com/kees/linux-2.6.git
kyle@dreadnought ~/src/linux-2.6 $ git fetch kees-execshield
kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)
In looking at how "exec-shield" is used, I was thinking
that maybe the
"nonexec" flag should be used instead. It could have multiple settings,
maybe. It seems like it could be used for:
off
hw-only
emu-if-needed
There also seems to be the "2" setting which ignores the stack-exec
markings, but that seems like it should be a separate feature. If we can
clean it up a little more, I'd really like to try to for upstream
inclusion. I know there has been resistance to it in the past, but
nearly every distro includes this patch set now; it's silly not to have it
upstream.
Yes, we've been saying for a while that the randomization stuff needs to
be gutted from exec-shield. There is still a lot of work left cleaning
up exec-shield, all the hooks are pretty out of order.
The second commit "x86: clean up nx-emu for ia32-only" adds
a bunch more
#ifdef CONFIG_X86_32 around things, mostly I think the primary change in
behavior that would be visible to Fedora would be having the "exec-shield"
sysctl vanish on x86_64, and to fall back to mainline ASLR in the non-emu
case.
I suspect all this is still too invasive in the generic code to be
palatable.
> > Is there a better place (public Fedora mailing list?) for
me to send these?
> >
>
> fedora-kernel-list(a)redhat.com if you want.
Cheers, Kyle
2:58 a.m.
New subject: NX emulation
Doesn't appear to work?
kyle@dreadnought ~/src/linux-2.6 $ git remote
add kees-execshield git://kernel.ubuntu.com/kees/linux-2.6.git
kyle@dreadnought ~/src/linux-2.6 $ git fetch kees-execshield
kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)
It worked for me.
That seems to be a large uncoordinated branch of many topics.
I guessed just from the log summary which commits are these ones:
git log -n3 6bf4df3
(I haven't really reviewed the changes.)
Kees, if you are looking for review, putting these on an isolated topic
branch for people to look at easily is probably a good idea.
Yes, we've been saying for a while that the randomization stuff
needs to
be gutted from exec-shield. There is still a lot of work left cleaning
up exec-shield, all the hooks are pretty out of order.
It was vaguely on my list for ages to clean up execshield and slice it into
separate patches, but I just gave up on ever getting around to it. One
should probably ping Ingo, since (AFAIK) he did it all to begin with, back
in the beforetime, the long, long ago.
The exec-shield boot/sysctl parameter has never made a whole lot of sense
to me. The "exec-shield" stuff is really about three separate things. If
they need knobs, it's always seemed to me they should have separate knobs.
I suspect all this is still too invasive in the generic code to be
palatable.
I haven't really looked at Kees' patches. But having considered before
factoring this stuff out to cleanish, the i386 "NX emulation" stuff seemed
like the first thing to do and not hard to do fairly cleanly. (Not that
this motivated me to bother doing it.)
Thanks,
Roland
2:02 p.m.
New subject: NX emulation
Hi,
On Wed, May 26, 2010 at 12:58:01AM -0700, Roland McGrath wrote:
Kyle said:
> Doesn't appear to work?
>
> kyle@dreadnought ~/src/linux-2.6 $ git remote
> add kees-execshield git://kernel.ubuntu.com/kees/linux-2.6.git
> kyle@dreadnought ~/src/linux-2.6 $ git fetch kees-execshield
> kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection timed out
> fatal: unable to connect a socket (Connection timed out)
It worked for me.
That seems to be a large uncoordinated branch of many topics.
I guessed just from the log summary which commits are these ones:
git log -n3 6bf4df3
(I haven't really reviewed the changes.)
Kees, if you are looking for review, putting these on an isolated topic
branch for people to look at easily is probably a good idea.
Yes, sorry, I'm trying to make a collection of stuff to get ready for
upstream. I will switch to topic branches, good idea:
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads...
The "x86: brk away from exec rand area" patch represents a fix to a real
problem, though, so at the very least, please review that one. It's a
corner case only for PIE, but it does happen. There might be a more
elegant solution, but my patch seems to do the job.
> Yes, we've been saying for a while that the randomization
stuff needs to
> be gutted from exec-shield. There is still a lot of work left cleaning
> up exec-shield, all the hooks are pretty out of order.
It was vaguely on my list for ages to clean up execshield and slice it into
separate patches, but I just gave up on ever getting around to it. One
should probably ping Ingo, since (AFAIK) he did it all to begin with, back
in the beforetime, the long, long ago.
Well, to use the mainline ASLR, it would have to grow a little more
knowledge about memory ranges to distinguish where the CS line was.
The NX-emulation is "just" the CS-limit bits. (I've been trying to avoid
saying "exec-shield" since AFAIU, exec-shield as a project covered much
more than just NX-emu and ASLR.) But yeah, a good first step would be to
port the NX-emu to using mainline ASLR.
The exec-shield boot/sysctl parameter has never made a whole lot of
sense
to me. The "exec-shield" stuff is really about three separate things. If
they need knobs, it's always seemed to me they should have separate knobs.
Sounds like we all agree on this. :) Currently it sounds like 3 knobs:
nonexec: off, anything, hw-only
stack-exec: follow ELF markings, always nonexec
> I suspect all this is still too invasive in the generic code to
be
> palatable.
I haven't really looked at Kees' patches. But having considered before
factoring this stuff out to cleanish, the i386 "NX emulation" stuff seemed
like the first thing to do and not hard to do fairly cleanly. (Not that
this motivated me to bother doing it.)
Other objections are that it isn't "perfect" (i.e. the bss areas of loaded
libraries end up being executable). I personally don't mind this -- it's
better than nothing on hardware lacking the NX bit.
-Kees
--
Kees Cook
Ubuntu Security Team
1:43 p.m.
New subject: NX emulation
Yes, sorry, I'm trying to make a collection of stuff to get ready
for
upstream. I will switch to topic branches, good idea:
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads...
Not that I need to micromanage your branches for you, but that appears to
be just a cutoff of the same "everything" branch, not a separate topic
branch. A topic branch has only the commits about this topic relative to
the baseline, and the baseline should be some upstream tree state. i.e.,
"git log origin/master...kees/nx-emu" would show only these three patches.
The "x86: brk away from exec rand area" patch represents a
fix to a real
problem, though, so at the very least, please review that one. It's a
corner case only for PIE, but it does happen. There might be a more
elegant solution, but my patch seems to do the job.
Ok. I think this should be reviewed in the normal upstream way, with x86
maintainers CC'd, not just by us.
Well, to use the mainline ASLR, it would have to grow a little more
knowledge about memory ranges to distinguish where the CS line was.
The NX-emulation is "just" the CS-limit bits. (I've been trying to avoid
saying "exec-shield" since AFAIU, exec-shield as a project covered much
more than just NX-emu and ASLR.) But yeah, a good first step would be to
port the NX-emu to using mainline ASLR.
Right. I think all that stuff becomes much less confusing if we integrate
the separate pieces one at a time.
Sounds like we all agree on this. :) Currently it sounds like 3
knobs:
I actually don't care about the details of the knobs at all. I just think
that one knob called "exec-shield" is indefensibly random and unhelpful.
You need to work this out with Ingo and the other x86 maintainers. Other
Fedora kernel folks might have some input based on concrete concerns from
the past. Personally, I've never had a use for any of these knobs.
Other objections are that it isn't "perfect" (i.e. the
bss areas of loaded
libraries end up being executable). I personally don't mind this -- it's
better than nothing on hardware lacking the NX bit.
Agreed. It's also worthwhile to note that even on current hardware,
you don't get NX in 32-bit kernels unless you use CONFIG_X86_PAE.
Thanks,
Roland
1:52 p.m.
New subject: NX emulation
On Thu, May 27, 2010 at 11:43:47AM -0700, Roland McGrath wrote:
> The "x86: brk away from exec rand area" patch
represents a fix to a real
> problem, though, so at the very least, please review that one. It's a
> corner case only for PIE, but it does happen. There might be a more
> elegant solution, but my patch seems to do the job.
Ok. I think this should be reviewed in the normal upstream way, with x86
maintainers CC'd, not just by us.
agreed.
I actually don't care about the details of the knobs at all. I
just think
that one knob called "exec-shield" is indefensibly random and unhelpful.
You need to work this out with Ingo and the other x86 maintainers. Other
Fedora kernel folks might have some input based on concrete concerns from
the past. Personally, I've never had a use for any of these knobs.
The only time I recall them ever being useful was when execshield was in
development, and we'd get users to disable certain features to try and determine
which was failing. These days, I bet no-one ever touches the knobs.
Dave
4:45 p.m.
New subject: NX emulation
Hi,
On Thu, May 27, 2010 at 11:43:47AM -0700, Roland McGrath wrote:
> Yes, sorry, I'm trying to make a collection of stuff to get
ready for
> upstream. I will switch to topic branches, good idea:
> http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads...
Not that I need to micromanage your branches for you, but that appears to
be just a cutoff of the same "everything" branch, not a separate topic
branch. A topic branch has only the commits about this topic relative to
the baseline, and the baseline should be some upstream tree state. i.e.,
"git log origin/master...kees/nx-emu" would show only these three patches.
Hmm, that was my intention. I am new to using topic branches, so I'm
probably screwing something up here. AFAICT, I do only have the 3 nx-emu
patches on top of current linux-2.6's master. What do you see when you try
that git log? (Note that I just rebased again against linux-2.6 today.)
> The "x86: brk away from exec rand area" patch
represents a fix to a real
> problem, though, so at the very least, please review that one. It's a
> corner case only for PIE, but it does happen. There might be a more
> elegant solution, but my patch seems to do the job.
Ok. I think this should be reviewed in the normal upstream way, with x86
maintainers CC'd, not just by us.
Sorry I wasn't clear about this one; it's a fix for a problem introduced
by the exec-shield ASLR. Mainline does not suffer from this problem, which
is why I was hoping other folks here would want to look at it.
Well, mostly I wanted to collapse Ubuntu's 3 nx-emu patches into a single
patch, which is the same as what Fedora uses so we can all be on the same
page, hence the git branch, etc.
Right. I think all that stuff becomes much less confusing if we
integrate
the separate pieces one at a time.
I will add parameterizing the upstream ASLR to my TODO list, but I don't
think it'll get prioritized up to the top for a while. If anyone else
pokes at this, please let me know and we can compare notes.
> Other objections are that it isn't "perfect" (i.e.
the bss areas of loaded
> libraries end up being executable). I personally don't mind this -- it's
> better than nothing on hardware lacking the NX bit.
Agreed. It's also worthwhile to note that even on current hardware,
you don't get NX in 32-bit kernels unless you use CONFIG_X86_PAE.
Right, exactly. This was the reason I worked with HPA to clarify the
boot-time NX messages in upstream x86[1]. I wanted people to be able to see
their actual state of NX protection.
-Kees
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
--
Kees Cook
Ubuntu Security Team
4:55 p.m.
New subject: NX emulation
Hmm, that was my intention. I am new to using topic branches, so
I'm
probably screwing something up here. AFAICT, I do only have the 3 nx-emu
patches on top of current linux-2.6's master. What do you see when you try
that git log? (Note that I just rebased again against linux-2.6 today.)
The new one is right. Thanks.
Sorry I wasn't clear about this one; it's a fix for a problem
introduced
by the exec-shield ASLR. Mainline does not suffer from this problem, which
is why I was hoping other folks here would want to look at it.
I did gather that. I just meant that integrating it all piecemeal upstream
with all those folks contributing to the review is the best way to go about
the whole thing.
Well, mostly I wanted to collapse Ubuntu's 3 nx-emu patches into
a single
patch, which is the same as what Fedora uses so we can all be on the same
page, hence the git branch, etc.
Let's take a crack at upstream being the thing we're sharing between our
two kernel forks. ;-)
I will add parameterizing the upstream ASLR to my TODO list, but I
don't
think it'll get prioritized up to the top for a while. If anyone else
pokes at this, please let me know and we can compare notes.
Nobody around here has touched this any more than absolutely necessary in
years now. It's possible someone will be motivated, but I wouldn't bet on it.
Thanks,
Roland
5:48 p.m.
New subject: NX emulation
On Thu, May 27, 2010 at 02:55:59PM -0700, Roland McGrath wrote:
I did gather that. I just meant that integrating it all piecemeal
upstream
with all those folks contributing to the review is the best way to go about
the whole thing.
Right, yes. To that end, would you recommend a specific mailing list
other than lkml to start on for just the x86 folks, or is lkml really the
best bet for that?
> Well, mostly I wanted to collapse Ubuntu's 3 nx-emu patches
into a single
> patch, which is the same as what Fedora uses so we can all be on the same
> page, hence the git branch, etc.
Let's take a crack at upstream being the thing we're sharing between our
two kernel forks. ;-)
Yeah, I'm all for that; I just think upstreaming this is going to take
longer than either of our next release cycles. :)
Nobody around here has touched this any more than absolutely
necessary in
years now. It's possible someone will be motivated, but I wouldn't bet on it.
Okay. I'll see what I can get done.
Thanks!
-Kees
--
Kees Cook
Ubuntu Security Team
6:07 p.m.
New subject: NX emulation
Right, yes. To that end, would you recommend a specific mailing
list
other than lkml to start on for just the x86 folks, or is lkml really the
best bet for that?
Just the usual rules as per MAINTAINERS:
To: Thomas Gleixner <tglx(a)linutronix.de>
Ingo Molnar <mingo(a)redhat.com>
"H. Peter Anvin" <hpa(a)zytor.com>
CC: x86(a)kernel.org, lkml
CC: roland(a)redhat.com, kmcmartin(a)redhat.com
Yeah, I'm all for that; I just think upstreaming this is going to
take
longer than either of our next release cycles. :)
Yeah, well, it's taken us several cycles to get around to bothering to try.
At any rate, IMHO a series/branch of patches proposed upstream is the thing
we'll want to share. Even if it's not all (or any) merged upstream soon
(or ever), that process will yield cleaned-up and granular patches that are
better to maintain (and to share across distros) as well as being better to
merge if the NAKers relent.
Thanks,
Roland
6:29 p.m.
New subject: NX emulation
On Thu, May 27, 2010 at 04:07:39PM -0700, Roland McGrath wrote:
> Right, yes. To that end, would you recommend a specific mailing
list
> other than lkml to start on for just the x86 folks, or is lkml really the
> best bet for that?
Just the usual rules as per MAINTAINERS:
To: Thomas Gleixner <tglx(a)linutronix.de>
Ingo Molnar <mingo(a)redhat.com>
"H. Peter Anvin" <hpa(a)zytor.com>
CC: x86(a)kernel.org, lkml
CC: roland(a)redhat.com, kmcmartin(a)redhat.com
I always go look at vger's lists for x86 instead of MAINTAINERS. *head-desk*
Yeah, well, it's taken us several cycles to get around to
bothering to try.
At any rate, IMHO a series/branch of patches proposed upstream is the thing
we'll want to share. Even if it's not all (or any) merged upstream soon
(or ever), that process will yield cleaned-up and granular patches that are
better to maintain (and to share across distros) as well as being better to
merge if the NAKers relent.
Sounds good.
Thanks,
-Kees
--
Kees Cook
Ubuntu Security Team
5084
days inactive
5085
days old
kernel@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Dave Jones -
Kees Cook -
Kyle McMartin -
Roland McGrath