netdev - Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?)

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, 23 Jul 2018 23:34:05 +0300 (EEST)
From:   Meelis Roos <mroos@...ux.ee>
To:     Daniel Borkmann <daniel@...earbox.net>
cc:     Arnd Bergmann <arnd@...db.de>,
        Linux Kernel list <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?)

> >> Now this seems more relevant:
> >>
> >> mroos@...00s2:~/linux$ nice git bisect good
> >> 24dea04767e6e5175f4750770281b0c17ac6a2fb is the first bad commit
> >> commit 24dea04767e6e5175f4750770281b0c17ac6a2fb
> >> Author: Daniel Borkmann <daniel@...earbox.net>
> >> Date:   Fri May 4 01:08:23 2018 +0200
> >>
> >>     bpf, x32: remove ld_abs/ld_ind
> >>
> >>     Since LD_ABS/LD_IND instructions are now removed from the core and
> >>     reimplemented through a combination of inlined BPF instructions and
> >>     a slow-path helper, we can get rid of the complexity from x32 JIT.
> > 
> > This does seem much more likely than the previous bisection, given
> > that you ended up in an x86-32 specific commit (the subject says x32,
> > but that is a mistake). I also checked that systemd indeed does
> > call into bpf in a number of places, possibly for the journald socket.
> > 
> > OTOH, it's still hard to tell how that commit can have ended up
> > corrupting the clock read function in systemd. To cross-check,
> > could you try reverting that commit on the latest kernel and see
> > if it still works?
> 
> I would be curious as well about that whether revert would make it
> work. What's the value of sysctl net.core.bpf_jit_enable ? Does it
> change anything if you set it to 0 (only interpreter) or 1 (JIT
> enabled). Seems a bit strange to me that bisect ended at this commit
> given the issue you have. The JIT itself was also new in this window
> fwiw. In any case some more debug info would be great to have.

net.core.bpf_jit_enable is 1.

Since it breaks bootup, I can not easily change the value at runtime (it 
would be postfactum). Do you mean changing the 
CONFIG_BPF_JIT_ALWAYS_ON=y option?

Anyway, I started compile of v4.18-rc5 that was the latest I tested, 
with the commit in question reverted. Will see if I can test tomorrow 
morning. But I will leave tomorrow for a week and can only test further 
things if they happen to boot fine (no manual reboot possible for a 
week).

-- 
Meelis Roos (mroos@...ux.ee)