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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ