linux-kernel - Re: [PATCH V2] mm: Recheck page table entry with page table lock held

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>] [day] [month] [year] [list]

Date:   Mon, 28 Oct 2019 15:08:25 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     "Figo.zhang" <figo1802@...il.com>
Cc:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2] mm: Recheck page table entry with page table lock held

On Fri, Oct 25, 2019 at 11:13:58AM +0800, Figo.zhang wrote:
> Aneesh Kumar K.V <aneesh.kumar@...ux.ibm.com> 于2018年9月26日周三 上午11:19写道：
> 
> > We clear the pte temporarily during read/modify/write update of the pte.
> > If we
> > take a page fault while the pte is cleared, the application can get
> > SIGBUS. One
> > such case is with remap_pfn_range without a backing vm_ops->fault callback.
> > do_fault will return SIGBUS in that case.
> >
> what is " remap_pfn_range without a backing vm_ops->fault callback ", would
> you like  elaborate the scenario?
>  is it the case using remap_pfn_range()  in drivers mmap() file operations?
> if in that case, why it will trap into do_fault?

Because there's no page mapped there during the race.

> >
> > cpu 0                                           cpu1
> > mprotect()
> > ptep_modify_prot_start()/pte cleared.
> > .
> > .                                               page fault.
> > .
> > .
> > prep_modify_prot_commit()
> 
> 
>   i am confusing this  scenario, when CPU0 will call
> in change_pte_range()->ptep_modify_prot_start() to clear the pte content,
> and
> on the other thread, in handle_pte_fault(), pte_offset_map() can get the
> pte, and the pte is not invalid, it's pte is valid but just the content is
> all zero, so why it will call into do_fault?
> 
> in  handle_pte_fault():
>     vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
>     if (!vmf->pte) {
>             return do_fault(vmf);
>     }

This case handles the situation when pte is none (clear) or page table is
not allocated at all.

-- 
 Kirill A. Shutemov