linux-kernel - Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB 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]

Date:   Mon, 6 Nov 2017 13:27:26 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Bob Liu <lliubbo@...il.com>, Will Deacon <will.deacon@....com>
Cc:     Wang Nan <wangnan0@...wei.com>, Linux-MM <linux-mm@...ck.org>,
        Linux-Kernel <linux-kernel@...r.kernel.org>,
        Bob Liu <liubo95@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>,
        Ingo Molnar <mingo@...nel.org>, Roman Gushchin <guro@...com>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking
 TLB entry

On Mon 06-11-17 09:52:51, Michal Hocko wrote:
> On Mon 06-11-17 15:04:40, Bob Liu wrote:
> > On Mon, Nov 6, 2017 at 11:36 AM, Wang Nan <wangnan0@...wei.com> wrote:
> > > tlb_gather_mmu(&tlb, mm, 0, -1) means gathering all virtual memory space.
> > > In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush
> > > TLB when tlb->fullmm is true:
> > >
> > >   commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
> > >
> > 
> > CC'ed Will Deacon.
> > 
> > > Which makes leaking of tlb entries. For example, when oom_reaper
> > > selects a task and reaps its virtual memory space, another thread
> > > in this task group may still running on another core and access
> > > these already freed memory through tlb entries.
> 
> No threads should be running in userspace by the time the reaper gets to
> unmap their address space. So the only potential case is they are
> accessing the user memory from the kernel when we should fault and we
> have MMF_UNSTABLE to cause a SIGBUS.

I hope we have clarified that the tasks are not running in userspace at
the time of reaping. I am still wondering whether this is real from the
kernel space via copy_{from,to}_user. Is it possible we won't fault?
I am not sure I understand what "Given that the ASID allocator will
never re-allocate a dirty ASID" means exactly. Will, could you clarify
please?
-- 
Michal Hocko
SUSE Labs