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]

Date:   Mon, 8 Mar 2021 11:00:28 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     "Luck, Tony" <tony.luck@...el.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Linux API <linux-api@...r.kernel.org>
Cc:     Aili Yao <yaoaili@...gsoft.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 Mar 8, 2021, at 10:31 AM, Luck, Tony <tony.luck@...el.com> 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 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