Schubfach, Ryū, Dragonbox etc support round-tripping and shortest-width, which (it sounds like) is not important for you. The idea of round-tripping is that if you convert a double to a string and then parse that, you get the exact same value. Shortest-width is to correctly round and generate the shortest possible text. I tried to implement a version that does _just_ round-tripping but is not shortest-width, it is around 290 lines for both parsing and toString [1]
They're different problem spaces, TrustZone is a trusted execution environment and TPM is an API for performing key storage and attestation which revolves around system state (PCRs).
Essentially, TPM is a standardized API for implementing a few primitives over the state of PCRs. Fundamentally, TPM is just the ability to say "encrypt and store this blob in a way that it can only be recovered if all of these values were sent in the right order," or "sign this challenge with an attestation that can only be provided if these values match." You can use a TEE to implement a TPM and on most modern x86 systems (fTPM) this is how it is done anyway.
You don't really need an fTPM either in some sense; one could use TEE primitives to write a trusted application that should perform similar tasks, however, TPM provides the API by which most early-boot systems (UEFI) provide their measurements, so it's the easiest way to do system attestation on commodity hardware.
Sure, why not? You have a reference implementation for both TrustZone OP-TEE (from Microsoft!) and in-Linux-kernel. No need to code anything, everything is already there, tested and ready to work.
As I understand it, you can not actually deploy a fTPM (in embedded and other scenarios) unless you run your own full PKI and have your CA signed off by Microsoft or some other TPM consortium member. So sure the code exists, but it's also just a dummy implementation, and for any embedded product that is not super cost conscious I will forever recommend to just buy the $1 chip, connect it via SPI and live happily ever after. Check the box, in embedded most non-technical people can't even begin to understand what FDE means anyway.
If you don't need the TPM checkbox, most vendors have simple signing fuses that are a lot easier than going fTPM.
Well, you have much more control of lower-level boot process on ARM chips, and each of the SoC manufacturers have their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.
In context of trusted boot — not much. If your specific application doesn't require TPM 2.0 advanced features, like separate NVRAM and different locality levels, then it's not worth to use dedicated chip.
However if you want something like PIN brute force protection with a cooldown on a separate chip, dTPM will do that. This is more or less exactly why Apple, Google and other major players have separate chip for most sensitive stuff—to prevent security bypasses when the attacker gained code execution (or some kind of reset) on the application processor.
> their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.
TPM and x86 trusted boot / root of trust are completely separate things, linked _only_ by the provision of measurements from the (_presumed_!) good firmware to the TPM.
x86 trusted boot relies on the same SoC manufacturer type stuff as in ARM land, starting with a fused public key hash; on AMD it's driven by the PSP (which is ARM!) and on Intel it's a mix of TXE and the ME.
This is a common mistake and very important to point out because using TPM alone on x86 doesn't prove anything; unless you _also_ have a root of trust, an attacker could just be feeding the "right" hashes to the TPM and you'd never know better.
On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM.
You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (as the only method), for which you can implement trusted boot, using TPM and all the previous measures proprietary code made to it.
You can do that on x86 too, the main difference is a combination of openness and who you need to sign an NDA with (which, granted, is a big difference, since most ARM vendors are more likely to be your friend than Intel). However, there are a ton of x86 based arcade machines, automotive systems, and so on which have secured root of trust and do not use UEFI at all. On Intel, you get unprovisioned chips and burn your KM hash into the PCH FPFs to advance the lifecycle state at EOM, which is basically the same thing you'd do with most ARM SoCs.
I cracked into many x86-based arcade machines (and non-arcade gambling machines), and none of them used anything really bespoke. I never seen non-BIOS/UEFI x86 system in my life.
Not going to say they are non-existent, but probably the only mention of not using UEFI on Intel chips was in the presentation of Linux optimization for automotive from Intel itself, where they booted Linux in 2 seconds from the cold boot.
I've seen the Intel bare-metal stuff in enough automotive products to call it extant in the wild; I've only heard of it being used in video arcade stuff so maybe I was misinformed there.
Anyway, I think we're both on the same page regardless that TPM and hardware root of trust are not the same thing. In some configurations TPM can (weakly) attest that the hardware root of trust is present, but it doesn't actually do any hardware trust root, and that looks architecturally very similar on x86 to how it looks anywhere else (mask ROM verifies a second bootloader against RTL or manufacturing fused chipmaker public key hash, second bootloader measures subsequent material against OEM fused key hash, and so it goes).
I think the general problem is that SoC-based security relies on internal "fuses" that are write-once, as the name suggests, which usually means that they are usable by the manufacturer only.
TPMs can be reprogrammed by the customer. If the device needs to be returned for repairs, the customer can remove their TPM, so that even the manufacturer cannot crack open the box and have access to their secrets.
That's only theory though, as the box could actually be "dirty" inside; for instance it could leak the secrets to obtained from the TPM to mass storage via a swap partition (I don't think they are common in embedded systems, though).
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.
>V8 emits a near-jump for all forward jumps. If the target ends up too far away, the near-jump target is adjusted to a jump pool entry that contains a long-jump to the actual target
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?
Sounds like it's probably emitting the machine code in a single pass (compilation speed matters for a browser JIT), perhaps even together in a single pass with lowering (so don't even know the amount of instructions beforehand), and for such adjusting things afterwards would mean parsing & rewriting bytecode, and adjusting already-hardcoded backwards jump distances.
Maybe they benchmarked it and processors are so good at predicting the indirection, it doesn't matter much. In out-of-order processors there is a lot of untapped potential. As an example, Rust inserts bounds checks almost for free.
They only want the screen for the stereo and backup camera, not anything else. It's easier to update a car from 2004 say to have Android Auto than to fix one made in 2024 that doesn't have it. $400 aftermarket stereo from crutchfield..
I would say that 2005 was peak car, except 2000 is slightly better because they had not yet gone nuts with serialized components.
(another reason is that direct inject fuel injection hadn't taken over yet, it's a disaster)
So this link is interesting for a different reason: look at the references at the end of the paper. It's awesome that the references include URLs. IMHO, old papers should all be updated to include such hyperlinks.
I'm pleased that the references to other ACM papers do work.
But try to click on this one:
Bainbridge, L. 1983. Ironies of automation. Automatica 19(6): 775-779;
Fail! No way to read the paper without paying or pirating by using scihub (and even if you do get the .pdf via scihub, its references are not hyperlinks). This does not help humanity, it makes us look like morons. FFS, even the music industry was able to figure this out.
Shell sort is sooo much faster than Bubble sort for tiny microcontrollers, for only a little bit more flash memory, like 40-100 bytes. If that's too much, then Insertion sort is 6X faster than Bubble sort, for only 10-20 bytes of extra flash.
I'll say this about IBM: because it's so old, it was the most diverse company I ever worked for- including age, nationality, race, sex, and any other category you can think of. Basically you had all types of people in all stages of life, not just young white workaholic tech-bros. The founders are long gone, so everyone there (including CEO) is a professional- meaning nobody has any kind of personal attachment to the company. We were all in the same boat, as it were. When your older coworker suddenly disappears due to a stroke, it puts things in perspective.
The fast-paced startup is really the hack, combining the energy of youth with the ego-mania of their founders. Ask yourself, is it healthy?
Anyway, IBM's customers tend to be other fortune 100s and governments- basically other similar organizations, and my experience was that we took care of them pretty well. The products were not pretty (no Steve Jobs-like person to enforce beauty), and rather complex due to all the enterprise requirements. But they were quite high quality, particularly the hardware.
The awe induced when standing in front of a brand new, kitted out x95 frame with all its drawers full and that special shade of IBM blue on everything is definitely something. Pull out the HMC and just think about how many decades of R&D and experience and tears went into the entire system.
https://github.com/nklabs/libnklabs/blob/main/src/nkprintf_f... https://github.com/nklabs/libnklabs/blob/main/src/nkstrtod.c https://github.com/nklabs/libnklabs/blob/main/src/nkdectab.c
nkprintf_fp.c+nkdectab.c: 2494 bytes
schubfach.cc: 10K bytes.. the code is small, but there is a giant table of numbers. Also this is just dtoa, not a full printf formatter.
OTOH, the old code is not round-trip accurate.
Russ Cox should make a C version of his code..
reply