Isn't this related to recent Linus rant about security patch from Google Pixel team? https://www.theregister.co.uk/2017/11/20/security_people_are...
No.
The mysterious case of the Linux Page Table Isolation patches
201–210 of 264 posts
Re: The mysterious case of the Linux Page Table Isolation patches
#202If true, this is pretty huge. As if the AWS "You blew through your budget" emails right around midnight of New Years were only an appetizer. Edit: AWS Spurious Budget Email Barrage: https://www.reddit.com/r/aws/comments/7ndvli/anybody_get_spu...
Oh shit! I thought it was just a bug in my setup! Should have searched around before disabling everything in a panic.
Re: The mysterious case of the Linux Page Table Isolation patches
#203Earlier quoted context omitted.
PCID support is unlikely to be backported, but perhaps a simpler scheme with only two PCIDs (user and kernel) could be applied...
> PCID support is unlikely to be backported I dunno, it sounds like it might be easiest to go ahead and backport PCID along with these patches. It touches a lot of the same code, so trying to split it out might just create more problems.
Yes, and the impact on syscall-intensive workloads is bad enough with PCID, without it it's even worse. I'd be moderately surprised if only KPTI is backported and not PCID.
Re: The mysterious case of the Linux Page Table Isolation patches
#204Earlier quoted context omitted.
Alternatively, use Firefox (on your mobile) to skip Amp and other sillinesses. Greatly improved my mobile browsing experience, haven't looked back (ublock origin, hint hint).
Firefox is pretty slow on my phone and sometimes when I try to search something, nothing happens. I want to like it, but chrome is just a lot smoother :'( I do love how Google tries to "downgrade" its experience on Firefox mobile, but all it really does is cut out all the javascript and material design bullshit.
Try samsung browser if you have a galaxy device. It's smoother and faster than chrome and supports adblock extensions.
Re: The mysterious case of the Linux Page Table Isolation patches
#205Even though I understood less than 50% of that I am still very excited about reading more about whatever the real issue is. If somebody can pwn aws from a random instance that would be highly amusing to me :D
Re: The mysterious case of the Linux Page Table Isolation patches
#206Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…
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…
Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?
Re: The mysterious case of the Linux Page Table Isolation patches
#207Earlier 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…
Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?
I think probably not, I think it may be too fundamental. But perhaps there is a mitigation if only a few instructions cause the leak and they can disable those in speculation. Performance hit could be bad though, worse than the Linux fix.
Re: The mysterious case of the Linux Page Table Isolation patches
#208Guess: it is not directly related to RowHammer/DRAM, and is purely a CPU issue. Maybe PageFault timing info leaks or cache timing, like this pwnie award winner: http://www.cs.vu.nl/~giuffrida/papers/anc-ndss-2017.pdf If this last one can defeat ASLR, imagine leaking bit by bit from a co-hosted VM, to extract secrets of other cloud customers… This is the reason anyone serious about cloud security will reserve instance…
Addendum: I know in most modern CPUs the memory controller is on-die, so my comment is partially wrong (RowHammer is definitely a SoC issue).
Also, if you're interested in this type of things: Armv8.4-A adds a flag … indicating that you want the execution time of instructions to be independent of the data.
https://twitter.com/agl__/status/927929410321244160
Now the primary source seems to have been edited(why?)… But webarchive still has it:
Data Independent Timing
CPU implementations of the Arm Architecture do not have to make guarantees about the length of time instructions take to execute. In particular, the same instructions can take different lengths of time, dependent upon the values that need to be operated on. For example, performing the arithmetic operation ‘1 x 1’ may be quicker than ‘2546483 x 245303’, even though they are both the same instruction (multiply).
This sensitivity to the data being processed can cause issues when developing cryptographic algorithms. Here, you want the routine to execute in the same amount of time no matter what you are processing – so that you don’t inadvertently leak information to an attacker. To help with this, Armv8.4-A adds a flag to the processor state, indicating that you want the execution time of instructions to be independent of the data operated on. This flag does not apply to every instruction (for example loads and stores may still take different amounts of time to execute, depending on the memory being accessed), but it will make development of secure cryptographic routines simpler.
https://web.archive.org/web/20171107164628/https://community...
The scope seems limited to ALU, so not really related to the TLB thing we have here. Also, it's still very far away, I'm not sure its predecessor Armv8.3-A is even shipping to customers yet.
Re: The mysterious case of the Linux Page Table Isolation patches
#209AWS had scheduled maintenance requiring reboot of all EC2 instances in December. Maybe this is somehow related.
We had a large % of our longer running instances have scheduled reboots in Dec.
Is it linked and if so does that mean AWS have already patched?
Re: The mysterious case of the Linux Page Table Isolation patches
#210Interesting to note that https://en.wikipedia.org/wiki/Kernel_page-table_isolation was created on December 29th.