oss-sec mailing list archives
Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method
From: Shawn <citypw () gmail com>
Date: Sun, 25 Jun 2017 00:07:10 +0800
Hi Alexander, I respect your decision. Because this is your list. To myself, it's not a crap. I was just simply talking the fact I know. I've been suffering from Linux security for a long time due to lacking of the defensive mitigation. Anyway, this kind of discussion may be somewhere else but not on oss-security. S0rry for the extra maintainence work on pre-moderation. On Sat, Jun 24, 2017 at 11:55 PM, Solar Designer <solar () openwall com> wrote:
Shawn, I really don't appreciate you CC'ing kernel-hardening on this. As I wrote to you in the rejection message for that copy of your message: "It's sufficient that we have this crap on oss-security. Let's not spam kernel-hardening with it as well. Let's have it on just one list, and it just so happens it started on oss-security this one time. As a moderator, I fully expect I'll have to shut down this thread soon anyway." I also had to switch kernel-hardening to full message pre-moderation because of your CC. Hopefully temporarily again. Last time I did this (recently), and had since undone it (re-enabling the whitelist until today), was because of what I'll call an "anti-grsecurity crap" thread. Why pre-moderate even for previously whitelisted senders? Because they might be replying to this thread that you attempted to CC to kernel-hardening, without them realizing that your initial message was not approved there. This is a general problem with CC's to moderated lists, and why I ask that all of us please use CC's sparingly. I don't like censorship, but I also want these mailing lists to remain usable for their primary intended purposes for all of us. This is why we generally don't reject individual messages in these discussion threads until eventually having to shut down the threads. So all sides have an equal opportunity to speak. FWIW, my own opinion on the actual matters raised in these threads is nuanced. I'm not with either side. I guess this makes it easier for me to stay neutral as a moderator. Alexander
-- GNU powered it... GPL protect it... God blessing it... regards Shawn
Current thread:
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method, (continued)
- 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)
- civilized discussion (Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method) Solar Designer (Jun 26)
- Re: civilized discussion (Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method) Kurt Seifried (Jun 26)
- Re: civilized discussion (Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method) Kyle R (Jun 27)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Solar Designer (Jun 24)
- Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method Shawn (Jun 24)