netdev - Re: Fwd: FW: [PATCH 18/31] nds32: Library functions

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

Message-ID: <20171118024436.GR21978@ZenIV.linux.org.uk>
Date:   Sat, 18 Nov 2017 02:44:36 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Vincent Chen <deanbo422@...il.com>
Cc:     viro@....linux.org.uk, greentime@...estech.com,
        Green Hu <green.hu@...il.com>, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
        tglx@...utronix.de, jason@...edaemon.net, marc.zyngier@....com,
        robh+dt@...nel.org, netdev@...r.kernel.org, vincentc@...estech.com
Subject: Re: Fwd: FW: [PATCH 18/31] nds32: Library functions

On Tue, Nov 14, 2017 at 12:47:04PM +0800, Vincent Chen wrote:

> Thanks
> So, I should keep the area that we've copied into instead of zeroing
> the area even if unpredicted exception is happened. Right?

Yes.  Here's what's required: if raw_copy_{from,to}_user(from, to, size)
returns n, we want
	* 0 <= n <= size
	* no bytes outside of to[0 .. size - n - 1] modified
	* all bytes in that range replaced with corresponding bytes of range
from[0 .. size - n - 1]
	* non-zero return values should happen only when some loads (in case
of raw_copy_from_user()) or stores (in case of raw_copy_to_user()) had failed.
If everything could have been read and written, we must copy everything.
	* return value should be equal to size only if no load or no store
had been possible.  In all other cases you need to copy at least something.
You don't have to squeeze all bytes that can be copied (you can, of course,
but it's not required).
	* you should not assume that failing load guarantees that subsequent
loads further into the same page will keep failing; normally they will, but
relying upon that is asking for trouble.  Several architectures had bugs
of that sort, with varying amounts of nastiness happening when e.g. write(2)
raced with mprotect(2) from another thread...

For almost any architecture these should be more or less parallel to memcpy();
the only exception I know of is the situation when cross-address-space copy
has timing very different from that for normal load+store.  s390 is that
way - there's considerable overhead of setting such copying, and you really
want it done in bigger chunks than would be optimal for memcpy().  uml is
similar.  However, generally it's memcpy tweaked to deal with exceptions.