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]
Date: Sun, 4 Feb 2024 11:03:15 +0000
From: Jiaxun Yang <jiaxun.yang@...goat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Oleg Nesterov <oleg@...hat.com>,
 Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Ben Hutchings <ben@...adent.org.uk>, linux-arch@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
 linux-mm@...ck.org, Xi Ruoyao <xry111@...111.site>
Subject: Re: [PATCH v2 0/3] Handle delay slot for extable lookup



在 2024/2/4 07:41, Linus Torvalds 写道:
[...]
> The thing is, the only reason for the code in
> get_mmap_lock_carefully() is for kernel bugs. IOW, some kernel bug
> with a wild pointer, and we do not want to deadlock on the mm
> semaphore, we want to get back to the fault handler and it should
> report an oops.
>
> ... and one of the "wild pointers" might in fact be the instruction
> pointer, in case we've branched through a NULL function pointer or
> similar. IOW, the exception *source* might be the instruction pointer
> itself.

Well this is the tricky part of my assumption.
In `exception_epc()` `__isa_exception_epc()` stuff is only called if we 
are in delay slot.
It is impossible for a invalid instruction_pointer to be considered as 
"in delay slot"
by hardware.

I'd agree that sounds fragile though.

Thanks
>
> So I realy think that MIPS needs to have some kind of "safe kernel
> exception pointer" helper. One that is guaranteed not to fault when
> evaluating the exception pointer.
>
> Assuming the kernel itself is never built with MIPS16e instructions,
> maybe that's a safe assumption thanks to the "get_isa16_mode()" check
> of EPC. But all of this makes me nervous.
>
>                Linus

-- 
---
Jiaxun Yang


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ