netdev - Re: [PATCH] vmalloc: Don't use flush flag when no exec perm

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: <89d6dee949e4418f0cca4cc6c4c9b526c1a5c497.camel@intel.com>
Date:   Thu, 30 May 2019 03:55:11 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "daniel@...earbox.net" <daniel@...earbox.net>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "ard.biesheuvel@....com" <ard.biesheuvel@....com>,
        "mroos@...ux.ee" <mroos@...ux.ee>,
        "will.deacon@....com" <will.deacon@....com>,
        "namit@...are.com" <namit@...are.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [PATCH] vmalloc: Don't use flush flag when no exec perm

On Tue, 2019-05-28 at 22:51 -0700, Rick Edgecombe wrote:
> The addition of VM_FLUSH_RESET_PERMS for BPF JIT allocations was
> bisected to prevent boot on an UltraSparc III machine. It was found
> that
> sometime shortly after the TLB flush this flag does on vfree of the
> BPF
> program, the machine hung. Further investigation showed that before
> any of
> the changes for this flag were introduced, with
> CONFIG_DEBUG_PAGEALLOC
> configured (which does a similar TLB flush of the vmalloc range on
> every vfree), this machine also hung shortly after the first vmalloc
> unmap/free.
> 
> So the evidence points to there being some existing issue with the
> vmalloc TLB flushes, but it's still unknown exactly why these hangs
> are
> happening on sparc. It is also unknown when someone with this
> hardware
> could resolve this, and in the meantime using this flag on it turns a
> lurking behavior into something that prevents boot.

The sparc TLB flush issue has been bisected and is being worked on now,
so hopefully we won't need this patch:
https://marc.info/?l=linux-sparc&m=155915694304118&w=2