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: <CALCETrWFXgOtFYycpY7A5Z1yM2oiZwP4sRh4e7Rfu32N85Kxig@mail.gmail.com>
Date:   Sun, 7 Mar 2021 11:16:24 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Aili Yao <yaoaili@...gsoft.com>
Cc:     "Luck, Tony" <tony.luck@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        HORIGUCHI NAOYA <naoya.horiguchi@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        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, Mar 3, 2021 at 4:51 AM Aili Yao <yaoaili@...gsoft.com> wrote:
>
> On Wed, 3 Mar 2021 20:24:02 +0800
> Aili Yao <yaoaili@...gsoft.com> wrote:
>
> > On Mon, 1 Mar 2021 11:09:36 -0800
> > Andy Lutomirski <luto@...capital.net> wrote:
> >
> > > > On Mar 1, 2021, at 11:02 AM, Luck, Tony <tony.luck@...el.com> 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 appalling hack. If users need such a mechanism
> > > > we should create some better way to do that.
> > > >
> > >
> > > Appalling hack or not, it works. So, if we’re going to send a signal to user code that looks like it originated from a bina fide architectural recoverable fault, it needs to be recoverable.  A load from a failed NVDIMM page is such a fault. A *kernel* load is not. So we need to distinguish it somehow.
> >
> > Sorry for my previous mis-understanding, and i have some questions:
> > if programs use read,write to check if if memory is valid, does it really want to cover the poison case?

I don't know.

> > When for such a case, an error is returned,  can the program realize it's hwposion issue not other software error and process correctly?

Again, I don't know.  But changing the API like this seems potentialy
dangerous and needs to be done with care.

> >
> > if this is the proper action, the original posion flow in current code from read and write need to change too.
> >
>
> Sorry, another question:
>   When programs use read(2), write(2) as ways to check if memory is valid, does it really want to check if the user page the program provided is valid, not the destination or disk space valid?

They may well be trying to see if their memory is valid.

>   the patch will not affect this purpose as it's only valid for user page which program provide to write or some syscall similiar parameter
>
> --
> Thanks!
> Aili Yao



-- 
Andy Lutomirski
AMA Capital Management, LLC