On 2024/03/12 17:20, Stuart Henderson wrote:
> 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.

I've managed to get this working with an external webcam - video(4)
seems broken with the internal cams on T14G3. chromium build uses nasm
not yasm so we can go with the simple version of the definition.

I've just started a build with the diff, hopefully will be able to
test runtime tomorrow.


Index: Makefile
===================================================================
RCS file: /cvs/ports/www/chromium/Makefile,v
diff -u -p -r1.772 Makefile
--- Makefile	6 Mar 2024 12:30:17 -0000	1.772
+++ Makefile	12 Mar 2024 17:46:27 -0000
@@ -10,6 +10,7 @@ DPB_PROPERTIES+=	lonesome
 COMMENT=		Chromium browser
 
 V=			122.0.6261.111
+REVISION=		0
 
 DISTNAME=		chromium-${V}
 
Index: patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
===================================================================
RCS file: patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
diff -N patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ patches/patch-third_party_libaom_source_libaom_third_party_x86inc_x86inc_asm	12 Mar 2024 17:46:27 -0000
@@ -0,0 +1,24 @@
+Index: third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm
+--- third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm.orig
++++ third_party/libaom/source/libaom/third_party/x86inc/x86inc.asm
+@@ -66,6 +66,12 @@
+     %endif
+ %endif
+ 
++%if AOM_ARCH_X86_64
++    %define _CET_ENDBR endbr64
++%else
++    %define _CET_ENDBR
++%endif
++
+ %define FORMAT_ELF 0
+ %define FORMAT_MACHO 0
+ %ifidn __OUTPUT_FORMAT__,elf
+@@ -860,6 +866,7 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
+     %endif
+     align function_align
+     %2:
++    _CET_ENDBR
+     RESET_MM_PERMUTATION        ; needed for x86-64, also makes disassembly somewhat nicer
+     %xdefine rstk rsp           ; copy of the original stack pointer, used when greater alignment than the known stack alignment is required
+     %assign stack_offset 0      ; stack pointer offset relative to the return address