From: firstname.lastname@example.org To: Ingo Molnar <email@example.com> Cc: Linus Torvalds <firstname.lastname@example.org>, Andi Kleen <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, email@example.com, Thomas Gleixner <firstname.lastname@example.org>, email@example.com, Jesper Juhl <firstname.lastname@example.org>, Borislav Petkov <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Arjan van de Ven <email@example.com>, Jan Beulich <JBeulich@novell.com>, richard -rw- weinberger <firstname.lastname@example.org>, Mikael Pettersson <email@example.com>, Brian Gerst <firstname.lastname@example.org>, 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, 14 Jun 2011 02:48:35 +0200 Message-ID: <4DF6AFE3.11023.3919B397@pageexec.freemail.hu> (raw) In-Reply-To: <20110610111932.GA30987@elte.hu> On 10 Jun 2011 at 13:19, Ingo Molnar wrote: > * email@example.com <firstname.lastname@example.org> 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).
next prev parent reply index 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 2011-06-14 0:48 ` pageexec [this message] 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=4DF6AFE3.11023.3919B397@pageexec.freemail.hu \ --email@example.com \ --cc=JBeulich@novell.com \ --cc=Louis.Rilling@kerlabs.com \ --cc=Valdis.Kletnieks@vt.edu \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git