On Fri, Nov 17, 2017 at 9:45 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 17/11/2017 18:35, Linus Torvalds wrote: >> Honestly, I'm unlikely to pull this at all this merge window, simply >> because I won't have time for it. This merge window is not going to be >> one where I can take a leisurely look at something like this. >> >> If you can make a smaller pull request that introduces the >> infrastructure, but that _obviously_ cannot actually break anything, >> that would be more likely to be palatable. > > As someone that was actually bitten by this stuff, and had a closer look > at the usercopy whitelisting stuff... This one is really fail-fast > (oopses all around if you forget to patch something), and with hardly
This is why I introduced the fallback mode: with both kvm and sctp (ipv6) not noticed until late in the development cycle, I became much less satisfied it had gotten sufficient testing. I wanted to make sure there was a way for the series to land without actually breaking things due to any missed whitelists. > any configuration dependency. It's certainly a lot less scary to me > than the GCC plugin stuff. Agreed: this is a different type of change entirely. The GCC plugins tend to be pretty invasive and non-discoverable. I prefer stuff like this series, which is all visible in the code. > But I don't want to ruin your Thanksgiving, so if Kees and/or you choose > not to do this pull request---please do pull a subset, even after -rc1. > It's easy enough to drop the final patch that changes whitelisting to > blacklisting, and it'd be one less series bouncing around and touching > files in several subsystems. With the fallback mode, missed whitelists generate a WARN and are allowed, so this series effectively only introduces tight controls on the places where a whitelist is specifically introduced. And I went to great lengths to document each whitelist usage in the commit logs. I would agree it would be nice to get at least a subset of this in, though. Linus, what would make you most comfortable? -Kees -- Kees Cook Pixel Security
