It feels like the concept faded with the advent of large VRAM and fast fill rate graphics accelerators. I remember old X Window System workstations supporting multiple concurrent windows with different color depths and modes. The hardware would compose windows from memory during display scan-out, all to save VRAM.
Color depths, not modes per se, and it's more that XFree86/X.Org by virtue of being lowest common denominator didn't have optimizations based on it, and over time GTK and others forgot they exist.
Some systems like Xsgi went further with having several visuals used for predefined purposes in their modified Motif versions
I used X11 on some 8-bit framebuffers back in the day, and I remember the palette changing depending on which window was in the foreground. The foreground window would have proper colour, and the background ones would generally have crazy clashing colours.
Then you take an illegal instruction exception, and you have a choice to request a rebuild, patch it, or emulate it. (Yeah, sometimes the vendors just don't cooperate.)
Incidentally, emulating opcodes is quite often practical (unless the performance must not be affected), and is greatly helped by having the plainest, cleanest instruction encoding possible, and a well designed system register & exception architecture.
One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support.
Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).
Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms.
Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way.
It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.
I, too, had wondered; this seems particularly common in the US. My best theory is that in rough handwriting, n and u/μ can look pretty similar, and everyone sort of agreed to only use u to reduce ambiguity.
Another way to reduce ambiguity is to omit the suffix (unless it's p for picofarads) and let it be deduced from the numbers and symbols.
47 -> 47nF (if next to plain double bar symbol with no polarity markings)
47 -> 47μF (if next to polarized cap symbol)
0.47 -> 0.47μF
47p -> 47pF
10np -> np -> nonpolar -> electrolytic -> 10μF
I heard this, and have witnessed it. One of my first jobs included board rework. There were several times when I had to go ask if they wrote a uF or an nF. The response was always "obviously a uF", because nobody uses nF!
Nobody uses nF in, say, digital, where the only caps are power supply filter caps and bypass/decoupling caps next to ICs.
It's not customary to call a 0.1μF bypass cap 100 nF.
If someone wrote in 100 nF for a decoupling cap, I would tend suspect they are trying to discourage a substitution like 82nF or 150nF and want to find out why.
Whereas if it is 0.1μF, I know we can stick in a 0.2μF, if that's what we have on hand, and everything will be fine.
It always feels a bit like lost magic. But at the same time, it's also something that was only enabled by the very high determinism of these old home systems. The design relies on having fixed RAM locations, no multiprocessing, etc.
Incredible to find out that typing the paper program would not have worked, though. And in such a disappointing way no less.
On an Apple ][, you couldn’t necessarily assume your BASIC code was going to start from the same location, thanks to the LOMEM command. I remember one of the things I wrote back in the day was a relocatable Assembly loader that would allow a bit of assembly code to be loaded to an arbitrary address in available memory and all the internal addresses (for, e.g., JSR or JMP or even some LD* commands, as I recall) would be rewritten to the correct location. I don’t really want to go back to writing code for 8-bit computers, but the challenges were certainly fun.
I sometimes wonder if there is still a lot of that magic in the tech world, but were so used to having everything abstracted away from us in multiple layers that we've lost the ability to look for it.
I think about the TLA hackers who do seemingly impossible things. Surely they must operate on this level.
I work in "lowest level" kernel development, and we're certainly operating at that layer. As for those kind of hacky solutions, we do try to avoid them, because they are, well, hacky, and therefore often hard to understand, easy to break, etc... but it does happen. Especially in prototyping, were usually anything goes to make something work initially.
Because I started in that era, I sometimes think that’s why I was motivated to learn synthetic programming for the HP 41, write the first disassembler for the HP 48SX’s ROM, why I wrote jailbreak software on the iPhone before the App Store existed. Tiny limited environments most resemble where I first coded.
reply