linux-kernel - Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access.

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: <CALCETrXT9vGRT1S6Kk5ExfU+mW16rCY964r73ihRf5ZSh9H8jg@mail.gmail.com>
Date:   Fri, 26 Feb 2021 19:40:35 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Aili Yao <yaoaili@...gsoft.com>
Cc:     "Luck, Tony" <tony.luck@...el.com>,
        HORIGUCHI NAOYA( 堀口 直也) 
        <naoya.horiguchi@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        yangfeng1@...gsoft.com, Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for
 hwpoison page access.

On Wed, Feb 24, 2021 at 8:47 PM Aili Yao <yaoaili@...gsoft.com> wrote:
>
> On Tue, 23 Feb 2021 08:42:59 -0800
> "Luck, Tony" <tony.luck@...el.com> wrote:
>
> > On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote:
> > >
> > > > On Feb 23, 2021, at 4:44 AM, Aili Yao <yaoaili@...gsoft.com> wrote:
> > > >
> > > > On Fri, 5 Feb 2021 17:01:35 +0800
> > > > Aili Yao <yaoaili@...gsoft.com> 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 fixup_exception, current code will just return
> > > >> error code to user code.
> > > >>
> > > >> This is not sufficient, we should send a SIGBUS to the process and log
> > > >> the info to console, as we can't trust the process will handle the error
> > > >> correctly.
> > > >>
> > > >> Suggested-by: Feng Yang <yangfeng1@...gsoft.com>
> > > >> Signed-off-by: Aili Yao <yaoaili@...gsoft.com>
> > > >> ---
> > > >> arch/x86/mm/fault.c | 62 +++++++++++++++++++++++++++++----------------
> > > >> 1 file changed, 40 insertions(+), 22 deletions(-)
> > > >>
> > > > Hi luto;
> > > >  Is there any feedback?
> > >
> > > 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) syscalls.
> > So if the poison was in a user buffer passed to write(fd, buffer, count)
> > sending a SIGBUS would be the action if they read the poison directly,
> > so it seems reasonable to send the same signal if the kernel read their
> > poison for them.
> >
> > It would avoid users that didn't check the return value merrily proceeding
> > as if everything was ok.
>
> Hi luto:
>    I will add more infomation:
>    Even if the process will check return value of syscall like write, I don't think
> process will take proper action for this.
>    In test example, the return value will be errno is 14 (Bad Address), the process may not realize
> this is a hw issue, and may take wrong action not as expected.
>    And totally, A hw error will rarely happen, and the hw error hitting this branch will be
> more unlikely, the impaction without this patch is quite minor, but this is still not good enough, we should
> make it better, right?

There are a few issues I can imagine:

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.

It's worth making sure that this doesn't end up sending duplicate
signals.  If nothing else, this would impact the vsyscall emulation
code.

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 entirely valid to look at CR2 / si_fault_addr, fix it up, and
return.  This would be completely *invalid* with your patch.  I'm not
sure what to do about this.

--Andy