06:23 <drath42> zapb__: Trace decoding requires access to memory content in some cases, so currently I'm thinking that trace decoding belongs inside the debugger.

06:33 <borneoa_> drath42: zapb__: CSAL has some info about the coresight components, so probably something that could go in openocd code. OpenCSD looks like pure trace decoding, maybe better suited for a stand alone tool. All requires further investigation.

06:45 <drath42> borneoa_: I'm currently working on getting a PoC trace chain working on an i.MX 8M Plus: A53 #0 ETM -> trace funnel -> trace replicator -> trace fifo -> trace memory controller -> DDR. That's what CSAL is concerned with, but right now I'm attempting to configure the whole chain manually.

06:47 <drath42> borneoa_: I've already used OpenCSD as a standalone tool in the past to decode traces collected on TI AM65x hardware, but IIRC this thing /is/ a library, and the standalone tool is only meant as a sample.

06:49 <drath42> borneoa_: I believe one of technical reasons is that for the generic use case you NEED the ability to read target memory to decode the trace. You can get away with an ELF file if that covers all of the executed code, but if you're looking at more complex setups (the ones I'm interested in) you wont necessarily have a binary file describing all executable memory.

11:41 <borneoa_> drath42: but you will still use the elf for the symbols, so somehow you need to know how stuff is mapped in memory. For parsing Linux traces you need to know where modules are loaded. For userland, there is all the relocation of trampolines for libraries. Not trivial. No idea how all this can be done nor how to simplify it

13:07 <milkylainen> borneoa_: Hi. People in stm32 pointed to you. The stm32 wiki has several errors. Seems documents are left in some strange state. https://wiki.st.com/stm32mpu/wiki/How_to_secure_STM32_MPU for example

13:07 <milkylainen> There are lots of other documents looking like that.

13:07 <milkylainen> Gotta run.

16:21 <borneoa_> milkylainen: hi, that page is under review and has not been approved for publication yet. Did you end up there while following some link inside the same wiki?

17:29 <PaulFertser> borneoa_: yes, let me paste more of his messages

17:30 <PaulFertser> borneoa_: https://paste.debian.net/hidden/f6085e9e/

18:44 <borneoa_> PaulFertser: thanks

18:46 <borneoa_> milkylainen: few days ago was uploaded the wiki content version 4.x.y. the previous versions are still available through the main page

18:49 <borneoa_> milkylainen: but the page you point doesn't look as present in old wiki, and in new one is not approved for publication

19:20 <milkylainen> borneoa_: Confusing. I just reloaded an URL I previously had open and noticed that some pages wouldn't display. I did notice that contents had changed. But why release a wiki version set if a bunch of links are not approved for publication yet?

19:21 <milkylainen> Confusing UI experience. :)

20:02 <milkylainen> borneoa_: do you know what the stm32mp1x actually needs hashed before creating the signature for the fsbl? The wiki image indicates a sha256 hash over data + header with public key... but the signature is inside the header?

20:10 <borneoa_> milkylainen: I never tried to sign the fsbl and close the device. Let me check...

20:24 <milkylainen> borneoa_: Thing is, I'm looking to maybe fix stm32image so it can sign the fsbl.

20:25 <milkylainen> borneoa_: But the documentation only seem to point to the "cube programmer" tool directory.

20:29 <borneoa_> milkylainen: yes, the cube programmer is considered as the simpler method to secure the chip, program otp and, I expect, also sign the fsbl . Nevertheless there will be "soon" documentation on how to run "manually" each step

20:31 <milkylainen> borneoa_: Mm. A few pointers in the process would be nice. That way I can fix stm32image and get it into a resonable build process with signing.

20:31 <borneoa_> milkylainen: by the way, is this activity linked to some company? Or personal hobby? I ask this to understand if I can push the support team

20:34 <borneoa_> milkylainen: if I remember correctly, it was a design decision to keep build and signing tasks separate. Usually two independent teams get involved, the company keys are not widely distributed to the dev

20:35 <milkylainen> borneoa_: company.

20:37 <milkylainen> An assignment. I work for a company with my own Linux solution where I try to consolidate several embedded security and functional things over various platforms.

20:39 <milkylainen> So a small Linux running guest softwares, both emulated and not. A 3gpp configuration, fault and performance management interface and security solutions in the middle layer (guests are using security solutions without inventing their own). Plus a lot of other things.

20:39 <milkylainen> We took this stm32mp1 assignment.

20:39 <milkylainen> For a customer.

20:43 <borneoa_> milkylainen: ok

20:44 <milkylainen> So. Learning the stm32mp1 boot solutions and fixing it for the customer. :)

21:41 <zapb__> drath42, what kind of information do you need from the target?