linux-kernel - Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jK-mTyhKE5pLtv51v0__KptSMJtSUfNg2ZYm2TxOkR8AA@mail.gmail.com>
Date:   Fri, 17 Nov 2017 14:19:52 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        David Windsor <dave@...lcore.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

On Fri, Nov 17, 2017 at 1:13 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> As long as you see your hardening efforts primarily as a "let me kill
> the machine/process on bad behavior", I will stop taking those shit
> patches.

Yes, this is entirely clear. This is why I adjusted this series (in
multiple places) to use WARN, etc etc. And why I went to great lengths
to document the rationale, effects, and alloc/use paths so when
something went wrong it would be easy to see what was happening and
why.

> So the hardening efforts should instead _start_ from the standpoint of
> "let's warn about what looks dangerous, and maybe in a _year_ when
> we've warned for a long time, and we are confident that we've actually
> caught all the normal cases, _then_ we can start taking more drastic
> measures".

Understood: I think my main flaw in helping bring these defenses to
the kernel has been thinking they can be fully tested during a single
development cycle, and this mistake was made quite clear this cycle,
which is why I adjusted the series like I did.

> Right now, the biggest problem for me is that the whole thing makes me
> uncomfortable, because I think the people involved are coming from a
> completely unacceptable model to begin with.
>
> And we had this exact issue with the _previous_ user mode access
> hardening. People apparently didn't learn a goddamn thing.

Well, I'd like to think I did learn something, since I fixed up this
series _before_ you yelled at me. :)

I'll make further adjustments and try again for v4.16.

-Kees

-- 
Kees Cook
Pixel Security