[WIP] chromium: update to 89.0.4389.72

[pullmoll]

CVE-2021-21166

• x86_64 patch set updated, built, tested very cursory and seems to work
• i686 patch applies w/o change, built, cursory test in a VM
• x86_64-musl patch set updated, built, works but can crash, see comments below
• system opus disabled because the generated shim header opus.h tries to include <opus.h> and fails
• not sure if libc_malloc.patch is ok, i.e. simply use malloc() instead of __libc_malloc().
• more to do

[ci skip]

If you don't want to build yourself my repo has the update for testing.

[pullmoll]

Not sure if the x86_64-musl syscall crash is because of me already using musl-1.2.2.
I'll check to see what syscall 0324 is and what to do about it.

I suppose it's 324 __NR_membarrier and not 0324 (octal) as printed in the crash log.

Edit: I need to partially restore the sandbox-membarrier.patch. The #if !defined(_NR_membarrier) are now in the headers while the case _NR_membarrier: is missing in syscall_sets.cc.

[ericonr]

Do you have it in your repository for musl? The current version doesn't crash on musl 1.2.1, at least. I haven't updated to 1.2.2 because it breaks Firefox seccomp (Firefox needs to be built for musl 1.2.2), so it could perhaps be the same situation.

[pullmoll]

@ericonr You can get it from https://repo.voidlinux.de/binpkgs/chromium-89.0.4389.72_1.x86_64-musl.xbps already, the x86_64-musl/... is not yet updated because a lot of live/... files are before that.
But see above. I think I removed an important part of a patch that failed.
I'll rebuild x86_64-musl with that.

[pullmoll]

Updated: patches/sandbox-membarrier.patch now just adds the case _NR_membarrier: line and I'm rebuilding x86_64-musl now.

Status update: x86_64-musl does not immediately crash but soon after when viewing a website:
libva error: vaGetDriverByNameIndex() failed with unknown libva error, driver name = (null)
https://voidlinux.org/ shows and does not crash... this requires further investigation :-(

[q66]

why are you removing patches that apply? (e.g. no-getcontext.patch, the libc_malloc.patch should probably stay as well, etc)

xxx-ppc64le-support.patch just needs a trivial 5-minute rebase so idk why you're removing it https://gist.github.com/q66/3b7ec52349d4d7390456e3f10726b38f (but i did it myself since i don't trust anyone else not to mess it up)

you'll find that xxx-ppc64le-support.patch in musl patches then applies cleanly, without removing any of it (i.e. revert your changes to it)

[pullmoll]

@q66 This is WIP and I didn't claim it was finished. You're welcome to help or, if you so desire, take over what I started :-P Took your updated xxx-ppc64le-musl.patch and restored the one in musl-patches...

Oh, and the previous libc_malloc.patch does not compile.

[q66]

well I'm not expecting it to be finished, i'm just saying the patches tend to depend on each other, so by making patches later in the sequence apply after removing patches earlier in the sequence is just wasting your time (and may result in bugs being introduced by accident)