All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: pageexec@freemail.hu
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>, Andy Lutomirski <luto@mit.edu>,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, Jesper Juhl <jj@chaosbits.net>,
	Borislav Petkov <bp@alien8.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Jan Beulich <JBeulich@novell.com>,
	richard -rw- weinberger <richard.weinberger@gmail.com>,
	Mikael Pettersson <mikpe@it.uu.se>,
	Brian Gerst <brgerst@gmail.com>,
	Louis Rilling <Louis.Rilling@kerlabs.com>,
	Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
Date: Tue, 7 Jun 2011 11:51:35 +0200	[thread overview]
Message-ID: <20110607095135.GD4133@elte.hu> (raw)
In-Reply-To: <4DED7222.28864.150079CE@pageexec.freemail.hu>


* pageexec@freemail.hu <pageexec@freemail.hu> wrote:

> On 6 Jun 2011 at 21:25, Ingo Molnar wrote:
> 
> > * pageexec@freemail.hu <pageexec@freemail.hu> 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

  reply	other threads:[~2011-06-07  9:52 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-05 17:50 [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 1/9] x86-64: Fix alignment of jiffies variable Andy Lutomirski
2011-06-06  8:31   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 2/9] x86-64: Document some of entry_64.S Andy Lutomirski
2011-06-06  8:31   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 3/9] x86-64: Give vvars their own page Andy Lutomirski
2011-06-06  8:32   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 4/9] x86-64: Remove kernel.vsyscall64 sysctl Andy Lutomirski
2011-06-06  8:32   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-12-05 18:27   ` [PATCH v5 4/9] " Matthew Maurer
2011-06-05 17:50 ` [PATCH v5 5/9] x86-64: Map the HPET NX Andy Lutomirski
2011-06-06  8:33   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 6/9] x86-64: Remove vsyscall number 3 (venosys) Andy Lutomirski
2011-06-06  8:33   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 7/9] x86-64: Fill unused parts of the vsyscall page with 0xcc Andy Lutomirski
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls Andy Lutomirski
2011-06-05 19:30   ` Ingo Molnar
2011-06-05 20:01     ` Andrew Lutomirski
2011-06-06  7:39       ` Ingo Molnar
2011-06-06  9:42       ` pageexec
2011-06-06 11:19         ` Andrew Lutomirski
2011-06-06 11:56           ` pageexec
2011-06-06 12:43             ` Andrew Lutomirski
2011-06-06 13:58               ` pageexec
2011-06-06 14:07                 ` Brian Gerst
2011-06-07 23:32                   ` pageexec
2011-06-07 23:49                     ` Andrew Lutomirski
2011-06-08  6:32                       ` pageexec
2011-06-06 15:26                 ` Ingo Molnar
2011-06-06 15:48                   ` pageexec
2011-06-06 15:59                     ` Ingo Molnar
2011-06-06 16:19                       ` pageexec
2011-06-06 16:47                         ` Ingo Molnar
2011-06-06 22:49                           ` pageexec
2011-06-06 22:57                             ` david
2011-06-07  9:07                               ` Ingo Molnar
2011-06-07  6:59                             ` Pekka Enberg
2011-06-07  8:30                             ` Ingo Molnar
2011-06-07 23:24                               ` pageexec
2011-06-08  5:55                                 ` Pekka Enberg
2011-06-08  6:19                                   ` pageexec
2011-06-08  6:48                                 ` Ingo Molnar
2011-06-08  9:02                                   ` pageexec
2011-06-08  9:11                                     ` Andi Kleen
2011-06-08  9:35                                       ` pageexec
2011-06-08 10:06                                         ` Andi Kleen
2011-06-08 10:26                                           ` pageexec
2011-06-08 10:39                                             ` Ingo Molnar
2011-06-08 10:35                                           ` Ingo Molnar
2011-06-08  9:15                                     ` Ingo Molnar
2011-06-08  7:16                                 ` Ingo Molnar
2011-06-08  9:29                                   ` pageexec
2011-06-06 14:01             ` Linus Torvalds
2011-06-06 14:55               ` pageexec
2011-06-06 15:33                 ` Ingo Molnar
2011-06-06 15:58                   ` pageexec
2011-06-06 15:41         ` Ingo Molnar
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-06  8:35   ` [tip:x86/vdso] x86-64, vdso, seccomp: Fix !CONFIG_SECCOMP build tip-bot for Ingo Molnar
2011-06-07  7:49   ` [tip:x86/vdso] x86-64: Emulate legacy vsyscalls tip-bot for Andy Lutomirski
2011-06-07  8:03   ` tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule Andy Lutomirski
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-06  8:46   ` [PATCH v5 9/9] " Linus Torvalds
2011-06-06  9:31     ` Andi Kleen
2011-06-06 10:39       ` pageexec
2011-06-06 13:56         ` Linus Torvalds
2011-06-06 18:46           ` pageexec
2011-06-06 20:40             ` Linus Torvalds
2011-06-06 20:51               ` Andrew Lutomirski
2011-06-06 21:54                 ` Ingo Molnar
2011-06-06 21:45               ` Ingo Molnar
2011-06-06 21:48                 ` Ingo Molnar
     [not found]                 ` <BANLkTi==uw_h78oaep1cCOCzwY0edLUU_Q@mail.gmail.com>
2011-06-07  8:03                   ` [PATCH, v6] x86-64: Emulate legacy vsyscalls Ingo Molnar
2011-06-06 21:53               ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule pageexec
2011-06-06 14:44         ` Ingo Molnar
2011-06-06 15:01           ` pageexec
2011-06-06 15:15             ` Ingo Molnar
2011-06-06 15:29               ` pageexec
2011-06-06 16:54                 ` Ingo Molnar
2011-06-06 18:59           ` pageexec
2011-06-06 19:25             ` Ingo Molnar
2011-06-07  0:34               ` pageexec
2011-06-07  9:51                 ` Ingo Molnar [this message]
2011-06-07 23:24                   ` pageexec
2011-06-10 11:19                     ` Ingo Molnar
2011-06-14  0:48                       ` pageexec
2011-06-15 19:42                         ` Valdis.Kletnieks
2011-06-06 14:52         ` Ingo Molnar
2011-06-06 10:24     ` [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS Ingo Molnar
2011-06-06 11:20       ` pageexec
2011-06-06 12:47         ` Ingo Molnar
2011-06-06 12:48           ` Ingo Molnar
2011-06-06 18:04           ` pageexec
2011-06-06 19:12             ` Ingo Molnar
2011-06-07  0:02               ` pageexec
2011-06-07  9:56                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-09  6:48                     ` Ingo Molnar
2011-06-09 23:33                       ` pageexec
2011-06-07 10:05                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-09  7:02                     ` Ingo Molnar
2011-06-09 23:33                       ` pageexec
2011-06-07 10:13                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-06 12:19       ` Ted Ts'o
2011-06-06 12:33         ` Andrew Lutomirski
2011-06-06 12:37         ` Ingo Molnar
2011-06-06 14:34     ` [tip:x86/vdso] " tip-bot for Ingo Molnar
2011-06-05 20:05 ` [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andrew Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110607095135.GD4133@elte.hu \
    --to=mingo@elte.hu \
    --cc=JBeulich@novell.com \
    --cc=Louis.Rilling@kerlabs.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=jj@chaosbits.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mikpe@it.uu.se \
    --cc=pageexec@freemail.hu \
    --cc=richard.weinberger@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.