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: <5c027cbf6b8741e4a8147963b07a8ac4@AcuMS.aculab.com>
Date: Mon, 25 Mar 2024 09:30:23 +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()

From: Alexandre Ghiti
> Sent: 25 March 2024 07:31
> 
> Hi David,
> 
> On 24/03/2024 20:42, David Laight wrote:
> > ...
> >> 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.
> 
> 
> Which is completely avoided with a strict definition of access_ok(). I
> see access_ok() as an already existing optimization of fault paths by
> avoiding them entirely when they are bound to happen.

No, access_ok() exists because accesses to kernel addresses don't fault.
Possibly in linux 0.01 it tried to ensure that the access was valid
(by checking the process's page tables (etc) but that that hasn't been
true for a long time.

You don't want to add a single instruction (never mind a conditional)
to access_ok() to avoid a page fault on an address that will fault.

Basically real programs don't pass bad addresses into the kernel
or access them in userspace. EFAULT and SIGSEGV are pretty fatal.
(Nothing call sbrk() from its SIGSEGV handler any more!)

	David

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