linux-kernel - RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access

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]

Message-ID: <f786e02245424e02b38f55ae6b29d14a@AcuMS.aculab.com>
Date: Sun, 24 Mar 2024 19:42:01 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alexandre Ghiti' <alex@...ti.fr>, Samuel Holland
	<samuel.holland@...ive.com>, Alexandre Ghiti <alexghiti@...osinc.com>
CC: Palmer Dabbelt <palmer@...belt.com>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, Albert Ou <aou@...s.berkeley.edu>, "Andrew
 Morton" <akpm@...ux-foundation.org>, Charlie Jenkins <charlie@...osinc.com>,
	Guo Ren <guoren@...nel.org>, Jisheng Zhang <jszhang@...nel.org>, Kemeng Shi
	<shikemeng@...weicloud.com>, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
	"Mike Rapoport (IBM)" <rppt@...nel.org>, Paul Walmsley
	<paul.walmsley@...ive.com>, Xiao Wang <xiao.w.wang@...el.com>, Yangyu Chen
	<cyy@...self.name>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok()

...
> The use of alternatives allows to return right away if the buffer is
> beyond the usable user address space, and it's not just "slightly
> faster" for some cases (a very large buffer with only a few bytes being
> beyond the limit or someone could fault-in all the user pages and fail
> very late...etc). access_ok() is here to guarantee that such situations
> don't happen, so actually it makes more sense to use an alternative to
> avoid that.

Is it really worth doing ANY optimisations for the -EFAULT path?
They really don't happen.

The only fault path that matters is the one that has to page in
data from somewhere.

Provided there is a gap between the highest valid user address and the
lowest valid kernel address (may not be true on some 32bit systems)
and copy_to/from_user() do 'increasing address' copies then the
access_ok() check they do can almost certainly ignore the length.

This may be true for pretty much all access_ok() tests?
It would certainly simplify the test.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)