Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

Post reply on HN
Print view View original

241–250 of 264 posts

Re: The mysterious case of the Linux Page Table Isolation patches

#241

Post by ifore »

JJJollyjim wrote: post #239
TheSwordsman wrote: post #211

One question I have around this is whether the patches made to the Windows kernel in November exhibit the same performance hits. Does anyone know? I'm due to refresh my gaming PC, and I was going to go with Intel again as they've not been a problem. However, if Intel chips are going to incur the same 5% - 50% performance hit on Windows, I might end up investing in AMD hardware instead.

I'm certainly no expert, but I would guess that the context-switch time (where I believe the new overhead is added) in games is fairly small compared to the raw number-crunching in-process, so the effect would be minimal in any case

I would have thought that would have been a lot of context switching with graphics driver calls

(Or maybe they already do as much as possible in userspace and then batch kernel calls?)

Re: The mysterious case of the Linux Page Table Isolation patches

#242

Post by caf »

amluto wrote: post #233
JdeBP wrote: post #199

Earlier quoted context omitted.

Probing more than a page size below the current stack pointer is wrong. Probing more than a page size further when one's saved frame area, save area, locals area, and (maximum) calling parameters area do not amount to a page in total is also wrong. For more on the considerations that underpin stack probing, see http://jdebp.eu./FGA/function-perilogues.html#StackProbes for starters.

Also, the probe does an unlocked RMW (or 0) instead of a read, which is slower but also wrong in a multithreaded application. The latter is what broke Go.

Is that because Go crams the thread stacks closely together and it probed into another thread's stack?

Regardless, it seems like RMW (or even just a store) should be fine as long as the stack pointer is adjusted before the probe.

Re: The mysterious case of the Linux Page Table Isolation patches

#245

Post by hintss »

pixl97 wrote: post #155
neerajsi wrote: post #148

Earlier quoted context omitted.

Locksmiths can get into many locks that people use to secure their houses. That doesn't mean that I want them to share that knowledge widely.

Eh, that information is shared widely. Some decent googl-fu will get you the information you want. The difference is a lock-pick can't exploit 20,000 doors in 20 minutes.

There are definitely bypass tools for common lock mechanisms, whose mechanism of operation isn't readily google-able.

Re: The mysterious case of the Linux Page Table Isolation patches

#246

Post by nske »

foobarbazetc wrote: post #152
saas_co_de wrote: post #100

Earlier quoted context omitted.

I never understand why people don't go bare metal. It is just as easy to automate, just as cheap (or cheaper) if you plan well, and more secure. A decade ago everyone knew that shared hosting was for hobby sites and stuff that didn't really matter. Maybe some more people will learn that lesson.

As someone who shares your skepticism of the cloud, I can say that people don’t switch from bare metal hosting (something like SoftLayer) to AWS/GCP for the cost. If you do the math like “we have 1000 cores and 2048Gb of RAM and 10Tb of RAID’ed SSD” and then plug that in to the GCP calculator... it’s going to be at minimum 1.5-2x your bare metal cost. That’s not even including bandwidth which is pretty much free at b…

You are right, however I think the amount of users that use cloud server instances because they really need that dynamic scalability is much smaller than the amount of users that use it just because

Re: The mysterious case of the Linux Page Table Isolation patches

#247

Post by nske »

neerajsi wrote: post #148
syshum wrote: post #65

Earlier quoted context omitted.

Your analogy is severely flawed as my door lock is under my control and I know about the risks (i.e it is unlocked) so I can take the steps I need to mitigate that risk For your analogy to apply here it would be the manufacturer of the door lock having a master key stolen then not telling anyone about it until they have a new lock for you to buy from them, in the case of a lock I would want to know that the lock is u…

Locksmiths can get into many locks that people use to secure their houses. That doesn't mean that I want them to share that knowledge widely.

I want them to. This puts more pressure for locks to improve and makes it less likely that I trust my current lock.

Re: The mysterious case of the Linux Page Table Isolation patches

#248

Post by Taniwha »

rst wrote: post #227
wilun wrote: post #161

Earlier quoted context omitted.

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wi…

One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here: https://twitter.com/pwnallthethings/status/94797892728438374... but (as he notes elsewhere) there are plen…

my guess is that the cache tags or tlb entries loaded on failed speculative accesses are wrong (maybe the valid bit is set but the address wasn't changed, or the user/supervisor protections are munged), that could leave you with a cache line or page tagged as user accessible but really protected kernel data

Re: The mysterious case of the Linux Page Table Isolation patches

#249

Post by snuxoll »

JJJollyjim wrote: post #239
TheSwordsman wrote: post #211

One question I have around this is whether the patches made to the Windows kernel in November exhibit the same performance hits. Does anyone know? I'm due to refresh my gaming PC, and I was going to go with Intel again as they've not been a problem. However, if Intel chips are going to incur the same 5% - 50% performance hit on Windows, I might end up investing in AMD hardware instead.

I'm certainly no expert, but I would guess that the context-switch time (where I believe the new overhead is added) in games is fairly small compared to the raw number-crunching in-process, so the effect would be minimal in any case

Every draw call will need to transition to kernel space to send data over the PCIe bus to the GPU. Modern games execute something on the order of 1000+ draws per frame, so assuming 60fps that's going to be at least 60,000*2 context switches into the kernel and back per second, more if you're doing high refresh rates.

How big the impact I will be, I don't know - but I wouldn't be surprised if it was a couple percent (effectively ruining the single-threaded performance boost Intel has in gaming over AMD before accounting for overclocking).

Re: The mysterious case of the Linux Page Table Isolation patches

#250

Post by TheSwordsman »

snuxoll wrote: post #249
JJJollyjim wrote: post #239

Earlier quoted context omitted.

I'm certainly no expert, but I would guess that the context-switch time (where I believe the new overhead is added) in games is fairly small compared to the raw number-crunching in-process, so the effect would be minimal in any case

Every draw call will need to transition to kernel space to send data over the PCIe bus to the GPU. Modern games execute something on the order of 1000+ draws per frame, so assuming 60fps that's going to be at least 60,000*2 context switches into the kernel and back per second, more if you're doing high refresh rates. How big the impact I will be, I don't know - but I wouldn't be surprised if it was a couple percent (…

I was also worried about network I/O too, which could be an absolute pain for games where you care about latency.
Post reply on HN