linux-kernel - Re: [PATCH v1] mm, pagemap: expose hwpoison entry

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: <YWi+HRiXju7NEkbX@t490s>
Date:   Fri, 15 Oct 2021 07:32:45 +0800
From:   Peter Xu <peterx@...hat.com>
To:     Naoya Horiguchi <naoya.horiguchi@...ux.dev>
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        Alistair Popple <apopple@...dia.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Konstantin Khlebnikov <koct9i@...il.com>,
        Bin Wang <wangbin224@...wei.com>,
        Naoya Horiguchi <naoya.horiguchi@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm, pagemap: expose hwpoison entry

On Thu, Oct 14, 2021 at 10:36:44PM +0900, Naoya Horiguchi wrote:
> Thanks for the good question, this could trigger WARN for unpoisoned pages.
> The impact is limited because the caller of unpoison should know that that
> happens in testing workload, but maybe there's no good reason to prevent
> from it. So I'll drop this WARN_ON().

Sounds good, thanks.

> > I had a feeling that when handling the page fault in do_swap_page before we
> > SIGBUS the program, we should double-check the PageHWPoison on the pfn page,
> > but I could be missing something..
> 
> The double-checking seems to allow processes to detect that the hwpoison page
> is unpoisoned, some test programs could benefit from it. But maybe it could
> be done independent of this patch.
> 
> Personally, I only use unpoison in cleanup phase of each test case,
> and each test case newly starts test processes, so reusing error pages
> with unpoison can be avoided.

I see.  We don't have anything like soft-online a page, do we?

I also don't know whether hwpoison can be used in any other form besides
testing the hwpoison code path.  E.g. logically it can be used to forbid
accessing a physical page for any reason then recover using unhwpoison?

Uffd has the SIGBUS mode that can do similar thing to the virtual address
space, so any access to some page will generate a SIGBUS. While hwpoison is
phsical address space based from that pov, and just like uffd it doesn't need
to change vma layout which should be a good property unlike mprotect().  But I
totally have no clue on all these... so it's just wild idea.

Anyway, agreed on above, even if it's applicable it should be a separate patch.

Thanks,

-- 
Peter Xu