netdev - Re: bpf VM_FLUSH_RESET_PERMS breaks sparc64 boot

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

Message-ID: <a30b1eac-4a98-de52-e381-91a7a59f8042@linux.ee>
Date:   Tue, 14 May 2019 07:58:29 +0300
From:   Meelis Roos <mroos@...ux.ee>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "namit@...are.com" <namit@...are.com>
Subject: Re: bpf VM_FLUSH_RESET_PERMS breaks sparc64 boot

> I'm having trouble getting Debian Buster up and running on qemu-system-
> sparc64 and so haven't been able to reproduce. Is this currently working for
> people?

I just reinstalled the machine from
https://cdimage.debian.org/cdimage/ports/2019-05-09/debian-10.0-sparc64-NETINST-1.iso
and there's a even newer build upe one directory level.

> This patch involves re-setting memory permissions when freeing executable
> memory. It looks like Sparc64 Linux doesn't have support for the set_memory_()
> functions so that part shouldn't be changing anything. The main other thing that
> is changed here is always doing a TLB flush in vfree when the BPF JITs are
> freed. It will already sometimes happen so that shouldn't be too different
> either.

That part I do not know.

> So it doesn't seem extra especially likely to cause a sparc specific problem
> that I can see. Is there any chance this is an intermittent issue?

So far it seemed 100% reproducible, at least in the bisect that led here.
The only variation I saw was if it just sat there for newer git snapshot or spew
out RCU and workqueue lockup warnings soon like I posed.

I can do some tests and boot the same kernel some more times.

-- 
Meelis Roos