Date: Sat, 3 Jun 2017 15:19:20 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: Linux kernel: stack buffer overflow with controlled payload in get_options() function Oh, and there I was hoping this thread had ended. On Sat, Jun 03, 2017 at 08:30:18AM -0400, Daniel Micay wrote: > On Sat, 2017-06-03 at 12:06 +0200, Florian Weimer wrote: > > I'm not a Red Hat spokesperson, and I did not speak for Red Hat. > If you don't want to act as a Red Hat spokesperson, use a > personal email address Daniel, I think that's too much. > > Part of the problem with UEFI Secure Boot is that no one > > has documented clear security objectives for UEFI Secure Boot. Fedora > > sort of evolved into "no unsigned code running in ring 0 without > > virtualization". From what I can tell, Microsoft picked that up and > > urged other distributions under their trust root to implement that as > > well. > > So, no meaningful security objective This might be right. Maybe there's a compliance objective: Microsoft would let distros use their trust root under some conditions, and from distros' point of view it doesn't matter much whether those conditions are meaningful or not as long as they're easy to meet. Then maybe treating those bypasses as non-security is a risk, as it draws attention to the current convenient terms of Microsoft not making security sense, and thus a risk of those terms changing to something more demanding. If so, it's technically off-topic for oss-security (and probably for CVE), but with the different opinions and without certainty about this interpretation I am not going to use this for moderation decisions just yet. I will not be rejecting messages on new (non-)issues in this area. I just ask that we please refrain from lengthy threads on each and every such (non-)issue. I will be pushing them from the (linux-)distros list to the public right away, if any more are brought to the private lists. I haven't participated in past discussions on this, nor had any interest in them. (I am dragged into this now as list admin/moderator; if someone else ran the list, I would not be posting to this thread.) I might very well be wrong in the above paragraph (which is a reason why no decision to reject new (non-)issues). Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ