Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

[Andy Lutomirski]

> On Apr 30, 2020, at 5:10 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> ïOn Thu, Apr 30, 2020 at 4:52 PM Dan Williams <dan.j.williams@xxxxxxxxx> 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.