linux-kernel - Re: [PATCH 2/7] x86,tlb: leave lazy TLB mode at page table free time

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: <CALCETrWhb4CU8BfjdYBe+QJ8CVa4pzAr3ME+HBe4=6y=Pi9pFQ@mail.gmail.com>
Date:   Wed, 15 Aug 2018 18:54:42 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Rik van Riel <riel@...riel.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Andrew Lutomirski <luto@...nel.org>,
        Mike Galbraith <efault@....de>,
        kernel-team <kernel-team@...com>, Ingo Molnar <mingo@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: [PATCH 2/7] x86,tlb: leave lazy TLB mode at page table free time

On Mon, Jul 16, 2018 at 12:03 PM, Rik van Riel <riel@...riel.com> wrote:
> Andy discovered that speculative memory accesses while in lazy
> TLB mode can crash a system, when a CPU tries to dereference a
> speculative access using memory contents that used to be valid
> page table memory, but have since been reused for something else
> and point into la-la land.

Hi Rik-

I was looking through this, and I see:

> -static void tlb_remove_table_one(void *table)
> +static void tlb_remove_table_one(void *table, struct mmu_gather *tlb)
>  {
>         /*
>          * This isn't an RCU grace period and hence the page-tables cannot be
> @@ -344,7 +348,7 @@ static void tlb_remove_table_one(void *table)
>          * It is however sufficient for software page-table walkers that rely on
>          * IRQ disabling. See the comment near struct mmu_table_batch.
>          */
> -       smp_call_function(tlb_remove_table_smp_sync, NULL, 1);
> +       smp_call_function(tlb_remove_table_smp_sync, tlb->mm, 1);
>         __tlb_remove_table(table);
>  }

But tlb_remove_table() doesn't always call tlb_remove_table_one().  Do
the other paths through tlb_remove_table() do the right thing?

--Andy