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: Fri, 10 Jun 2011 13:19:32 +0200 [thread overview]
Message-ID: <20110610111932.GA30987@elte.hu> (raw)
In-Reply-To: <4DEEB31B.24457.19E64984@pageexec.freemail.hu>
* pageexec@freemail.hu <pageexec@freemail.hu> 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
next prev parent reply other threads:[~2011-06-10 11:20 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
2011-06-07 23:24 ` pageexec
2011-06-10 11:19 ` Ingo Molnar [this message]
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=20110610111932.GA30987@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.