linux-kernel - Re: [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery

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: <20210723001436.GA1460637@agluck-desk2.amr.corp.intel.com>
Date:   Thu, 22 Jul 2021 17:14:36 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Jue Wang <juew@...gle.com>
Cc:     Borislav Petkov <bp@...en8.de>, dinghui@...gfor.com.cn,
        huangcun@...gfor.com.cn, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        HORIGUCHI NAOYA(堀口 直也) 
        <naoya.horiguchi@....com>, Oscar Salvador <osalvador@...e.de>,
        x86 <x86@...nel.org>, "Song, Youquan" <youquan.song@...el.com>
Subject: Re: [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user
 recovery

On Thu, Jul 22, 2021 at 04:30:44PM -0700, Jue Wang wrote:
> I think the challenge being the uncorrectable errors are essentially
> random. It's
> just a matter of time for >1 UC errors to show up in sequential kernel accesses.
> 
> It's easy to create such cases with artificial error injections.
> 
> I suspect we want to design this part of the kernel to be able to handle generic
> cases?

Remember that:
1) These errors are all in application memory
2) We reset the count every time we get into the task_work function that
   will return to user

So the multiple error scenario here is one where we hit errors
on different user pages on a single trip into the kernel.

Hitting the same page is easy. The kernel has places where it
can hit poison with page faults disabled, and it then enables
page faults and retries the same access, and hits poison again.

I'm not aware of, nor expecting to find, places where the kernel
tries to access user address A and hits poison, and then tries to
access user address B (without returrning to user between access
A and access B).

-Tony