On 2024/03/11 17:32, Laurence Tratt wrote:
> On Mon, Mar 11, 2024 at 11:14:44AM -0600, Theo de Raadt wrote:
>
> Hello Theo,
>
> > With a bit of effort, the address you see:
> >
> > addr=0x67cb1d220
> >
> > can be compared in the ktrace to earlier mmap() operations (done by the
> > shared library linker ld.so); those mmap are mappings against a file
> > descriptor,
> > and you can see what library file ld.so opened just previously... then we
> > know
> > what library still has a BTI issue.
>
> I will admit to being absolute clueless with kdump output. I'm happy to try
> if someone can give me some hints, but equally if someone wants to look at
> the dump, I'm happy to send them on for analysis.
I've had a look at this, but there's nothing relevant in kdump output
matching close to that address.
$ kdump|grep -E '0x67[0-9a-f]{7}'
69377 chrome CALL unveil(0x674f4c86b,0x674ee7079)
69377 chrome CALL pledge(0x674e59cbb,0)
69377 chrome PSIG SIGILL SIG_DFL code=ILL_BTCFI addr=0x67cb1d220 trapno=21
Educated guess: chromium uses its own bundled copy of aom (AV1 codec;
AFAIK it uses dav1d to _de_code AV1 but that's a decoder only, so
there's a good chance it uses aom to _en_code) which doesn't have
patches for IBT. So I think there's a good chance it's that.
