linux-kernel - Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy

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: <1962EE67-8AD1-409D-963A-4F1E1AB3B865@amacapital.net>
Date:   Thu, 30 Apr 2020 17:23:31 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        stable <stable@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paul Mackerras <paulus@...ba.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Erwin Tsaur <erwin.tsaur@...el.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 5:10 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> On Thu, Apr 30, 2020 at 4:52 PM Dan Williams <dan.j.williams@...el.com> wrote:
>> 
>> You had me until here. Up to this point I was grokking that Andy's
>> "_fallible" suggestion does help explain better than "_safe", because
>> the copy is doing extra safety checks. copy_to_user() and
>> copy_to_user_fallible() mean *something* where copy_to_user_safe()
>> does not.
> 
> It's a horrible word, btw. The word doesn't actually mean what Andy
> means it to mean. "fallible" means "can make mistakes", not "can
> fault".
> 
> So "fallible" is a horrible name.

What I was trying to get at was not “can fault” but “can malfunction”.  Maybe “unreliable”?  Better words welcome.

> 
> But anyway, I don't hate something like "copy_to_user_fallible()"
> conceptually. The naming needs to be fixed, in that "user" can always
> take a fault, so it's the _source_ that can fault, not the "user"
> part.

I don’t like this.  “user” already implied that basically anything can be wrong with the memory — it can be unmapped entirely, it can have the wrong permissions, it can have the wrong protection key, it can have an ECC error, etc.  If the operation you want is “copy from unreliable kernel memory (but with a definitely valid pointer) to user memory”, you want copy_unreliable_to_user().

Now maybe copy_to_user() should *always* work this way, but I’m not convinced. Certainly put_user() shouldn’t — the result wouldn’t even be well defined. And I’m unconvinced that it makes much sense for the majority of copy_to_user() callers that are also directly accessing the source structure.

I also tend to think that the probe_kernel stuff should just stay separate. Those are really for two totally separate types of use: either the kernel is trying its best to print an errr message without exploding worse, or it’s involved in eBPF or trading hacks in which address is arbitrary and essentially untrusted.