Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule

 

 

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


luto at MIT

Jun 5, 2011, 10:50 AM

Post #1 of 26 (2513 views)
Permalink
[PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule

CONFIG_UNSAFE_VSYSCALLS was added in the previous patch as a
temporary hack to avoid penalizing users who don't build glibc from
git.

Signed-off-by: Andy Lutomirski <luto [at] mit>
---
Documentation/feature-removal-schedule.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 1a9446b..94b4470 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -600,3 +600,12 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl.
Who: Laurent Pinchart <laurent.pinchart [at] ideasonboard>

----------------------------
+
+What: CONFIG_UNSAFE_VSYSCALLS (x86_64)
+When: When glibc 2.14 or newer is ubitquitous. Perhaps mid-2012.
+Why: Having user-executable code at a fixed address is a security problem.
+ Turning off CONFIG_UNSAFE_VSYSCALLS mostly removes the risk but will
+ make the time() function slower on glibc versions 2.13 and below.
+Who: Andy Lutomirski <luto [at] mit>
+
+----------------------------
--
1.7.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Jun 6, 2011, 1:46 AM

Post #2 of 26 (2454 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On Mon, Jun 6, 2011 at 2:50 AM, Andy Lutomirski <luto [at] mit> wrote:
> CONFIG_UNSAFE_VSYSCALLS was added in the previous patch as a
> temporary hack to avoid penalizing users who don't build glibc from
> git.

I really hate that name.

Do you have *any* reason to call this "unsafe"?

Seriously. The whole patch series just seems annoying.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andi at firstfloor

Jun 6, 2011, 2:31 AM

Post #3 of 26 (2453 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On Mon, Jun 06, 2011 at 05:46:41PM +0900, Linus Torvalds wrote:
> On Mon, Jun 6, 2011 at 2:50 AM, Andy Lutomirski <luto [at] mit> wrote:
> > CONFIG_UNSAFE_VSYSCALLS was added in the previous patch as a
> > temporary hack to avoid penalizing users who don't build glibc from
> > git.
>
> I really hate that name.
>
> Do you have *any* reason to call this "unsafe"?
>
> Seriously. The whole patch series just seems annoying.

and assumes everyone is using glibc which is just wrong.

-Andi

--
ak [at] linux -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 3:39 AM

Post #4 of 26 (2456 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 11:31, Andi Kleen wrote:

> On Mon, Jun 06, 2011 at 05:46:41PM +0900, Linus Torvalds wrote:
> > On Mon, Jun 6, 2011 at 2:50 AM, Andy Lutomirski <luto [at] mit> wrote:
> > > CONFIG_UNSAFE_VSYSCALLS was added in the previous patch as a
> > > temporary hack to avoid penalizing users who don't build glibc from
> > > git.

[didn't get your mail directly (yet?), so i'm replying here]

> > I really hate that name.
> >
> > Do you have *any* reason to call this "unsafe"?

any userland executable code at a universally (read: across any and all 2.6+ linux
boxes) fixed address is not secure (no really, it's worse, it's simply insane design,
there's a reason the vdso got randomized eventually), it's the prime vehicle used by
both reliable userland and kernel exploits who need to execute syscalls and/or pop
the stack until something useful is reached, etc. not to mention the generic snippets
of both code and data (marketing word: ROP) that one may find in there.

> > Seriously. The whole patch series just seems annoying.

what is annoying is your covering up of security fixes on grounds that you don't want
to help script kiddies (a bullshit argument as it were) but at the same time question
proactive security measures (one can debate the implementation, see my other mail) that
would *actually* prevent the same kiddies from writing textbook exploits.

but hey, spouting security to journalists works so much better for marketing, doesn't it.

> and assumes everyone is using glibc which is just wrong.

the libc is irrelevant, they can all be fixed up to use the vdso entry points if they
haven't been doing it already. already deployed systems will simply continue to use
their flawed kernel and libc, they're not affected.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Jun 6, 2011, 6:56 AM

Post #5 of 26 (2451 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On Mon, Jun 6, 2011 at 7:39 PM, <pageexec [at] freemail> wrote:
>
> what is annoying is your covering up of security fixes on grounds that you don't want
> to help script kiddies (a bullshit argument as it were) but at the same time question
> proactive security measures (one can debate the implementation, see my other mail) that
> would *actually* prevent the same kiddies from writing textbook exploits.

Shut up unless you have any real arguments. I know you have your
hangups, and I just don't care.

Calling the old vdso "UNSAFE" as a config option is just plain stupid.
t's a politicized name, with no good reason except for your political
agenda. And when I call it out as such, you just spout the same tired
old security nonsense.

I'm happy with perhaps moving away from the fixed-address vdso, but
that does not excuse bad naming and non-descriptive crap like the
feature-removal thing, and all the insanity going on in the thread. If
the config option is about removing the legacy vdso, then CALL IT
THAT, instead of spouting idiotic and irrelevant nonsense.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 7:44 AM

Post #6 of 26 (2451 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> > > Seriously. The whole patch series just seems annoying.
>
> what is annoying is your covering up of security fixes on grounds
> that you don't want to help script kiddies (a bullshit argument as
> it were) but at the same time question proactive security measures
> (one can debate the implementation, see my other mail) that would
> *actually* prevent the same kiddies from writing textbook exploits.

You are mixing up several issues here, and rather unfairly so.

Firstly, see my other mail, there's an imperfect balance to be
found between statistical 'proactive' measures and the incentives
that remove the *real* bugs. You have not replied to that mail of
mine so can i assume that you concur and accept my points? If yes
then why are you still arguing the same thing?

Secondly, *once* a real security bug has been found the correct
action is different from the considerations of proactive measures.
How can you possibly draw equivalence between disclosure policies
and the handling of statistical security measures?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 7:52 AM

Post #7 of 26 (2456 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> On 6 Jun 2011 at 11:31, Andi Kleen wrote:
>
> > and assumes everyone is using glibc which is just wrong.
>
> the libc is irrelevant, they can all be fixed up to use the vdso
> entry points if they haven't been doing it already. already
> deployed systems will simply continue to use their flawed kernel
> and libc, they're not affected.

Correct, the libc is irrelevant here really - a distro will obviously
enable or disable CONFIG_COMPAT_VSYSCALL=y based on the type and
version of libc it is using.

This has been pointed out to Andi before.

Unfortunately Andi has been spouting nonsense in this thread without
replying to mails that challenge his points, such as:

http://marc.info/?l=linux-kernel&m=130686838202409
and: http://marc.info/?l=linux-kernel&m=130686827002311
and: http://marc.info/?l=linux-kernel&m=130687014804697

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 8:01 AM

Post #8 of 26 (2455 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 16:44, Ingo Molnar wrote:

> You have not replied to that mail of
> mine so can i assume that you concur and accept my points?

my bandwidth/quota for replying to idiocy is limited (and is
close to exhaustion for today ;), be patient, i'll reply to
you as well.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 8:15 AM

Post #9 of 26 (2455 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> On 6 Jun 2011 at 16:44, Ingo Molnar wrote:
>
> > You have not replied to that mail of
> > mine so can i assume that you concur and accept my points?
>
> my bandwidth/quota for replying to idiocy is limited (and is
> close to exhaustion for today ;), be patient, i'll reply to
> you as well.

You might want to save the insults to after we are done with the
discussion.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 8:29 AM

Post #10 of 26 (2456 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 17:15, Ingo Molnar wrote:

> You might want to save the insults to after we are done with the
> discussion.

haha, Ingo, seriously, you wrote the above 20 minutes after this one?

> Unfortunately Andi has been spouting nonsense in this thread without
> replying to mails that challenge his points, such as:

tell you what Ingo, heed your own advice. better, you can even keep it
to yourself. i do whatever i want, including what you reserve for
seemingly yourself only.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 9:54 AM

Post #11 of 26 (2453 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> On 6 Jun 2011 at 17:15, Ingo Molnar wrote:

> > pageexec [at] freemail <pageexec [at] freemail> wrote:
> >
> > > my bandwidth/quota for replying to idiocy is limited (and is
> > > close to exhaustion for today ;), be patient, i'll reply to
> > > you as well.
> >
> > You might want to save the insults to after we are done with the
> > discussion.
>
> haha, Ingo, seriously, you wrote the above 20 minutes after this
> one?
>
> > Unfortunately Andi has been spouting nonsense in this thread
> > without replying to mails that challenge his points, such as:
>
> tell you what Ingo, heed your own advice. better, you can even keep
> it to yourself. i do whatever i want, including what you reserve
> for seemingly yourself only.

The difference is that:

- You wrote an insult without waiting for the discussion to come to
a conclusion. I think you are wrong and i am willing to argue it.

- Andi first tried to injected fear, uncertainty and doubt into the
discussion a week ago, then ignored 3 mails from 3 separate people
and thus when he repeated his nonsense today (while still ignoring
the feedback he got) i sure can call his opinion 'nonsense'.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 11:46 AM

Post #12 of 26 (2449 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 22:56, Linus Torvalds wrote:

> On Mon, Jun 6, 2011 at 7:39 PM, <pageexec [at] freemail> wrote:
> >
> > what is annoying is your covering up of security fixes on grounds that you don't want
> > to help script kiddies (a bullshit argument as it were) but at the same time question
> > proactive security measures (one can debate the implementation, see my other mail) that
> > would *actually* prevent the same kiddies from writing textbook exploits.
>
> Shut up unless you have any real arguments. I know you have your
> hangups, and I just don't care.

i have real arguments, i told them to you but i have yet to see anything
expect silly name calling from you. is that the best you can do? seriously?

> Calling the old vdso "UNSAFE" as a config option is just plain stupid.
> t's a politicized name, with no good reason except for your political
> agenda. And when I call it out as such, you just spout the same tired
> old security nonsense.

i didn't choose this name, Andy did but i happen to agree with it. whether
you like it or not is frankly and quite obviously irrelevant to me ;). as
for political agenda, tell me more, i'd like to know what it is. exposing
your lies to the public about doing full disclosure but still covering up
the security fixes is not politics, it's called honesty. not yours, mine.
maybe that's what bothers you.

> I'm happy with perhaps moving away from the fixed-address vdso,

it's not about the vdso that has been mmap'ed and randomized for quite some
time now. it's about the amd64 specific vsyscall page.

> but that does not excuse bad naming and non-descriptive crap like the
> feature-removal thing, and all the insanity going on in the thread. If
> the config option is about removing the legacy vdso, then CALL IT
> THAT, instead of spouting idiotic and irrelevant nonsense.

noone wants to remove the legacy vdso as one can simply configure out that
option already. it's about introducing a similar option for vsyscall.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 11:59 AM

Post #13 of 26 (2452 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 16:44, Ingo Molnar wrote:
> * pageexec [at] freemail <pageexec [at] freemail> wrote:
>
> > > > Seriously. The whole patch series just seems annoying.
> >
> > what is annoying is your covering up of security fixes on grounds
> > that you don't want to help script kiddies (a bullshit argument as
> > it were) but at the same time question proactive security measures
> > (one can debate the implementation, see my other mail) that would
> > *actually* prevent the same kiddies from writing textbook exploits.
>
> You are mixing up several issues here, and rather unfairly so.

but it's very simple logic Ingo. it goes like 'I am not willing to
do A because it would help script kiddies but I'd rather do B that
would help script kiddies'. with A = 'disclose security bugs' and
B = 'keep the last roadblock that prevents full ASLR'.

if someone's that worried about script kiddies as Linus claims to be
(which i always called a BS argument, but let's accept here), he can't
possibly argue for keeping the vsyscall page at a fixed address around,
simple as that.

and it is for security, no other reason, else you'd have to accept a patch
that maps the vdso at a fixed address again or come up with some very
convincing arguments why the vdso must stay randomized but the vsyscall
page is fine at a fixed address (i guess neither is forthcoming but you
guys can act in surprising ways, so i'm not placing any bets ;).

> Firstly, see my other mail, there's an imperfect balance to be
> found between statistical 'proactive' measures and the incentives
> that remove the *real* bugs.

i hope i replied to this already now to your satisfaction else feel free
to elaboarte.

> Secondly, *once* a real security bug has been found the correct
> action is different from the considerations of proactive measures.

as i said already, you're mixing up fixing bugs and fighting exploit
techniques. apples vs. oranges.

> How can you possibly draw equivalence between disclosure policies
> and the handling of statistical security measures?

see the simple logic above.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 12:25 PM

Post #14 of 26 (2449 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> [...] it goes like 'I am not willing to do A because it would help
> script kiddies but I'd rather do B that would help script kiddies'.
> with A = 'disclose security bugs' and B = 'keep the last roadblock
> that prevents full ASLR'.

No, that's wrong, the logic goes like this:

if i do A then it has X1 advantages and Y1 disadvantages.
if i do B then it has X2 advantages and Y2 disadvantages.

The Y1 and Y2 set of disadvantages can both include "making it easier
for script kiddies" but the sets of advantages and disadvantages can
also include MANY OTHER considerations, making the decision unique in
each case.

To translate it to this specific case (extremely simplifed, so please
don't nit-pick that my descriptions of advantages and disadvantages
are not precise nor complete):

A) "i put a zero day exploit and a CVE code into a changelog"

Advantages: - it describes the problem more fully

Disadvantages: - it makes it easier for people (including script kiddies) do harm faster
- creates a false, misleading category for "security bugs"

B) "i obfuscate the vsyscall page"

Advantages: - it makes it statistically harder for people (including script kiddies) to do harm

Disadvantages: - it reduces the incentive to fix *real* security bugs
- complicates the code

Do you see how A) and B) are not equivalent at all? Different cases,
different attributes, different probabilities and different
considerations.

> but it's very simple logic Ingo.

Please drop the condescending tone, i think it should be clear to you
by now that i have a good basis to disagree with you.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Jun 6, 2011, 1:40 PM

Post #15 of 26 (2450 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On Tue, Jun 7, 2011 at 3:46 AM, <pageexec [at] freemail> wrote:
>
>> I'm happy with perhaps moving away from the fixed-address vdso,
>
> it's not about the vdso that has been mmap'ed and randomized for quite some
> time now. it's about the amd64 specific vsyscall page.

Duh. What do you think that thing is? It's a special fixed-address
vdso. Stop the whole jumping from issue to issue and making up random
irrelevant arguments. First it was you jumping up and down about
"covering up security issues", now you start instead complaining about
some random word choice. Stop it.

What I complain about in the patch series was (specifically) that I
think the naming sucks and (non-specifically) that the whole series is
annoying.

The config name is misleading and pointlessly scary - the whole thing
is not in itself "unsafe", so calling it that is just wrong. If we
want to make it a legacy option that you can turn off (which sounds
sane in itself), then name it that way. But if so, the name and
explanation should be that it's about legacy stuff and that you can
only do so once it's no longer used. Not "UNSAFE", which it isn't.

We *definitely* don't want to name it in a way that makes some random
person just turn it off because it's scary, since the random person
*shouldn't* turn it off today. Comprende?

And the annoying part about the whole patch series is how the whole
re-sending has gone on forever. Just pick some approach, do it, and
don't even bother making it a config option for now. If we can replace
the vsyscall page with a page fault or int3 or whatever, and it's only
used for the 'time()' system call, just do it.

The series is now extended with the cleanup patches so the end result
looks reasonable, but why have the whole "first implement it, then
clean it up" and sending it as a whole series. That's annoying. Just
send the cleaned-up end result to begin with.

Linus

PS. The reason you don't see direct replies seems to be this from gmail:

----- The following addresses had permanent fatal errors -----
<pageexec [at] freemail>
(reason: 553 sorry, that domain isn't in my list of allowed
rcpthosts (#5.7.1))

which is probably because some spamming or other bad behavior from
within the same domain.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


luto at mit

Jun 6, 2011, 1:51 PM

Post #16 of 26 (2455 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On Mon, Jun 6, 2011 at 4:40 PM, Linus Torvalds
<torvalds [at] linux-foundation> wrote:

> We *definitely* don't want to name it in a way that makes some random
> person just turn it off because it's scary, since the random person
> *shouldn't* turn it off today. Comprende?

Yes, and fixed in the cleaned up version.

>
> And the annoying part about the whole patch series is how the whole
> re-sending has gone on forever.

If I have the patch-resending protocol wrong, please enlighten me.
I'm not sure how to make future work less annoying.

> Just pick some approach, do it, and
> don't even bother making it a config option for now. If we can replace
> the vsyscall page with a page fault or int3 or whatever, and it's only
> used for the 'time()' system call, just do it.

Really?

I won't personally complain about the 200+ ns hit, but I'm sure
someone will cc: me on a regression report if there's no option.

>
> The series is now extended with the cleanup patches so the end result
> looks reasonable, but why have the whole "first implement it, then
> clean it up" and sending it as a whole series. That's annoying. Just
> send the cleaned-up end result to begin with.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 2:45 PM

Post #17 of 26 (2447 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* Linus Torvalds <torvalds [at] linux-foundation> wrote:

> We *definitely* don't want to name it in a way that makes some
> random person just turn it off because it's scary, since the random
> person *shouldn't* turn it off today. Comprende?

Agreed, and that's fixed now.

> And the annoying part about the whole patch series is how the whole
> re-sending has gone on forever. Just pick some approach, do it, and
> don't even bother making it a config option for now. If we can
> replace the vsyscall page with a page fault or int3 or whatever,
> and it's only used for the 'time()' system call, just do it.

Ok, we can certainly remove CONFIG_LEGACY_VTIME - that would further
simplify things!

I was unsure how big of a problem the time() slowdown was and the
config option was easy enough to provide. My preference would be to
just remove the config option and simplify the code - complexity is
the #1 enemy of security.

> The series is now extended with the cleanup patches so the end
> result looks reasonable, but why have the whole "first implement
> it, then clean it up" and sending it as a whole series. That's
> annoying. Just send the cleaned-up end result to begin with.

Do you think x86/vdso is worth rebasing at this stage? Right now it
has:

feba7e97df8c: x86-64: Rename COMPAT_VSYSCALLS to LEGACY_VTIME and clarify documentation
7dc0452808b7: x86-64: Clean up vsyscall emulation and remove fixed-address ret
8d6316596441: x86-64: Fix outdated comments in vsyscall_64.c
1593843e2ada: x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS
764611c8dfb5: x86-64, vdso, seccomp: Fix !CONFIG_SECCOMP build
38172403a978: x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
d55ed1d30b82: x86-64: Emulate legacy vsyscalls
5dfcea629a08: x86-64: Fill unused parts of the vsyscall page with 0xcc
bb5fe2f78ead: x86-64: Remove vsyscall number 3 (venosys)
d319bb79afa4: x86-64: Map the HPET NX
0d7b8547fb67: x86-64: Remove kernel.vsyscall64 sysctl
9fd67b4ed071: x86-64: Give vvars their own page
8b4777a4b50c: x86-64: Document some of entry_64.S
6879eb2deed7: x86-64: Fix alignment of jiffies variable

it's reasonably tested by now. We'd keep about 80% of the commits
after the rebase.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 2:48 PM

Post #18 of 26 (2447 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* Ingo Molnar <mingo [at] elte> wrote:

> I was unsure how big of a problem the time() slowdown was and the
> config option was easy enough to provide. My preference would be to
> just remove the config option and simplify the code - complexity is
> the #1 enemy of security.

The patch below is what the config removal brings us.

Thanks,

Ingo

--
Documentation/feature-removal-schedule.txt | 13 -------------
arch/x86/Kconfig | 23 -----------------------
arch/x86/kernel/vsyscall_64.c | 26 --------------------------
arch/x86/kernel/vsyscall_emu_64.S | 2 --
4 files changed, 0 insertions(+), 64 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 7a7446b..1a9446b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -600,16 +600,3 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl.
Who: Laurent Pinchart <laurent.pinchart [at] ideasonboard>

----------------------------
-
-What: CONFIG_LEGACY_VTIME (x86_64)
-When: When glibc 2.14 or newer is ubiquitous. Perhaps 2013.
-Why: Having user-executable syscall invoking code at a fixed addresses makes
- it easier for attackers to exploit security holes. Turning off
- CONFIG_LEGACY_VTIME reduces the risk without breaking binary
- compatibility but will make the time() function slightly slower on
- glibc versions 2.13 and below.
-
- We may flip the default setting to N before 2013.
-Who: Andy Lutomirski <luto [at] mit>
-
-----------------------------
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6746d35..da34972 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1646,29 +1646,6 @@ config COMPAT_VDSO

If unsure, say Y.

-config LEGACY_VTIME
- def_bool y
- prompt "Fast legacy sys_time() vsyscall"
- depends on X86_64
- ---help---
- Glibc 2.13 and older, statically linked binaries, and a few
- other things use a legacy ABI to implement time().
-
- If you say N here, the kernel will emulate that interface in
- order to make certain types of userspace bugs more difficult
- to exploit. This will cause some legacy software to run
- slightly more slowly.
-
- If you say Y here, then the kernel will provide native code to
- allow legacy programs to run without any performance impact.
- This could make it easier to exploit certain types of
- userspace bugs.
-
- If unsure, say Y.
-
- NOTE: disabling this option will not break any ABI; the kernel
- will be fully compatible with all binaries either way.
-
config CMDLINE_BOOL
bool "Built-in kernel command line"
---help---
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index f56644e..41f6a98 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -102,30 +102,6 @@ static void warn_bad_vsyscall(const char *level, struct pt_regs *regs,
regs->ip - 2, regs->sp, regs->ax, regs->si, regs->di);
}

-#ifdef CONFIG_LEGACY_VTIME
-
-/* This will break when the xtime seconds get inaccurate, but that is
- * unlikely */
-time_t __attribute__ ((unused, __section__(".vsyscall_1"))) notrace
-vtime(time_t *t)
-{
- unsigned seq;
- time_t result;
-
- do {
- seq = read_seqbegin(&VVAR(vsyscall_gtod_data).lock);
-
- result = VVAR(vsyscall_gtod_data).wall_time_sec;
-
- } while (read_seqretry(&VVAR(vsyscall_gtod_data).lock, seq));
-
- if (t)
- *t = result;
- return result;
-}
-
-#endif /* CONFIG_LEGACY_VTIME */
-
void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
{
static DEFINE_RATELIMIT_STATE(rs, 3600 * HZ, 3);
@@ -169,12 +145,10 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
(struct timezone __user *)regs->si);
break;

-#ifndef CONFIG_LEGACY_VTIME
case 1:
vsyscall_name = "time";
ret = sys_time((time_t __user *)regs->di);
break;
-#endif

case 2:
vsyscall_name = "getcpu";
diff --git a/arch/x86/kernel/vsyscall_emu_64.S b/arch/x86/kernel/vsyscall_emu_64.S
index b192283..bc10dba 100644
--- a/arch/x86/kernel/vsyscall_emu_64.S
+++ b/arch/x86/kernel/vsyscall_emu_64.S
@@ -14,12 +14,10 @@ ENTRY(vsyscall_0)
int $VSYSCALL_EMU_VECTOR
END(vsyscall_0)

-#ifndef CONFIG_LEGACY_VTIME
.section .vsyscall_1, "a"
ENTRY(vsyscall_1)
int $VSYSCALL_EMU_VECTOR
END(vsyscall_1)
-#endif

.section .vsyscall_2, "a"
ENTRY(vsyscall_2)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 2:53 PM

Post #19 of 26 (2450 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 7 Jun 2011 at 5:40, Linus Torvalds wrote:

> On Tue, Jun 7, 2011 at 3:46 AM, <pageexec [at] freemail> wrote:
> >
> >> I'm happy with perhaps moving away from the fixed-address vdso,
> >
> > it's not about the vdso that has been mmap'ed and randomized for quite some
> > time now. it's about the amd64 specific vsyscall page.
>
> Duh. What do you think that thing is? It's a special fixed-address
> vdso.

that we call the vsyscall page and not some random vdso thing, they're quite
different, that's why there's this whole patch series, duh.

> What I complain about in the patch series was (specifically) that I
> think the naming sucks and (non-specifically) that the whole series is
> annoying.
>
> The config name is misleading and pointlessly scary - the whole thing
> is not in itself "unsafe", so calling it that is just wrong.

if it's safe to have the vsyscall page at a fixed address, then you surely
wouldn't object to have its replacement at a fixed address as well, would
you? yes/no? (if it's a 'yes' then you'd better have some non-security
arguments too ;)

> We *definitely* don't want to name it in a way that makes some random
> person just turn it off because it's scary, since the random person
> *shouldn't* turn it off today. Comprende?

actually you confused yourself and got it backwards. we want everyone sane
who cares an iota about security to turn off the legacy/fixed address vsyscall
as soon as possible else it's a pointless exercise. capito?

> If we can replace the vsyscall page with a page fault or int3 or
> whatever, and it's only used for the 'time()' system call, just do it.

i agree fully, there's no real reason for a config option imho, i never
had one in PaX and noone ever complained let alone noticed it (except
perhaps for failed exploit attempts but that's by design).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 6, 2011, 2:54 PM

Post #20 of 26 (2449 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* Andrew Lutomirski <luto [at] mit> wrote:

> > don't even bother making it a config option for now. If we can
> > replace the vsyscall page with a page fault or int3 or whatever,
> > and it's only used for the 'time()' system call, just do it.
>
> Really?
>
> I won't personally complain about the 200+ ns hit, but I'm sure
> someone will cc: me on a regression report if there's no option.

Well, for 0.2 usecs to show up one would have to do like a million of
them per second.

Why an application would want to query the *same value* from the
kernel a million times per second is beyond me. vgettimeofday()?
Sure. But vtime()?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 6, 2011, 5:34 PM

Post #21 of 26 (2449 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 6 Jun 2011 at 21:25, Ingo Molnar wrote:

> * pageexec [at] freemail <pageexec [at] freemail> wrote:
>
> > [...] it goes like 'I am not willing to do A because it would help
> > script kiddies but I'd rather do B that would help script kiddies'.
> > with A = 'disclose security bugs' and B = 'keep the last roadblock
> > that prevents full ASLR'.
>
> No, that's wrong, the logic goes like this:
>
> if i do A then it has X1 advantages and Y1 disadvantages.
> if i do B then it has X2 advantages and Y2 disadvantages.
>
> The Y1 and Y2 set of disadvantages can both include "making it easier
> for script kiddies" but the sets of advantages and disadvantages can
> also include MANY OTHER considerations, making the decision unique in
> each case.

sure, i was only reflecting on what Linus himself kept insisting on in
the past.

> To translate it to this specific case (extremely simplifed, so please
> don't nit-pick that my descriptions of advantages and disadvantages
> are not precise nor complete):

i don't even need to get there, you already failed right in the very
first sentence, very impressive. no. 'not precise' is an understatement.

> A) "i put a zero day exploit and a CVE code into a changelog"
>
> Advantages: - it describes the problem more fully
>
> Disadvantages: - it makes it easier for people (including script kiddies) do harm faster
> - creates a false, misleading category for "security bugs"
>

you try to set things up to serve your argument but it's not the things
we've ever talked about (IOW, this is a strawman).

in particular, i've never ever requested exploits in commit logs (and i
don't remember anyone else who has, do you?). why do you keep thinking in
only extremes? is it so impossible to simply state a CVE and the generic
bug class (CWE) that the commit fixes? what Linus has insisted on is 'no
greppable words', that's diametrically opposite to 'full disclosure' that
you guys say you're supposedly doing.

so if you omit the exploits that noone really requested (and i don't even
know why they'd be useful in a commit) then suddenly the script kiddies
are no longer helped.

and you have yet to explain what is false and misleading about the security
bug category. you used these words yourself several times today, how do you
explain that? why does the CVE exist? why does bugtraq exist? are all those
people discussing 'false and misleading' things? why does your employer
release security errata? etc, etc.

> B) "i obfuscate the vsyscall page"
>
> Advantages: - it makes it statistically harder for people (including script kiddies) to do harm
>
> Disadvantages: - it reduces the incentive to fix *real* security bugs

as i pointed out in an earlier mail, this supposed disadvantage doesn't
exist so come up with something better, preferably real.

> - complicates the code

removing code simplifies things. next try? ;)

> Do you see how A) and B) are not equivalent at all? Different cases,
> different attributes, different probabilities and different
> considerations.

i only see a strawman that you thought would help your cause but since
it's just that, a strawman, something you made up for the sake of argument,
i don't think there's much more to see about it.

> > but it's very simple logic Ingo.
>
> Please drop the condescending tone, i think it should be clear to you
> by now that i have a good basis to disagree with you.

i'm a firm believer of instant karma, it seems to work on people like yourself
or Linus really well. in somewhat profane but simple english: if you behave as
an asshole i will treat you as one, if you believe i treated you as an asshole
it's because i think you acted as one, and if you don't understand why then you're
welcome to 1. look into yourself and figure it out yourself, 2. ask me. what is
not going to get you anywhere is if you talk to me and others from the high horse,
you must be a lot better than your current self for anyone to tolerate it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 7, 2011, 2:51 AM

Post #22 of 26 (2450 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> On 6 Jun 2011 at 21:25, Ingo Molnar wrote:
>
> > * pageexec [at] freemail <pageexec [at] freemail> wrote:
> >
> > > [...] it goes like 'I am not willing to do A because it would
> > > help script kiddies but I'd rather do B that would help script
> > > kiddies'. with A = 'disclose security bugs' and B = 'keep the
> > > last roadblock that prevents full ASLR'.
> >
> > No, that's wrong, the logic goes like this:
> >
> > if i do A then it has X1 advantages and Y1 disadvantages.
> > if i do B then it has X2 advantages and Y2 disadvantages.
> >
> > The Y1 and Y2 set of disadvantages can both include "making it
> > easier for script kiddies" but the sets of advantages and
> > disadvantages can also include MANY OTHER considerations, making
> > the decision unique in each case.
>
> Sure, i was only reflecting on what Linus himself kept insisting on
> in the past.

From what i've seen his say in past discussions he clearly applied
the common-sense logic i outlined above, not the twisted logic you
provided.

You paraphrased Linus in such a way:

" it goes like 'I am not willing to do A because it would
help script kiddies but I'd rather do B that would help script
kiddies'. with A = 'disclose security bugs' and B = 'keep the
last roadblock that prevents full ASLR'.
"

IMO your are blatantly misrepresenting Linus's opinion.

> > To translate it to this specific case (extremely simplifed, so
> > please don't nit-pick that my descriptions of advantages and
> > disadvantages are not precise nor complete):
>
> i don't even need to get there, you already failed right in the
> very first sentence, very impressive. no. 'not precise' is an
> understatement.
>
> > A) "i put a zero day exploit and a CVE code into a changelog"
> >
> > Advantages: - it describes the problem more fully
> >
> > Disadvantages: - it makes it easier for people (including script kiddies) do harm faster
> > - creates a false, misleading category for "security bugs"
> >
>
> you try to set things up to serve your argument but it's not the things
> we've ever talked about (IOW, this is a strawman).
>
> in particular, i've never ever requested exploits in commit logs
> (and i don't remember anyone else who has, do you?). why do you
> keep thinking in only extremes? is it so impossible to simply state
> a CVE and the generic bug class (CWE) that the commit fixes? what
> Linus has insisted on is 'no greppable words', that's diametrically
> opposite to 'full disclosure' that you guys say you're supposedly
> doing.

You contradict yourself in that paragraph (see below).

I simply disagree with putting easily greppable words like 'CVE' into
the changelogs of bugs, due to what i already said above:

Disadvantages: - it makes it easier for people (including script kiddies) do harm faster
- creates a false, misleading category for "security bugs"

> so if you omit the exploits that noone really requested (and i
> don't even know why they'd be useful in a commit) then suddenly the
> script kiddies are no longer helped.
>
> and you have yet to explain what is false and misleading about the
> security bug category. you used these words yourself several times
> today, how do you explain that? why does the CVE exist? why does
> bugtraq exist? are all those people discussing 'false and
> misleading' things? why does your employer release security errata?
> etc, etc.

My arguments against putting easily greppable CVE numbers into
changelogs are very simple:

Firstly:

- in many cases it is equivalent to providing a zero-day exploit
in the changelog, to any reasonably skilled exploit writer

And you yourself said that you don't want to put zero-day exploits
into changelogs, so why are you even arguing?

Secondly:

- it's misleading because IMO CVE tagged bugs do not cover all
bugs that matter, they are self-selected bugs often highlighted
by attention-seeking participants of the security circus.
The primary driving force in that industry is attention seeking,
*not* the maximization of security - and often they act in direct
conflict to better security ...

Maximizing security is hard: whether a bug has security implications
is highly usecase and bug dependent, and the true security impact of
bugs is not discovered in the majority of cases. I estimate that in
*ANY* OS there's probably at least 10 times more bugs with some
potential security impact than ever get a CVE number...

So putting CVEs into the changelog is harmful, pointless, misleading
and would just create a fake "scare users" and "gain attention"
industry (coupled with a "delay bug fixes for a long time" aspect, if
paid well enough) that operates based on issuing CVEs and 'solving'
them - which disincentivises the *real* bugfixes and the
non-self-selected bug fixers.

I'd like to strengthen the natural 'bug fixing' industry, not the
security circus industry.

[. But this is a higher level meta argument based on opinion so it's
probably rather pointless to argue it with you as such arguments
need a certain level of mutual trust to discuss efficiently. ]

> > > but it's very simple logic Ingo.
> >
> > Please drop the condescending tone, i think it should be clear to
> > you by now that i have a good basis to disagree with you.
>
> i'm a firm believer of instant karma, it seems to work on people
> like yourself or Linus really well. in somewhat profane but simple
> english: if you behave as an asshole i will treat you as one, if
> you believe i treated you as an asshole it's because i think you
> acted as one, and if you don't understand why then you're welcome
> to 1. look into yourself and figure it out yourself, 2. ask me.
> what is not going to get you anywhere is if you talk to me and
> others from the high horse, you must be a lot better than your
> current self for anyone to tolerate it.

I simply disagreed with you and argued with you without insulting you
in such a tone.

Does disagreeing with you make me an 'asshole'?

But the thing is, i probably shouldnt bother arguing with you since i
have trouble convincing you about very obvious things like the simple
fact that putting more instructions into the page fault path ...
slows it down, why should i bother arguing with you here?

You are not willing to listen and amazingly, in all these recent
discussions you've never *ever* conceded a single point - even in
cases where you were proven wrong beyond recognition!

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 7, 2011, 4:24 PM

Post #23 of 26 (2445 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 7 Jun 2011 at 11:51, Ingo Molnar wrote:

> > Sure, i was only reflecting on what Linus himself kept insisting on
> > in the past.
>
> From what i've seen his say in past discussions he clearly applied
> the common-sense logic i outlined above, not the twisted logic you
> provided.

you must have been reading a different discussion over the years than
what i have. he's never once provided anything remotely related to
'common sense'. every time i pointed out the holes in his logic, he
just shut up. not exactly the way to have a meaningful conversation
but let's see if you fare any better ;).

> You paraphrased Linus in such a way:
>
> " it goes like 'I am not willing to do A because it would
> help script kiddies but I'd rather do B that would help script
> kiddies'. with A = 'disclose security bugs' and B = 'keep the
> last roadblock that prevents full ASLR'.
> "
>
> IMO your are blatantly misrepresenting Linus's opinion.

i think the man can defend himself if he really feels that way, but let
me show you the origin of this idiotic script kiddie defense of his:
http://lkml.org/lkml/2008/7/15/293 notice how he didn't even know the
difference between publishing exploits (something script kiddies could
try) vs. describing the security aspects of the fix. but as we can see
below, you're not that much better either, so let's continue there.

> > in particular, i've never ever requested exploits in commit logs
> > (and i don't remember anyone else who has, do you?). why do you
> > keep thinking in only extremes? is it so impossible to simply state
> > a CVE and the generic bug class (CWE) that the commit fixes? what
> > Linus has insisted on is 'no greppable words', that's diametrically
> > opposite to 'full disclosure' that you guys say you're supposedly
> > doing.
>
> You contradict yourself in that paragraph (see below).

you wish i did ;).

> I simply disagree with putting easily greppable words like 'CVE' into
> the changelogs of bugs, due to what i already said above:

i note that most of the world does this already, so you'd better come up with
an excuse that applies only to you but not the other projects/companies/etc.
i also note that you provided no explanation for your employer's behaviour
(http://www.redhat.com/security/data/cve/). do you disagree with them?

> Disadvantages: - it makes it easier for people (including script kiddies) do harm faster

what evidence do you have that people are doing harm faster when you put
CVEs/etc into commits? and what do scipt kiddies have to do with this again?
do you know what that term even means?

> - creates a false, misleading category for "security bugs"

let's see this one below.

> My arguments against putting easily greppable CVE numbers into
> changelogs are very simple:
>
> Firstly:
>
> - in many cases it is equivalent to providing a zero-day exploit
> in the changelog, to any reasonably skilled exploit writer

bullshit again. you don't even know what the term '0-day exploit' means.
(do you understand that if knowing the CVE leads people to exploits then
they can just track the CVEs instead and forget about kernel commits?).

but that aside, you're assuming the existence of a person who can read
the code in a commit and create an exploit out of it (when the CVE/etc
are included) but at the same time when he reads the same commit, he's
suddenly unable to create an exploit out of it (when the CVE/etc are not
included). are you for real Ingo? do you know this thing called 'logic'?
do you understand that your 'argument' rests on an impossible situation,
the existence of a person with mutually exclusive attributes?

btw, what do you know about exploit writers? and then what is a reasonably
skilled exploiter writer according to you? how would you even be able to
determine that?

let me tell you now a real distadvantage of your coverup: you're hurting
the good guys (the defenders) a lot more than you're hurting the bad guys
(the attackers). why? because of the usual asymmetry of the situation we
often face in security. an attacker needs to find only a single commit
silently fixing a security bug (never mind finding the earlier commit
that introduced it) whereas the defenders would have to find all of them.

thanks to your policy you can guess which side has a distinct advantage
from the start and how well the other side fares.

> And you yourself said that you don't want to put zero-day exploits
> into changelogs, so why are you even arguing?

it's not even arguing Ingo, that would assume sides with equal knowledge
but you have only delusions about the real world out there. i always
wondered where you guys cook up these ideas about script kiddies, exploits,
0day, etc. do you read about them in the news? do you follow conferences
and read papers? do you actively research vulnerabilities? seriously,
what's the source of all this nonsense i see?

> Secondly:
>
> - it's misleading because IMO CVE tagged bugs do not cover all
> bugs that matter,

sure but that's not your problem. as a kernel developer your task is
to keep your users informed about what you yourselves know. covering
it up does not serve users, it serves attackers.

> they are self-selected bugs
^^^^^^^^^^^^^
what does this mean?

> often highlighted by attention-seeking participants of the security circus.

what do external actors have to do with what you tell your users?
nothing? also, what is this 'security circus'? the security industry
is very big, it has many many actors in it (playing on a wide spectrum
of attack and defense), which ones are you referring to in particular?

> The primary driving force in that industry is attention seeking,

as always, it's not a black&white world, so yes, some actors can be
described as above but then others cannot. whatever their interest
however, i don't see what it matters to you. your job is not to force
people to behave one way or another (considering all the negative
response you've got so far, you've failed at it) but to keep your
users secure. covering up security fixes doesn't do that, informing
them does.

> *not* the maximization of security - and often they act in direct
> conflict to better security ...

i don't understand who you're referring to here. i believe the context
is people who provide you with security bugs, get a CVE and then go
public with it with more or less fanfare? is that what you're referring
to here? in any case, what does 'maximization of security' mean to you?
and how do these actors (whoever they are, define them please) act against
better security?

> Maximizing security is hard: whether a bug has security implications
> is highly usecase and bug dependent, and the true security impact of
> bugs is not discovered in the majority of cases. I estimate that in
> *ANY* OS there's probably at least 10 times more bugs with some
> potential security impact than ever get a CVE number...

sure but what does that imply for the bugs that you do know are security
related? i don't see how the coverup follows from it.

> So putting CVEs into the changelog is harmful,

it's not harmful, or at least not more harmful than withholding it. remember
the asymmetric situation. also by extension anyone else who publishes CVEs
is actively harming their users, is that what you're saying? if not then
explain why the rule applies to kernel development only but not the rest
of the world.

> pointless,

why? not knowing about security fixes harms exactly those who you claim
to protect, your users, the good guys.

> misleading

why? who's being misled and about what? a security bug is a security bug,
there's nothing misleading about it.

> and would just create a fake "scare users"

who's being scared by attaching a CVE to a commit? i've never seen such a
person in my life, have you? and what percentage of the userbase do you
think are 'scared' whenever a security bug's fixed? and why should the existence
of such users affect how the rest is informed? do you think that the weatherman
should retire as well because someone might be scared when told about the coming
storm ahead of time?

> and "gain attention" industry

that part of the industry is there, has been for a long while and is not
going away. why does all that matter to you guys though? in particular, how
do you think covering up security fixes will change anything in that part
of the industry? hint: it won't, in fact it will allow them grow even bigger
and louder since you continually provide munition to them.

> (coupled with a "delay bug fixes for a long time" aspect, if
> paid well enough)

uh, are you still talking about kernel security bugs? what are you referring
to here in particular? what's the connection between the above and covering
up security fixes? i think i'm getting lost here a bit, sorry ;).

> that operates based on issuing CVEs and 'solving'
> them - which disincentivises the *real* bugfixes and the
> non-self-selected bug fixers.

self-selected again, what's that mean here? and how does 'whatever you are
talking about above' discourage the 'real' bugfixes? what are these 'real
bugfixes'?

> I'd like to strengthen the natural 'bug fixing' industry, not the
> security circus industry.

what is this 'natural bug fixing industry' exactly? who are you thinking
of in particular? and how do you think covering up security fixes strengthens
this 'industry'? what does it even mean to strengthen them?

> I simply disagreed with you and argued with you without insulting you
> in such a tone.

yeah we all saw your tone now and in the past too. that's why you get
what you deserve ;). but then you're an adult person and can take the
heat, can't you? judging by the average Linus and other flames on lkml,
i think i was being pretty mild so far in fact ;).

> Does disagreeing with you make me an 'asshole'?

disagreements require (at least) two equally real and relevant choices
over which one can reasonably disagree. you have yet to present your
side of that relevant choice, until then i won't treat you as an equal
peer, sorry (you can start by answering the above questions, although
considering how many issues you skipped over so far i don't have high
hopes). so no, it's not about disagreements, it's about trying to
teach you some basics of security and in general, logical thinking.

> But the thing is, i probably shouldnt bother arguing with you since i
> have trouble convincing you about very obvious things like the simple
> fact that putting more instructions into the page fault path ...
> slows it down, why should i bother arguing with you here?

as i said in another mail, the devil is in the details, here, whether
that slowdown matters or not. man, every time you bring this up i have
to stop typing as i'm still smiling over your pride about that absolutely
bogus and irrelevant single cycle 'speedup' ;).

> You are not willing to listen and amazingly, in all these recent
> discussions you've never *ever* conceded a single point - even in
> cases where you were proven wrong beyond recognition!

show me a single point then ;). so far i only saw ex cathedra statements
without numbers (single cycle improvement, remember? haha, sorry couldn't
help it ;). anything else i missed? also a discussion is not a trade of
'now i'll agree with you on this point if you agree with me on that other
point'. i'll agree with what i think is correct and i'll point out bullshit
when i see it, simple as that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

Jun 10, 2011, 4:19 AM

Post #24 of 26 (2444 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

* pageexec [at] freemail <pageexec [at] freemail> wrote:

> let me tell you now a real distadvantage of your coverup: [...]

Our opinion is that the scheme you are suggesting is flawed and
reduces security, so we refuse to use it. That is not a 'coverup', to
the contrary, it *helps* security - see below.

> [...] you're hurting the good guys (the defenders) a lot more than
> you're hurting the bad guys (the attackers). why? because of the
> usual asymmetry of the situation we often face in security. an
> attacker needs to find only a single commit silently fixing a
> security bug (never mind finding the earlier commit that introduced
> it) whereas the defenders would have to find all of them.
>
> thanks to your policy you can guess which side has a distinct
> advantage from the start and how well the other side fares.

Firstly, the assymetry is fundamental: attackers *always* have an
easier way destroying stuff than the good guys are at building new
things. This is the second law of thermodynamics.

Secondly, you are missing one fundamental aspect: the 'good guys' are
not just the 'defenders'. The good guys are a *much* broader group of
people: the 'bug fixers'.

Thirdly, you never replied in substance to our arguments that CVE
numbers are woefully inadequate: they miss the majority of bugs that
can have a security impact. In fact i argue that the way software is
written and fixed today it's not possible to effectively map out
'bugs with a security impact' at all: pretty much *any* bug that
modifies the kernel image can have a security impact. Bug fixers are
not at all concentrated on thinking like parasitic attackers, so
security side effects often remain undiscovered. Why pretend we have
a list of CVEs when we know that it's only fake?

Fourth, exactly how does putting CVE numbers make it harder for
attackers? It makes it distinctly *easier*: people will update their
systems based on a list of say 10 CVEs that affect them, totally
blind to the 100+ other bugs that may (or may not) have an effect on
them. An attacker will now only have to find an *already fixed* bug
that has a security impact and which didn't get a CVE and attack a
large body of systems that people think are safe.

With the current upstream kernel policy we do not deceive users: we
say that the way to be most secure is to be uptodate. Attackers will
have to find an entirely new, not yet fixed security hole, instead of
just a bug that missed the CVE filter ...

I.e. our opinion is, on very good and honest grounds, that your
scheme creates a false sense of security and actually harms real
security and we simply refuse to support such a scheme.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pageexec at freemail

Jun 13, 2011, 5:48 PM

Post #25 of 26 (2426 views)
Permalink
Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule [In reply to]

On 10 Jun 2011 at 13:19, Ingo Molnar wrote:
> * pageexec [at] freemail <pageexec [at] freemail> wrote:
>
> > let me tell you now a real distadvantage of your coverup: [...]
>
> Our opinion is that the scheme you are suggesting [...]

why are you trying to make it 'my' scheme? it's not mine, i didn't come up
with it, it's what pretty much everyone else (other than you, that is) in
the world does, including your own employer, Red Hat.

i already asked you about this and you never responded so here it is again:
what do you think about Red Hat publishing security errata (including kernel
vulnerabilities)? with CVEs, description of fault, etc.

it's diametrically opposite to what you've been claiming so there seems to be
a disconnect here. do you actively disagree with your own employer's security
bug handling policy? you see, they're doing exactly what you're not willing to.

> [...] is flawed and reduces security, so we refuse to use it. That is not a
> 'coverup', to the contrary, it *helps* security - see below.

yeah well, we'll see about it. it looks like year after year you guys manage
to outdo yourselves in absurdity, one wonders if there'll be a new category
needed for this year's pwnie awards because you're likely to no longer fit the
lamest vendor response category.

> > [...] you're hurting the good guys (the defenders) a lot more than
> > you're hurting the bad guys (the attackers). why? because of the
> > usual asymmetry of the situation we often face in security. an
> > attacker needs to find only a single commit silently fixing a
> > security bug (never mind finding the earlier commit that introduced
> > it) whereas the defenders would have to find all of them.
> >
> > thanks to your policy you can guess which side has a distinct
> > advantage from the start and how well the other side fares.
>
> Firstly, the asymmetry is fundamental: attackers *always* have an
> easier way destroying stuff than the good guys are at building new
> things. This is the second law of thermodynamics.

what garbage. both sides are building stuff! in fact, finding vulnerabilities,
writing exploits is an even higher level creation process than normal development
as it gives us knowledge well beyond what we'd have if we were doing only the
usual development. what extra knowledge is that? without this kind of research
we'd have to accept at face value a developer's claim (expressed in source code)
that he's just written code that does this or that.

the extra info we learn through all the work done by security research is whether
said code lives up to its developer's claims or not. e.g., whenever someone finds
a vulnerability that allows arbitrary code execution is basically a proof that a
Turing machine thought to be non-universal is actually a universal one. and with
a working exploit the proof is even machine verifiable. this is one of the rare
instances when we can actually pull such stunts off for non-trivial codebases in
fact.

i find it amazing that this fact is even up for debate when in another subfield
of security, cryptology, both sides (cryptography and cryptanalysis) are well
accepted and studied subjects in academic, commercial, military, etc settings
worldwide, without all the negative connotations that seem to plague vulnerability
research in some minds.

as for the asymmetry: whether it's present in all situations or not is something
you don't know because you don't know all situations (in fact, you seem to know
very little about this whole subject). since i tend to err on the side of safety,
i said 'usual' and 'often' just because i can't exclude the possibility of a
situation where such asymmetry is not present or is much less pronounced than
what we face with vulnerabilities and exploits.

> Secondly, you are missing one fundamental aspect: the 'good guys' are
> not just the 'defenders'. The good guys are a *much* broader group of
> people: the 'bug fixers'.

is this language lawyering? what do you think bug fixers do? they reduce the
attack surface of a system and therefore are part of the defender group.

> Thirdly, you never replied in substance to our arguments that CVE
> numbers are woefully inadequate:

heh, i replied to you many times already but you didn't respond to dozens of
questions already (did you respond to this one because it was featured on LWN?).
the answers are all there Ingo, you just have to read them.

and it's never been about CVE per se btw, it was about 'some' information that
would help one reading the commit clearly understand that it's a fix for a
security bug, as far as the committer knew.

whether a CVE or similar piece of information is inadequate depends on what the
goal is. clearly, you're thinking in extreme black&white terms once again.
somehow you seem to believe that if you can't provide perfect and complete
information about security bugs then providing *no* information is somehow the
better choice? and better for what? end users' security? truly mind boggling!

> they miss the majority of bugs that can have a security impact.

you don't understand the whole purpose of CVE and similar information. it's not
about providing guaranteed full coverage about any and all vulnerabilities that
exist. that knowledge is kinda non-existent as far as we know. instead, CVE is
a mechanism that let's the world organize of what is *known* and communicate it
between all parties (vendors, developers, users, etc). your stubborn refusal to
even contemplate the idea of communicating your own knowledge to your own users
is very stupid and haven't earned you many friends out there (it, however, serves
as an excellent basis for every sales speech by every security vendor out there).

> In fact i argue that the way software is written and fixed today it's
> not possible to effectively map out 'bugs with a security impact' at
> all: pretty much *any* bug that modifies the kernel image can have a
> security impact.

this is a strawman, noone asks for this kind of work as you're not even in the
position to be able to do this even if you tried. last but not least, it's also

"not possible to effectively map out 'bugs that can cause filesystem
corruption' at all: pretty much *any* bug that modifies the kernel
image can cause filesystem corruption".

however that little fact somehow never prevented you guys from describing such
fixes in the commits which contradicts your desire to not give your users a false
sense of (filesystem) security. so if you want to follow your own words, you'll
have to *stop* letting the world know when you fix a known filesystem corruption
bug since based on what you argued so far, you can't guarantee that those are the
*only* such bugs/fixes. what's more, covering up filesystem corruption bugs will
also help everyone who has to backport them to their own supported kernels (for
yet to be explained reasons, i'm sure the world's dying to know now how they're
supposed to pull that off).

> Bug fixers are not at all concentrated on thinking like parasitic
> attackers, so security side effects often remain undiscovered.

noone ever expects it from them as it's never been a matter of concentration,
it's a matter of being skilled at it which you are not, there's nothing wrong
with it.

calling people who do the hard work of vulnerability research 'parasitic' shows
only how insecure (no pun intended) you feel about this whole situation: you
(presumably) do your best to write code and then comes someone out of the blue
and pokes a hundred holes in it and your subconscious self-defense begins to
distort your view of yourself and the others.

btw, would you call every respected cryptographer out there a parasite? because
that's what you effectively said.

> Why pretend we have a list of CVEs when we know that it's only fake?

because CVEs are not about what you seem to think they are. knowing that a given
bug is exploitable is not 'fake', communicating it to your users is not 'fake'.
lying about it is however dishonest of utmost proportions. btw, how's all this
sit with the 'full disclosure' declared in Documentation/SecurityBugs? ever
thought of clearing it up?

> Fourth, exactly how does putting CVE numbers make it harder for
> attackers?

a little help in reading comprehension of what i said:

> > you're hurting the good guys (the defenders) a lot more than
> > you're hurting the bad guys (the attackers).

what (you think) makes life harder for attackers is *withholding* CVE or similar
information from commits, not their inclusion.

> It makes it distinctly *easier*: people will update their systems
> based on a list of say 10 CVEs that affect them, totally blind to the
> 100+ other bugs that may (or may not) have an effect on them.

'people' are not updating their systems based on any list. 'people' update their
systems based on what their kernel supplier (vendor/distro/company's internal
team/etc) provides them with (there's an extreme minority of users who build
their own kernels of the latest vanilla tree).

now the big question becomes whether these suppliers are helped or obstructed by
your policy of covering up security fixes. given that pretty much none of them
supports the latest vanilla tree, not even -stable, it means that in order to
release new kernels they'll have to backport fixes. fixes that they don't even
know they should be backporting because of your covering them up. so what happens
is that everyone has to read every commit and do his best estimate whether it's
worthy of backporting or not (notice the waste of duplicated effort). don't you
think they could spend more time on finding actually important fixes if they
could skip over the already known ones and just backport them?

> An attacker will now only have to find an *already fixed* bug

what makes you think an attacker is interested at all in already fixed bugs?
who's gonna pay for an exploit against such a bug? that's not exactly where
the market is.

> that has a security impact and which didn't get a CVE and attack a
> large body of systems that people think are safe.

people don't think that systems are safe just because there're no outstanding
CVEs against them (where did this idea come from?) because everyone who has ever
heard of CVEs knows about 0-day bugs as well (if for no other reason than the
simple fact that there're CVEs issued for 0-day bugs as they became public).

> With the current upstream kernel policy we do not deceive users: we
> say that the way to be most secure is to be uptodate.

where do you say that?

what you do say is that you practice full disclosure though which you're
apparently not doing in practice as you cover up security fixes. besides, if,
as you said above, you don't actually figure out the security impact of all the
bugs you fix, what's the guarantee that the latest kernel (whatever up-to-date
means, git HEAD?) didn't introduce more bugs than it fixed? if you can't provide
such a guarantee (no, saying it is not it) then using the latest kernel is as
good as using anything else, if not worse (since older kernels at least had
more eyes scrutinize them by virtue of being around for longer).

the biggest flaw with your argument is that noone uses up-to-date kernels because
they have to rely on vendors/distros/etc. and for them to be able to produce an
up-to-date kernel they'd need to know the exact information that you're omitting.
so for the majority of users you make it impossible to be the most secure.

> Attackers will have to find an entirely new, not yet fixed security
> hole, instead of just a bug that missed the CVE filter ...

why would an attacker need to find a 0-day bug when he can just sit back and
watch as the kernel suppliers struggle with backporting covered up security
fixes and pick up the ones they missed? unless you want to claim that attackers
are worse at identifying said silent fixes than kernel suppliers but i hope you
realize how ridiculous that would be.

> I.e. our opinion is, on very good and honest grounds,

'good' and 'honest' are not exactly the words i'd use here ;)

> that your scheme creates a false sense of security and actually harms
> real security and we simply refuse to support such a scheme.

false sense of security is a term that you should understand before you use it
in context. in particular, you didn't demonstrate the origin of any sense of
security, never mind a false one. second, you didn't demonstrate any harm from
properly disclosing security fixes (vs. covering them up).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.