linux-kernel - Re: [RFC][CFT][PATCHSET v1] uaccess unification

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>] [day] [month] [year] [list]

Message-ID: <CACVxJT8XeP37yivEP1k-8DSA_oUcpD4vhwYtud-Vdoy4tdJyNg@mail.gmail.com>
Date:   Thu, 30 Mar 2017 16:27:43 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification

[cc linux-kernel]

On Thu, Mar 30, 2017 at 4:25 PM, Alexey Dobriyan <adobriyan@...il.com> wrote:
>> void *to, const void *from, unsigned long size
>
> Type of the last argument should be "unsigned int",
> for the following reasons:
> * on x86_64 actual copying is done as 32-bit: types flip to "unsigned"
>   at some point and 32-bit registers are used in assembly
>
> * 4GB+ copies simply do not exist:
>   kernel doesn't have data structures that big,
>
>   huge copies are done with cond_resched() in between
>   (with or without proxy pages),
>
>   even if they exist, they do not work on x86_64 now and can be
>   trivially wrapped as copy_from_user64() or something.
>
>   VFS truncates everything at INT_MAX exactly to not deal with all
>   the bugs associated with implicit type conversions.
>
> * Binary code becomes smaller: it doesn't matter for constant sizes,
>   but people tend to maintain type "safety" by using size_t and
>   do 64-bit arithmetic where it is unnecessary. I've sent some
>   patches to networking people already and have much more
>   which exterminate "size_t" from net/ and they give smaller code
>   size overall.
>
> Same arguments apply to kmalloc(), strlen(), memcpy() and
> all functions which are "size_t len".
>
> There was one time when Xen(?) people asked for 64-bit memcpy(),
> I can't remember any other example.
>
>     A