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.