[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1czud6krk.fsf@fess.ebiederm.org>
Date: Thu, 29 Apr 2021 12:52:31 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Liam Howlett <liam.howlett@...cle.com>
Cc: Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Julien Grall <julien.grall@....com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
"bpf\@vger.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn() sometime returns the wrong signals
This entire discussion seems to come down to what are the expected
semantics of arm64_notify_segfault. The use of this helper in
swp_handler and user_cache_main_handler is clearly for the purposes of
instruction emulation. With instruction emulation it is a bug if the
emulated instruction behaves differently than a real instruction in
the same circumstances.
To properly fix the instruction emulation in arm64_notify_segfault it
looks to me that the proper solution is to call __do_page_fault or
handle_mm_fault the way do_page_fault does and them parse the VM_FAULT
code for which signal to generate.
I would probably rename arm64_notify_segfault to arm64_emulate_fault, or
possibly arm64_notify_fault while fixing the emulation so that it
can return different signals and so that people don't have to guess
what the function is supposed to do.
For the specific case of sigreturn and rt_sigreturn it looks sufficient
to use the fixed arm64_notify_segfault. As it appears the that the code
is attempting to act like it is emulating an instruction that does not
exist.
There is an argument that sigreturn and rt_sigreturn do a poor enough
job of acting like the fault was caused by an instruction, as well
as failing for other reasons it might make more sense to just have
sigreturn and rt_sigreturn call "force_sig(SIGSEGV);" But that seems
out of scope of what you are trying to fix right now so I would not
worry about it.
Eric
Powered by blists - more mailing lists