linux-kernel - Re: Question on "uaccess: Add strict non-pagefault kernel-space read function"

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]

Date:   Fri, 3 Apr 2020 16:20:24 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
        bgregg@...flix.com
Subject: Re: Question on "uaccess: Add strict non-pagefault kernel-space read
 function"

Hi Christoph,

On 4/3/20 3:35 PM, Christoph Hellwig wrote:
[...]
> I just stumbled over your above commit, and it really confuses me.
> 
> Not the newly added functions, which seems perfectly sane, but why you
> left the crazy old functions in place instead of investing a little
> bit of extra effort to clean the existing mess up and switch everyone
> to the sane new variants?

With crazy old functions I presume you mean the old bpf_probe_read()
which is mapped to BPF_FUNC_probe_read helper or something else entirely?

For the former, basically my main concern was that these would otherwise
break existing tools like bcc/bpftrace/.. unfortunately until they are not
converted over yet to _strict variants.

At least on x86, they would still rely on the broken semantic to probe
kernel and user memory with probe_read where it 'happens to work', but not
on other archs where the address space is not shared.

But once these are fixed, I would love to deprecate these in one way or
another. The warning in 00c42373d397 ("x86-64: add warning for non-canonical
user access address dereferences") should be a good incentive to switch
since people have been hitting it in production as the non-canonical space
is sometimes used in user space to tag pointers, for example.

Thanks,
Daniel