03:19 <hanetzer> so, about panwrap. is there any info on the general technique?

03:20 <hanetzer> I'm working on some ip cores that have blob kmods and blob userspace libs (in a sane world they'd be v4l2 devices) so I don't even have the courtesy of vendorware kernel module source.

05:19 <robclark> general technique is LD_PRELOAD ;-)

08:07 <jenneron[m]> alyssa: hi, i'm thinking that i can ask alpine maintainers to carry the patch to enable t628 in mesa, so it'd work in postmarketOS on peach-pit and peach-pi chromebooks. i want to know your opinion about this, since it may cause users to report T628 issues to upstream mesa which could be annoying i guess

09:46 <jenneron[m]> also, I got access to hardware, I don't see xorg issues which I have been reported about

10:11 <hanetzer> robclark: I mean crafting the LD_PRELOAD'd lib

10:30 <icecream95> hanetzer: You could just read the panwrap source, panwrap-syscall.c is only about 250 LOC

11:03 <icecream95> The first three CSF instructions from a Free userspace have been run!

11:04 <icecream95> Now to fix the bugs and see if I get something more impressive than 'mov x72, #0x1234'

11:07 <icecream95> "GPU ID: v10.8 r6p7 (Mali-G710)." I was *sure* that it would be 0xa002, not 0xa867

11:08 <robmur01> r6p7 is definitely not right ;)

11:10 <icecream95> robmur01: Blame kbase for sticking a wrong value in the KBASE_GPUPROP_PRODUCT_ID field then

11:10 <icecream95> Unless they've changed the field format again

11:14 <hanetzer> icecream95: yeah, that actually looks fairly simple. but here's a question; what about hooking small internal helper functions in the library? for example, this lib has a public facing api, but internally uses JPEG_HDEC_{ReadReg,WriteReg,Cpy2Mem,Cpy2Regs} to do a lot of the 'real work'. These are never meant to be called by the end user, and even if you did, well, you don't know the

11:14 <hanetzer> magic regs and such

11:16 <hanetzer> so, instead of hooking the public JPG_HDEC_DecodeJpg or so I'd like to hook the func it calls from the above list, to trace those.

11:19 <icecream95> If you just want to dump arguments and don't mind if the function breaks, I guess you could dlsym the functions, mprotect to gain write access, and stick in some instructions to jump to your own function

11:20 <icecream95> If you consider disassembling the first one or two instructions in a function to not be "binary r/e", you could then make your own function do what they did and jump back

11:21 <icecream95> Recently I've found Valgrind to be a very powerful tool for instrumentation: When you get a BB, check if the address matches the function you want to trace, then insert a call to an external function and do whatever you want

11:23 <icecream95> "Coherency mode: 0x1f (None)" :(

11:26 <icecream95> The stream feature mask here is 0x7085f, and the "global interface version" is 0x1010000

11:26 <icecream95> I guess the feature mask is like the texture features register, a mask of natively-supported commands to run on iterators?

11:27 <hanetzer> valgrind on arm is pain, never got it to work lmao

11:27 <robmur01> icecream95: the revision isn't part of the product ID though? At least we have separate properties for them in Mesa :/

11:29 <icecream95> So that would be 0-4, 6, 11, 16-18 if zero-based, which seems wrong. It must have some other meaning then

11:33 <icecream95> robmur01: mali_kbase_gpu_id.h confuses me, but it appears ARCH_REV == 6 and PRODUCT_MAJOR == 7 at least

11:34 <hanetzer> also this jpeg decoder is funny. the userspace lib is almost entirely jpeg6b with the hw stuff tacked on (they provide both a shared and static library, so listing the object files in the latter helped determine that)

11:34 <icecream95> Which seems correct because PRODUCT_MAJOR == 7 is LODX

11:34 <icecream95> I was confused because the blob prints that it wants 0xa002 in a debug message

11:36 <robmur01> 7 should be G610

11:36 <robmur01> but wither way it's unrelated to rXpY, so whoever's printing that is just wrong

11:36 <icecream95> Okay, I'll fix that code then

11:38 <icecream95> hanetzer: Is this ARMv7 or AArch64? I remember having problems with Valgrind but I think that was 32-bit ARM, while it's been very reliable on 64-bit, except for missing a couple of dc instructions

11:40 <hanetzer> icecream95: armv7, cortex-a7 specifically.

11:40 <hanetzer> but yeah. if I'm reading the kmod in ghidra right, it doesn't *do* much except handle interrupts

11:44 <robmur01> FWIW I don't imagine ARCH_MINOR and ARCH_REV are of much interest

11:51 <hanetzer> yeh until the revbump it for some hw errata :P

11:57 <robmur01> nah, that's what the VERSION_* fields are for

11:59 <hanetzer> https://binaryresearch.github.io/2019/08/29/A-Technique-for-Hooking-Internal-Functions-of-Dynamically-Linked-ELF-Binaries.html this actually looks like a pretty viable technique

21:33 <icecream95> Hmm, the stream feature mask has register definitions in kbase

21:34 <icecream95> G610 has a register count of 0x5f, so "mov x96, #0xf00" and possibly "mov x95, #0x00f" should fault, I think

21:38 <daniels> hanetzer: it wasn't great on A7, but a lot of things weren't great 15 years ago

21:41 <hanetzer> true, but I'm also limited to using uclibc because that's all the vendor 'provided' (read: got lucky and found it on the internet)