Factorio Forums

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/
https://www.phoronix.com/scan.php?page= ... ming-Tests
I wonder how much this affect to Factorio after apply the patch.

On the one hand, it's not supposed to affect gaming at all. On the other... Go AMD.

Well, i won't go to AMD because it has terrible performance in Factorio compared to Intel (tested myself).

All the performance effects will only be due during system calls.

Where before (a large part of) the kernel could stay mapped into the application's address space, with this vulnerability it has to be unmapped and remapped every system call.

Dont worry, factorio developer will do another bugfix patch in a few hours that will solve the intel problem increases CPU speed 5% to 30%.

Eaggra wrote:increases CPU speed 50% to 300%.

FTFY

The flaw exists in AMD and even ARM (and therefore mobile phones) as well and they will need the same OS workaround: https://googleprojectzero.blogspot.de/2 ... -side.html

WTF?! 5-30% performance drop?! Lets just hope its nothing factorio relay on.

.

there are two different exploits, meltdown and spectre. First is the one that seems to only affect intel stuff and can be "fixed" with a kernel patch.

The other one exists on pretty much all CPUs that have speculative execution so anything from amd-intel in past 10y+ and a few newer arm things. That one can not be patched neither via microcode nor OS level patches.
A ton of info + whitepapers about the two flaws:
https://spectreattack.com/

[edit]

For regular people that bug isn't really *that* much of an issue. It requires to have the attacking code run on your machine and generally when you have a virus in your machine you're screwed either way already. Though it is possible to probe around the memory space of some browsers (seemingly chrome based ones) and see what information you have/are typing in other tabs but that can be worked around via changing the browser settings.

For organizations that rent out cloud services/virtual machines, this will be a massive problem as one could just rent some VM time from them and run a code in it that has access to memory of not only the hardware host but also the memory of other virtual machines running on same physical hardware. I can't really imagine how to deal with that kind of problem. Hypothetically, one could probably encrypt the entire memory of their OS/virtual machines but that'll be a massive speed penalty

hoho wrote:[edit]

For regular people that bug isn't really *that* much of an issue. It requires to have the attacking code run on your machine and generally when you have a virus in your machine you're screwed either way already. Though it is possible to probe around the memory space of some browsers (seemingly chrome based ones) and see what information you have/are typing in other tabs but that can be worked around via changing the browser settings.

For organizations that rent out cloud services/virtual machines, this will be a massive problem as one could just rent some VM time from them and run a code in it that has access to memory of not only the hardware host but also the memory of other virtual machines running on same physical hardware. I can't really imagine how to deal with that kind of problem. Hypothetically, one could probably encrypt the entire memory of their OS/virtual machines but that'll be a massive speed penalty

Thought a bit about it...


Wouldn't it be possible to prevent speculative execution for syscall instructions (and similar)?

That would stall the pipeline from prefetching Kernelmode memory into the cache until the usermode application is finished doing whatever it does. If such a speculative branch isn't taken then the Kernel space stuff can't leak to the usermode application since it was never prefetched to the cache. All the attacking application could then safely read from cache is only its own history.

Something along the order could probably be done with call gates (and alike)... the CPU should hypothetically know that accessing a specific memory location requires a privilege level change... and if that happens then also prevent further speculative execution (and with that prefetching sensitive memory locations to the cache) until everything to that point is resolved.

Of course it would slow down process of switching between privilege levels but at least it would maintain process seperation. It's the most secure handover I can think of.

But then again I only barely remember most of the CPU concepts back from my studying years ever since I completely moved away from Electonics Engineering and IT to do something entirely different unrelated to it.


As for what happens within the same application... well I don't know about that.


[edit]
Seems like Torvalds basically suggested what I did already yesterday:
https://lkml.org/lkml/2018/1/3/797

MeduSalem wrote:Wouldn't it be possible to prevent speculative execution for syscall instructions (and similar)?

From what I understand, CPU itself has no clue if an instruction is called by kernel or some other piece of code so it has to be controlled on the OS-side. If I understood the patches made to fix Meltdown properly, they do disable speculative execution for the duration of the kernel call + dump kernel stuff from memory/caches after the call is complete.

Loewchen wrote:The flaw exists in AMD and even ARM (and therefore mobile phones) as well and they will need the same OS workaround: https://googleprojectzero.blogspot.de/2 ... -side.html

There's two different vulnerabilities, Meltdown is the one that affects all Intel chips and some of ARM, is also the most damaging since that one allows unprivileged access to all kernel memory. Spectre affects all vendors but is more limited to the aplication's memory and the fix is more trivial.

m44v wrote: and the fix is more trivial.

Is it, really? Most of the reports on it I've heard so far have said it's next to impossible to fix with patches and CPUs have to be changed on hardware level to get rid of it.

hoho wrote:From what I understand, CPU itself has no clue if an instruction is called by kernel or some other piece of code so it has to be controlled on the OS-side. If I understood the patches made to fix Meltdown properly, they do disable speculative execution for the duration of the kernel call + dump kernel stuff from memory/caches after the call is complete.

Actually the CPU knows if instructions are run in Kernel Mode or User Mode (or Hypervisor mode for systems with Virtualization capability or additional protection rings if the CPU architecture supports it), because there are several instructions that can only be legally performed if it is set to a specific mode, in that case Kernel Mode.

Like for example in x86 that would be Local/Global Descriptor Table updates, Task Register Updates, certain Control Register Updates, several Debug Instructions, and other such things.



And what the Meltdown fix does is effectively hide certain Kernel space memory that had previously been mapped into User Space.

OS developers usually mapped even some Read/Write protected Kernel Space memory into User Space memory to spare themselves to have to switch to Kernel Mode or to make the transition between User and Kernel mode go a lot faster. Switching to Kernel Mode is usually a costly action so you want to avoid having to do that or at least reduce its impact.

Usually mapping protected Kernel Space Memory to User Space Memory isn't much of a problem because if the Page Table is set correctly it prevents the User Space process from reading/writing on these memory locations even if they are mapped into its own space. You would have to switch to Kernel mode to eventually access them.

With Intel CPUs shit hits the fan when their Out-of-Order and with it Speculative Execution doesn't check the Page Table on legality for its speculatively performed memory accesses to said read/write-protected Kernel Space that is mapped into User Mode memory.

And that is what Meltdown is exploiting... they are getting the speculative execution to read on protected Kernel memory because they know it doesn't perform the necessary page table security checks during speculative execution. For the speculation the TLB just translates the virtual address to a physical one in a dumb-but-fast approach no matter if it is actually allowed to access that location or not. The CPU only realizes there is something wrong in terms that the usermode process actually doesn't have the privilege to read on the locations once the instructions are non-speculative and are really committed and the TLB does its accurate check on the page table... but at that point it's already too late. The User mode Process has gathered information from Kernel Space locations it shouldn't have, even if the Out-of-Order execution engine then invalidates all actions and backrolls everything. The Kernel memory information is already in the cache then and seems like it can be extracted via a sidechannel by the user mode application even after backrolling because the cache isn't cleared along with the pipeline.

The meltdown fix is basically a "You can't leak, what doesn't exist" approach, by changing the OS so that it doesn't map those critical Kernel Space memory locations to User Space anymore. Now it has to enter Kernel Mode to act on them. Now it only maps the bare minimum of Kernel Space memory to User Space memory so that the application gets the necessary interfaces so it can work as intended and nothing more. But that in return is what causes performance loss due to more work that has to be done in Kernel Mode.



The Spectre thing though where a thread of the own process might read on shared memory space it shouldn't read.. is really fubar. While browsers might alleviate the issue with some unprecise timing to prevent effectively using the sidechannel attack... I don't know if that can be really done in every application out there.

hoho wrote:Is it, really? Most of the reports on it I've heard so far have said it's next to impossible to fix with patches and CPUs have to be changed on hardware level to get rid of it.

No. Meltdown is an Intel specific problem which has a fix, but unfortunately the impact of that fix can lead to massive loss of performance.

Spectre is a class of attacks which can be executed on most processors from Intel, AMD and ARM. It has no single clear fix and can be executed by malicious software, such as e.g. Javascript running in the browser. Because it is a whole class of attacks, it is not entirely clear yet what it can impact, but it has been demonstrated to be able to dump memory from the browser executing it.

Caine wrote:

hoho wrote:Is it, really? Most of the reports on it I've heard so far have said it's next to impossible to fix with patches and CPUs have to be changed on hardware level to get rid of it.

No. Meltdown is an Intel specific problem which has a fix

I said pretty much exactly that. I was talking about if there is a fix for Spectre as the person I quoted seemed to indicate

Caine wrote:but unfortunately the impact of that fix can lead to massive loss of performance.

Not really, unless all you do is run synthetic benchmarks of file system or rely heavily on databases. For normal usage (e.g games), the performance impact is small enough to not effectively be there.

hoho wrote: I said pretty much exactly that. I was talking about if there is a fix for Spectre as the person I quoted seemed to indicate

I might have misunderstood when I read about it. I checked again and indeed spectre is actually not simple to fix in general, perhaps it meant the fix for specific and known attacks.