From: Andy Lutomirski <luto@amacapital.net> Date: 2021-03-08 19:01:09
On Mar 8, 2021, at 10:31 AM, Luck, Tony [off-list ref] wrote:
quoted
Can you point me at that SIGBUS code in a current kernel?
It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever get_user()
or copy from user variant was in use in the kernel when the poison memory was consumed.
if (p->mce_vaddr != (void __user *)-1l) {
force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
Hmm. On the one hand, no one has complained yet. On the other hand, hardware that supports this isn’t exactly common.
We may need some actual ABI design here. We also need to make sure that things like io_uring accesses or, more generally, anything using the use_mm / use_temporary_mm ends up either sending no signal or sending a signal to the right target.
Would it be any better if we used the BUS_MCEERR_AO code that goes into siginfo?
Dunno.
That would make it match up better with what happens when poison is found
asynchronously by the patrol scrubber. I.e. the semantics are:
AR: You just touched poison at this address and need to do something about that.
AO: Just letting you know that you have some poison at the address in siginfo.
-Tony
On Mon, 8 Mar 2021 11:00:28 -0800
Andy Lutomirski [off-list ref] wrote:
quoted
On Mar 8, 2021, at 10:31 AM, Luck, Tony [off-list ref] wrote:
quoted
Can you point me at that SIGBUS code in a current kernel?
It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever get_user()
or copy from user variant was in use in the kernel when the poison memory was consumed.
if (p->mce_vaddr != (void __user *)-1l) {
force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
Hmm. On the one hand, no one has complained yet. On the other hand, hardware that supports this isn’t exactly common.
We may need some actual ABI design here. We also need to make sure that things like io_uring accesses or, more generally, anything using the use_mm / use_temporary_mm ends up either sending no signal or sending a signal to the right target.
quoted
Would it be any better if we used the BUS_MCEERR_AO code that goes into siginfo?
Dunno.
I have one thought here but don't know if it's proper:
Previous patch use force_sig_mceerr to the user process for such a scenario; with this method
The SIGBUS can't be ignored as force_sig_mceerr() was designed to.
If the user process don't want this signal, will it set signal config to ignore?
Maybe we can use a send_sig_mceerr() instead of force_sig_mceerr(), if process want to
ignore the SIGBUS, then it will ignore that, or it can also process the SIGBUS?
--
Thanks!
Aili Yao
From: Andy Lutomirski <luto@amacapital.net> Date: 2021-03-11 01:29:01
On Wed, Mar 10, 2021 at 5:19 PM Aili Yao [off-list ref] wrote:
On Mon, 8 Mar 2021 11:00:28 -0800
Andy Lutomirski [off-list ref] wrote:
quoted
quoted
On Mar 8, 2021, at 10:31 AM, Luck, Tony [off-list ref] wrote:
quoted
Can you point me at that SIGBUS code in a current kernel?
It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever get_user()
or copy from user variant was in use in the kernel when the poison memory was consumed.
if (p->mce_vaddr != (void __user *)-1l) {
force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
Hmm. On the one hand, no one has complained yet. On the other hand, hardware that supports this isn’t exactly common.
We may need some actual ABI design here. We also need to make sure that things like io_uring accesses or, more generally, anything using the use_mm / use_temporary_mm ends up either sending no signal or sending a signal to the right target.
quoted
Would it be any better if we used the BUS_MCEERR_AO code that goes into siginfo?
Dunno.
I have one thought here but don't know if it's proper:
Previous patch use force_sig_mceerr to the user process for such a scenario; with this method
The SIGBUS can't be ignored as force_sig_mceerr() was designed to.
If the user process don't want this signal, will it set signal config to ignore?
Maybe we can use a send_sig_mceerr() instead of force_sig_mceerr(), if process want to
ignore the SIGBUS, then it will ignore that, or it can also process the SIGBUS?
I don't think the signal blocking mechanism makes sense for this.
Blocking a signal is for saying that, if another process sends the
signal (or an async event like ctrl-C), then the process doesn't want
it. Blocking doesn't block synchronous things like faults.
I think we need to at least fix the existing bug before we add more
signals. AFAICS the MCE_IN_KERNEL_COPYIN code is busted for kernel
threads.
--Andy
On Wed, 10 Mar 2021 17:28:12 -0800
Andy Lutomirski [off-list ref] wrote:
On Wed, Mar 10, 2021 at 5:19 PM Aili Yao [off-list ref] wrote:
quoted
On Mon, 8 Mar 2021 11:00:28 -0800
Andy Lutomirski [off-list ref] wrote:
quoted
quoted
On Mar 8, 2021, at 10:31 AM, Luck, Tony [off-list ref] wrote:
quoted
Can you point me at that SIGBUS code in a current kernel?
It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever get_user()
or copy from user variant was in use in the kernel when the poison memory was consumed.
if (p->mce_vaddr != (void __user *)-1l) {
force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
Hmm. On the one hand, no one has complained yet. On the other hand, hardware that supports this isn’t exactly common.
We may need some actual ABI design here. We also need to make sure that things like io_uring accesses or, more generally, anything using the use_mm / use_temporary_mm ends up either sending no signal or sending a signal to the right target.
quoted
Would it be any better if we used the BUS_MCEERR_AO code that goes into siginfo?
Dunno.
I have one thought here but don't know if it's proper:
Previous patch use force_sig_mceerr to the user process for such a scenario; with this method
The SIGBUS can't be ignored as force_sig_mceerr() was designed to.
If the user process don't want this signal, will it set signal config to ignore?
Maybe we can use a send_sig_mceerr() instead of force_sig_mceerr(), if process want to
ignore the SIGBUS, then it will ignore that, or it can also process the SIGBUS?
I don't think the signal blocking mechanism makes sense for this.
Blocking a signal is for saying that, if another process sends the
signal (or an async event like ctrl-C), then the process doesn't want
it. Blocking doesn't block synchronous things like faults.
I think we need to at least fix the existing bug before we add more
signals. AFAICS the MCE_IN_KERNEL_COPYIN code is busted for kernel
threads.
Got this, Thanks!
I read https://man7.org/linux/man-pages/man2/write.2.html, and it seems the write syscall is not expecting
an signal, maybe a specific error code for this scenario is enough.
--
Thanks!
Aili Yao