Linux page table isolation is not needed on AMD processors • Hacker News Board

Re: Linux page table isolation is not needed on AMD processors

#291

Post by dx034 » Thu, Jan 04, 2018, 4:39 PM UTC

zimmerfrei wrote: post #246

daenney wrote: post #157

Earlier quoted context omitted.

Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).

It depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap. Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution fo…

They knew of the issue since June. Now that the patches are out it'll be hard to regain the performance. I doubt they are able to issue a microcode update within the following months. Otherwise large clients such as AWS would have implemented that instead.

Re: Linux page table isolation is not needed on AMD processors

#292

Post by dx034 » Thu, Jan 04, 2018, 4:48 PM UTC

infinity0 wrote: post #248

sedachv wrote: post #105

Earlier quoted context omitted.

> We really need to stop shipping software as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution. What we really need to do is to start shipping all software as source code. This is exactly what JavaScript does, and why it is the most successful method of software distribution ever. WebAssembly is a huge step backward.

Most deployed JavaScript isn't source code.

What do you mean with that? All js I get via websites is source code. Often minified but that can easily be reversed.

Re: Linux page table isolation is not needed on AMD processors

#293

Post by Sir_Substance » Thu, Jan 04, 2018, 6:02 PM UTC

IgorPartola wrote: post #282

pdimitar wrote: post #269

Earlier quoted context omitted.

Not exactly but almost. I am saying this is the most likely outcome. Judging by other activities of the intelligence agencies and working with pure speculation -- not hiding from these words, you are correct by calling it that -- I still think it's much more likely they commissioned the Intel ME. You mention critical thinking in another comment. Critical thinking, the way I apply it, also requires a historical contex…

OK. And with that you are saying that you are basing this on 95% speculation and 5% pattern recognition with no direct evidence, and yet it's the most likely outcome. And I am saying that the confidence interval on that calculation is just orders of magnitude not tight enough. I am not denying that you could be right. It's just that I am giving that possibility something like a 1% chance of being true, while somethin…

>And I am saying that the confidence interval on that calculation is just orders of magnitude not tight enough.

You're also saying, implicitly, that therefore we must default to assuming it is incompetence.

That link isn't a given. Stating that it is incompetence is also speculation, not some kind of universal backup truth.

However, when it comes to that last 5%, I assert that the historical data does not back a claim that Intel's marketing department is incompetent.

Re: Linux page table isolation is not needed on AMD processors

#294

Post by int_19h » Fri, Jan 05, 2018, 2:06 AM UTC

api wrote: post #264

int_19h wrote: post #198

Earlier quoted context omitted.

Out of curiosity, which parts of .NET bytecode do you believe to be "too far abstracted from the hardware"? The object model, certainly, but you don't need to use that. On the other hand, the basic instruction set for arithmetic and pointers seems to be on the same abstraction level as WebAssembly to me.

So why can't I build C++ as .NET? Actually doing a big of searching I think you originally could but for some reason they removed it.

You can build C++ as .NET, absolutely. So far as I know, it can handle everything in the Standard except for setjmp/longjmp. All it takes is compiling with /clr:pure.

What you're referring to is probably C++/CLI, which wasn't removed, but it hasn't really been updated for a while. C++/CLI is a set of language extensions that make it possible to interface with the .NET object model.

If we go feature by feature, the .NET type system and bytecode has: - unsigned types - raw (non-GC) data pointers with pointer arithmetic - raw function pointers (distinct from delegates) - structs and unions - dynamic memory allocation on the stack (like alloca) - vararg functions

Re: Linux page table isolation is not needed on AMD processors

#295

Post by stefanfisk » Fri, Jan 05, 2018, 8:50 PM UTC

kev009 wrote: post #219

amluto wrote: post #62

Earlier quoted context omitted.

I think you're still misunderstanding. The CPU picks TTBR0 or TTBR1 based on the top significant bit of the VA, irrespective of whether the access was initiated by user or kernel code. This is in contrast to s390, which has separate page tables for user mode and kernel mode. I personally much prefer s390's model. And yes, I've read quite a few papers, and I wrote a good fraction of the patches.

I vaguely remember some threads from last decade where Linus trashed PowerPC and s390 TLBs. I wish I could find them and reread with this in mind.

are you thinking of this? http://yarchive.net/comp/powerpc_page_tables.html

Re: Linux page table isolation is not needed on AMD processors

#296

Post by arghwhat » Sat, Jan 06, 2018, 12:24 PM UTC

emj wrote: post #249

revelation wrote: post #141

Earlier quoted context omitted.

Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: DPDK for 10-100 Gbps networking: https://dpdk.org/ SPDK for NVMe storage: http://www.spdk.io/ The queuing and balancing stuff the kernel does makes sense for spinning rust harddisks and residential networking, but when the underlying hardware is so fas…

Taking control over network cards in user space seems doable nowdays. There was a talk about doing such drivers with IOMMU/DMA at CCC: https://media.ccc.de/v/34c3-9159-demystifying_network_cards

User-space drivers have been doable for a while, and dpdk[1] is definitely worth a check. There's also some manufacturers[2] that only does user-space drivers for their high-performance cards (e.g. 4x10Gb/s, 2x40Gb/s, 2x100Gb/s cards). Being designed with this in mind helps performance a lot.

1: https://dpdk.org/ 2: http://www.napatech.com/

Re: Linux page table isolation is not needed on AMD processors

#297

Post by arghwhat » Sat, Jan 06, 2018, 12:26 PM UTC

DSMan195276 wrote: post #263

revelation wrote: post #141

Earlier quoted context omitted.

Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: DPDK for 10-100 Gbps networking: https://dpdk.org/ SPDK for NVMe storage: http://www.spdk.io/ The queuing and balancing stuff the kernel does makes sense for spinning rust harddisks and residential networking, but when the underlying hardware is so fas…

> Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: I would personally think that is worse, though please correct me if I'm wrong. The userland driver will run with an isolated PT like any other userland process won't it? If so, it will suffer the same slowdown that every other process now has every-t…

A user-space driver doesn't communicate with the kernel. It is assigned DMA buffers, and communicates with the NIC solely through reading and writing to shared memory buffers.

Even before this fix, the benefits were massive, as sending a buffer was just writing to some memory, rather than syscalls and copies galore.

Re: Linux page table isolation is not needed on AMD processors

#298

Post by matzipan » Fri, Jan 12, 2018, 8:04 AM UTC

api wrote: post #36

At the meta level this is just a special case of "complexity is evil" in security. CPUs have been getting more and more complex, and the relationship between complexity and bugs (of all types) is exponential. Each new CPU feature exponentially increases the likelihood of errata. A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software…

While what you're saying sounds nice, your theory has nothing to do with practice.

In reality, the ultimate source of this problem is the mismatch in speed between silicon logic and silicon memory. This is why your CPU ends up doing all sorts of tricks like caching, branch prediction, speculative execution to compensate for slow memory.