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.
I'd like to add that no light source can lie outside the horseshoe of the CIE xyz diagram: pure wavelengths are points on the curved line, everything that mixes them moves towards the inside of the space. So you're stuck with triangles that fit within it.
If you lay a yardstick from fully desaturated white to maximum perceivable green, you’re effectively seeing #119911 even if you’re looking at a green quantum dot #00ff00 LED, because the color green can also be seen by your eye’s non-green receptors a little bit too.
The green in ProPhoto RGB is shown at a ‘distance’ from the other colors that’s impossible for human photoreceptors to perceive (let’s say it’s #00bb00), because there’s no way to trigger our green receptors at such a severe distance from white — they can’t differentiate greens beyond #009900 — without our perception also mixing in some of the other colors (result: #119911) due to those receptors being analog-curve-blended rather than sharp single-frequency cutouts like quantum dot, sodium lights, or laser emission spectra. So no matter how strong a green you emit in reality, it can never reach when perceived the depth of green that ProPhoto RGB represents, because the eye can’t perceive #00bb00 green as being different from #009900 green, and it can’t perceive any intensity of green as #00gg00 rather than #11gg11 without optical illusions or other fun tricks like shooting your green ‘M’ receptors with pinpoint laser beams: https://news.ycombinator.com/item?id=43741013
So, the upside of having three overlapping curves is that we can distinguish different shades of similar colors with much higher accuracy, but the downside is that we cannot see undiluted green or blue. Human tetrachromats, theorized to have a fourth receptor at +/-yellow, would in theory be able to differentiate colors even more strongly, peaking at that +/-yellow versus red/green; but, perhaps, they might(?) lose a bit of the ‘imaginary’ three neon CMY colors that we synthesize from that overlap (for example #ffff00), in exchange for gaining six? new ones (#00ff00ff?). I need to consider 4-D rhodopsin interactions for longer than this comment’s edit window to be more certain of that implication :)
DxO created a wide color space a while back that they fit better to human receptor sensitivity than ProPhoto, and while I’m not qualified to judge whether it’s Better or Worse, their explanation of how they constructed it around Pointer’s Gamut — someone sampled actual real world objects to see what the strongest colors we can see in earthly reality are! — provides some very precise images showing ‘the strongest color distances we can find from white on real life objects’ versus ‘the strongest color distances from white that sRGB and ProPhoto RGB can represent’:
This post also does help explain in depth why having ‘impossible’ color spaces is helpful for digital processing: It lets you manipulate photos without color truncation (do your intermediate math in double-float), and then when you’re ready to ‘land’ the photo back into reality — either on sRGB, or Dosplay P3, or HDR10, or Kodak film negatives — you can control how that inevitable rounding-off of the impossible colors occurs (store the final result in half-float). Do you want to prioritize eye-searing color or preserve the fine gradients of hue, in your photo of a flower petal? There is no single correct answer, but if you do your work in ProPhoto, you’ll have the option to preserve those gradients (or to convert them to luminosity gradients!) that you would lose if you’d done your work in a more limited colorspace.
Hex code nitpicks: Colorspace pros, I acknowledge that RGB hex codes are wildly incorrect to use here, not the least of which because they encode luminosity and hue when I’m just using them as hue above, but also because they’re wildly incorrect to mix with modern color spaces. This is done solely for analogy purposes and supports the curiosity basis of colorspaces 101; those who wish to learn more are welcome to — and join us in being grumpy about web hex codes and colorspaces :D
Well, it's complicated. As I understand, one of the polio vaccines - the oral one - has an unusual quirk.
The live virus used in it can reproduce and spread in low-vaccination communities. While the vaccine version of it will not cause paralysis, it can and occasionally does mutate back into a pathogenic variant.
So we're sort of maintaining a reservoir of polio, really.
Hopefully though we will slowly wean off the live vaccine. For the most part the live vaccine is only used in developing countries. There are a bunch of factors that make that difficult but i think eventually we will get there.
Imagine a power splitter + phase shifter that produces a correct phase shift for each element in a phased array to produce a directional beam from one radio transceiver.
Now this clever arrangement, instead of having only one radio transceiver port, has multiple. And each of those ports corresponds to a different set of phase shifts, producing a directional beam at a different azimuth angle.
And because this is an entirely passive device, it's linear, and all ports can be active at the same time (principle of superposition essentially). So you can use a single phased antenna array to serve multiple directional beams at the same time.
Right! I think a lot of people, who have not done a lot of "things you can kick" engineering, have a very romantic view of it. Especially the relationship with whoever is nominally setting the goals of the project.
The physics works perfectly, of course. But physics is only a third of the constraint in engineering. The other two thirds are project goals and convention.
Project goals are horribly underspecified, every time. It's incredibly rare to be given a project that is completely constrained on that side, and if you do get one, most of the time it's physically impossible to achieve. This is because the people who write those specifications not doing engineering, they're doing marketing or sales or just had a cool idea. Sometimes that can even be the engineer themselves :-) So it's up to the engineer to fill in the gap, and they do it with experience and a sense of aesthetics, of sorts.
Convention is what constrains the physical possibilities of engineering to the practical. Yes, you can build anything and make it work, possibly even better than what everyone else builds. But you will have to invent and construct a lot of new technologies before you can build your perfect mousetrap. So, you settle on standard components and build a decent one instead. But this introduces a gap between physics and engineering, too. A bit of no-man's land that you can reach into to produce truly great results. But it's up to the engineer to know when it's worth it.
reply