oss-sec mailing list archives
Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method
From: Brad Spengler <spender () grsecurity net>
Date: Fri, 23 Jun 2017 21:54:57 -0400
On Fri, Jun 23, 2017 at 06:04:00PM -0700, Linus Torvalds wrote:
On Fri, Jun 23, 2017 at 5:50 PM, Brad Spengler <spender () grsecurity net> wrote:BTW, we're happy to go toe-to-toe with you here in public on actual facts instead of pathetic ad hominems.Quite frankly, I'd much rather see *you* actually send in patches that are acceptable for inclusion, something you've never done. As it is, other people have tried to clean up parts of the grsecurity patches, and tried to make them acceptable. Wouldn't it be nice if you actually tried to make the baseline actually better?
Are you delusional? Sorry, you don't get to weasel your way out of calling us clowns, that our code is garbage, with this weak reply where you can pretend you didn't just say those things and now would love for us to provide our "garbage" code directly. Also you might be in confusion as to the extent to which KSPP is "cleaning up" parts of our code -- they're definitely introducing bugs and renaming variables. Other than that, they have a tendency to misrepresent the source of their ideas, so I can understand the cause of your confusion. This, for instance: http://www.openwall.com/lists/kernel-hardening/2017/06/20/34 was simply someone realizing we had updated the code they previously copy+pasted, and copy+pasted the newer version. He is being funded to do this. He even emailed me for help figuring out the code he was being paid to copy+paste. Wouldn't it be nice if you didn't demand free work of us in our free time? We publicly gave permission for any company involved in the KSPP to publish the private details of any supposed offers made to us, including any financial terms. No such offers have ever materialized in public, I wonder why that is? Until you acknowledge the KSPP is business competition dreamed up by Google, who made a conscious decision somewhere higher up in the company than Kees to compete with us instead of cooperating with us, there is no negotiation. You thought you'd get away with it by being able to continue using our own test patches against us, and now look at the mess you've all created. How many dozens of incompetent people are you going to fund full time to avoid getting help from the people with real knowledge? Linux's technical debt is only going to increase, and when the KSPP contributors veer into original idea territory (which they're soon going to have to do a lot more of), the results make Linux look as dumb as OpenBSD preventing NOP-sliding into ROP gadgets. If you really wanted our help, you would know how to get it -- we've posted about it publicly (and I'll publish it here too for the record if this mail is allowed through despite being totally off-topic and non-technical): 1) Forget 'bugs are bugs' 2) Stop obfuscating commit messages 3) Actually put someone (or someones) in charge of security, start having actual responsibility instead of pretending you guys are just doing the work in your free time. If Jon Corbet has to submit a fix himself, something is clearly broken. 4) Have a basic level of respect 5) Fund our work so that we have the free time to help out. As it stands, any time spent helping takes away from our own work (which becomes the security of Linux a decade from now, quite literally). It's that simple, but you (collectively) seem to be unwilling to do any of the above. -Brad
Attachment:
signature.asc
Description: Digital signature
Current thread:
- More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Brad Spengler (Jun 23)
- Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Linus Torvalds (Jun 23)
- Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Brad Spengler (Jun 24)
- Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Brad Spengler (Jun 24)
- Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Linus Torvalds (Jun 24)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Brad Spengler (Jun 24)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Mansour Moufid (Jun 26)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Kurt Seifried (Jun 26)
- RE: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Christey, Steven M. (Jun 26)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit meth PaX Team (Jun 27)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit meth Kurt Seifried (Jun 26)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit meth PaX Team (Jun 27)
- Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Linus Torvalds (Jun 23)
- civilized discussion (Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method) Solar Designer (Jun 26)