On Thu, Mar 11, 2021 at 04:52:10PM +, Luck, Tony wrote:
> > 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.
>
> Can a kernel thread do get_user() or copy_from_user()? Do we have kernel
>
> 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.
Can a kernel thread do get_user() or copy_from_user()? Do we have kernel
threads
that have an associated user address space to copy from?
-Tony
On Wed, 10 Mar 2021 17:28:12 -0800
Andy Lutomirski wrote:
> On Wed, Mar 10, 2021 at 5:19 PM Aili Yao wrote:
> >
> > On Mon, 8 Mar 2021 11:00:28 -0800
> > Andy Lutomirski wrote:
> >
> > > > On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
> > > >
> > > >
> > > >>
> > > >> Can you point me
On Wed, Mar 10, 2021 at 5:19 PM Aili Yao wrote:
>
> On Mon, 8 Mar 2021 11:00:28 -0800
> Andy Lutomirski wrote:
>
> > > On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
> > >
> > >
> > >>
> > >> Can you point me at that SIGBUS code in a current kernel?
> > >
> > > It is in kill_me_maybe().
On Mon, 8 Mar 2021 11:00:28 -0800
Andy Lutomirski wrote:
> > On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
> >
> >
> >>
> >> 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()
> >
On Tue, 9 Mar 2021 10:14:52 +0800
Aili Yao wrote:
> On Mon, 8 Mar 2021 18:31:07 +
> "Luck, Tony" wrote:
>
> > > 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
On Mon, 8 Mar 2021 18:31:07 +
"Luck, Tony" wrote:
> > 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
>
> On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
>
>
>>
>> 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
> 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) {
> On Mar 8, 2021, at 1:49 AM, Aili Yao wrote:
>
> On Sun, 7 Mar 2021 11:16:24 -0800
> Andy Lutomirski wrote:
>
>>> Some programs may use read(2), write(2), etc as ways to check if
>>> memory is valid without getting a signal. They might not want
>>> signals, which means that
On Sun, 7 Mar 2021 11:16:24 -0800
Andy Lutomirski wrote:
> > > > >> Some programs may use read(2), write(2), etc as ways to check if
> > > > >> memory is valid without getting a signal. They might not want
> > > > >> signals, which means that this feature might need to be
> > > > >>
On Wed, Mar 3, 2021 at 4:51 AM Aili Yao wrote:
>
> On Wed, 3 Mar 2021 20:24:02 +0800
> Aili Yao wrote:
>
> > On Mon, 1 Mar 2021 11:09:36 -0800
> > Andy Lutomirski wrote:
> >
> > > > On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote:
> > > >
> > > >
> > > >>
> > > >> Some programs may use
On Mon, 1 Mar 2021 11:09:36 -0800
Andy Lutomirski wrote:
> > On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote:
> >
> >
> >>
> >> Some programs may use read(2), write(2), etc as ways to check if
> >> memory is valid without getting a signal. They might not want
> >> signals, which means that
On Wed, 3 Mar 2021 20:24:02 +0800
Aili Yao wrote:
> On Mon, 1 Mar 2021 11:09:36 -0800
> Andy Lutomirski wrote:
>
> > > On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote:
> > >
> > >
> > >>
> > >> Some programs may use read(2), write(2), etc as ways to check if
> > >> memory is valid
> On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote:
>
>
>>
>> Some programs may use read(2), write(2), etc as ways to check if
>> memory is valid without getting a signal. They might not want
>> signals, which means that this feature might need to be configurable.
>
> That sounds like an
> Some programs may use read(2), write(2), etc as ways to check if
> memory is valid without getting a signal. They might not want
> signals, which means that this feature might need to be configurable.
That sounds like an appalling hack. If users need such a mechanism
we should create some
> Programs that get a signal might expect that the RIP that the signal
> frame points to is the instruction that caused the signal and that the
> instruction faulted without side effects. For SIGSEGV, I would be
> especially nervous about this. Maybe SIGBUS is safer. For SIGSEGV,
> it's
Hi Luto:
> > > > At the very least, this needs a clear explanation of why your proposed
> > > > behavior is better than the existing behavior.
> > >
> > > The explanation is buried in that "can't trust the process" line.
> > >
> > > E.g. user space isn't good about checking for failed write(2)
On Wed, Feb 24, 2021 at 8:47 PM Aili Yao wrote:
>
> On Tue, 23 Feb 2021 08:42:59 -0800
> "Luck, Tony" wrote:
>
> > On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote:
> > >
> > > > On Feb 23, 2021, at 4:44 AM, Aili Yao wrote:
> > > >
> > > > On Fri, 5 Feb 2021 17:01:35 +0800
> > >
On Tue, 23 Feb 2021 08:42:59 -0800
"Luck, Tony" wrote:
> On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote:
> >
> > > On Feb 23, 2021, at 4:44 AM, Aili Yao wrote:
> > >
> > > On Fri, 5 Feb 2021 17:01:35 +0800
> > > Aili Yao wrote:
> > >
> > >> When one page is already
On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote:
>
> > On Feb 23, 2021, at 4:44 AM, Aili Yao wrote:
> >
> > On Fri, 5 Feb 2021 17:01:35 +0800
> > Aili Yao wrote:
> >
> >> When one page is already hwpoisoned by MCE AO action, processes may not
> >> be killed, processes mapping
> On Feb 23, 2021, at 4:44 AM, Aili Yao wrote:
>
> On Fri, 5 Feb 2021 17:01:35 +0800
> Aili Yao wrote:
>
>> When one page is already hwpoisoned by MCE AO action, processes may not
>> be killed, processes mapping this page may make a syscall include this
>> page and result to trigger a
On Fri, 5 Feb 2021 17:01:35 +0800
Aili Yao wrote:
> When one page is already hwpoisoned by MCE AO action, processes may not
> be killed, processes mapping this page may make a syscall include this
> page and result to trigger a VM_FAULT_HWPOISON fault, as it's in kernel
> mode it may be fixed by
When one page is already hwpoisoned by MCE AO action, processes may not
be killed, processes mapping this page may make a syscall include this
page and result to trigger a VM_FAULT_HWPOISON fault, as it's in kernel
mode it may be fixed by fixup_exception, current code will just return
error code
24 matches
Mail list logo
