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
