23 comments

[ 4.1 ms ] story [ 35.6 ms ] thread
Prepare for a new set of exploits affecting every major OS except Linux [1] involving SYSRET to a non-canonical address.

[1] Linux may get a free pass because I'm going to insist on a specific test case for this issue.

I wonder if Intel would be willing to change the behaviour to be the same as AMD.
(comment deleted)
I wonder who asked for this? While 640k might not be enough for everyone, 256 terabytes of directly addressable memory seems, suffient to requirements.
But 256 terabytes of disk might not be enough and, if you want to address your disk like it's RAM, you need more address space.
Yeah, I had thought in terms of fancy new kinds of NVRAM, but mmap'ing lots of existing storage (or a mix) is a legit use case sooner.
One reading of this is that Intel wants some future arch to be able to address huge amounts of NVRAM as if it were RAM.
Of course they do. If their X-Point stuff (or something like it) ever ships, they will want to put a couple or three terabytes of NVmemory on the otherside of the frontside bus. If you can do that you can enable some really amazing systems architectures. Things like a web search engine that consumes less than a 100W when it isn't serving a request because it can 'wake from sleep' and answer a query in under 10mS. And it can reboot in just the few seconds needed to change out the RAM parts of memory and pick up the giant data structure with the web index already loaded.
Fun fact: physical addresses will still have at most 52 bits, despite linear address space having up to 57.
For garbage collectors and other things you really want a randomly selected number to only infrequently be a valid address.
How often do garbage collectors look at physical addresses?
... You're right, physical address bits are totally irrelevant and I was confused.
And that is a huge improvement from the old 40 bit limit, and then the 42 bit limit. In fact it is over 1000x better than the 52 bit limit :-)
I'm guessing this is tradeoff of practical vs possible?
The third paragraph of the first page states:

"Virtual-machine monitors (VMMs) use the virtual-machine extensions (VMX) to support guest software operating in a virtual machine. VMX transitions are control flow transfers between the VMM and guest software"

Can anyone explain what "control flow transfers" are?

Is this just referring to a per VM context of a core's control path? Kind of context switch of sorts to to another VM?

In this context "control flow transfer" refers to the CPU transitioning between executing VMM code and guest code.
~144 petabytes 128 pebibytes