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  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]
Date:   Thu, 30 Apr 2020 17:23:31 -0700
From:   Andy Lutomirski <>
To:     Linus Torvalds <>
Cc:     Dan Williams <>,
        "Luck, Tony" <>,
        Andy Lutomirski <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,
        Peter Zijlstra <>,
        Borislav Petkov <>,
        stable <>,
        the arch/x86 maintainers <>,
        "H. Peter Anvin" <>,
        Paul Mackerras <>,
        Benjamin Herrenschmidt <>,
        Erwin Tsaur <>,
        Michael Ellerman <>,
        Arnaldo Carvalho de Melo <>,
        linux-nvdimm <>,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 5:10 PM, Linus Torvalds <> wrote:
> On Thu, Apr 30, 2020 at 4:52 PM Dan Williams <> 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.

Powered by blists - more mailing lists