The man page ld.so has ENVIRONMENT section that looks pretty good.
Otherwise one of the most reliable options is to simply grep the source code for calls to getenv, I would not be that surprised if their are some extra ones that are undocumented.
Please just buy a proper differential probe for stuff like this, you definitely don't need the R&SRT-ZHD mentioned in the article. Otherwise loved the article btw.
Their have been many vulnerabilities in TrustZone implementations and both Google and Apple now use separate secure element chips. In Apple's case they put the secure element as part of their main SoC, but on devices where that wasn't designed in house like Intel they had the T2 Security Chip. On all Pixel devices I'm pretty sure the Titan has been a separate chip (at least since they started including it at all).
So yes incorporating a separate secure element\TPM chip into a design is probably more secure, but ultimately the right call will always depend on your threat model.
Here's an excerpt about the anti-rollback feature from Nvidia's docs on how the Tegra X1 SoC in the switch 1 boots [0] (called Tegra210 in the document)
> By default, the boot ROM will only consider bootloader entries with a version field that matches the version field of the first entry, and will stop iterating through the entries is a mismatch is found. The intent is to ensure that if some subset of the bootloader entries are upgraded, and hence the version field of their entries is modified, then the boot ROM will only boot the most recent version of the bootloader. This prevents an accidental rollback to an earlier version of the bootloader in the face of boot memory read errors, corruption, or tampering. Observe that this relies on upgraded bootloader entries being placed contiguously at the start of the array.
It isn't that wild; the typical name for it is anti-rollback, and you probably have at least one device that implements it. Most Android devices have anti-rollback efuses to prevent installing older versions of the bootchain\bootloader; they might still allow you to downgrade the OS (depends on the vendor, if memory serves). Instead of using efuse counters, anti-rollback counters can also be implemented by Replay Protected Memory Block (RPMB), which is implemented by many flash storage (eMMC often supports RPMB, but other storage types can as well). It is possible to implement anti-rollback mechanisms on x86_64 by utilizing a TPM [0], but as far as I know, only Chrome OS does this.
It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
> The only thing I'm not sure about is why they decided to reopen it.
It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
That would make sense, since they would then need support for JXL for the embedded PDF viewer anyway. Unless they want it to choke on valid PDFs that include JXL images.
I see! Thanks for pointing out this very interesting correlation. So we got something better only because someone else equally influential forced their hand. Otherwise the users be damned, for all they care, it seems.
I have been relentlessly shilling JPEG-XL's technological superiority especially against their joke of an alternative and a stain on the Internet they call WebP
I designed WebP lossless alone. The rest of the WebP folks added a RIFF header and an artificial size limitation (16383x16383) to match with the size limitation of lossy WebP.
In JPEG XL I believe I had more influence on the lossy ("VarDCT") format than anyone else, but stayed relatively far from the lossless part (except the delta palette, two predictors, 2d lz-codes, and a few other smaller things). I believe Jon and Luca had most influence there.
"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?
Pebble watches run on Cortex-M microcontrollers which have less than 1MB of flash storage and RAM, I like Kotlin multiplatform but getting it to run on them is extremely unlikely. I assume that for the foreseeable future Pebble apps will be only written in languages which are traditionally used for MCUs like Rust and C\C++
Calling rust traditional is a bit of a stretch, while it is being done it's pretty much bleeding edge (though if you do not use any of the manufacturer supplied code and libraries to begin with you should be fine).
It is honestly refreshing to see constraints like this again.
In my cloud infrastructure work (C++), we have gotten lazy. We bloat our containers because 'RAM is cheap'. Seeing a system designed to fit into 1MB reminds me that performance engineering used to be about efficiency, not just throwing more hardware at the problem.
I find this a little funny because as a firmware engineer the project I regularly work on only has 512kb of flash. This doesn't stop sales from constent new feature requests.
Embedded is definitely a fun balance of what we could do and how much we can do.
Otherwise one of the most reliable options is to simply grep the source code for calls to getenv, I would not be that surprised if their are some extra ones that are undocumented.
reply