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

111–120 of 264 posts

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

#111

Post by asveikau »

tzs wrote: post #64
avian wrote: post #33

Earlier quoted context omitted.

Why would users refuse to buy hardware that works 99.9999999999% of the time when they apparently have no problem buying software that works 99% of the time? Radioactive decays and cosmic particles flipping bits give an upper bound for reliability. You are not going to see low-background packages and rad-hard chips in your iPhone.

Almost everything I've seen on error rates from radioactive decay and cosmic particles has been on servers in data centers. I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I ask because I had a couple of home desktop Linux boxes once, without ECC RAM, that were running as lightly loaded servers. I ran a background…

I think it's multiplication. The odds are low but the number of potential instances is larger. Data centers have larger numbers of machines and those machines are doing repeated work where you observe the result.

Personal machines are typically limited by what your senses can handle. There are few of them for starters. They idle a lot. If many pieces failed inexplicably it's not likely to be something you are personally paying attention to with your senses.

(I have personally observed ram and disk failures on personal machines anyway. And I have seen stuff in my dmesg indicating hardware faults on my personal desktops, but rarely in a way that I notice in actual use not looking at dmesg.)

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

#112

Post by pja »

twoodfin wrote: post #82

I'm confused about the TLB impact. The pythonsweetness link claims these patches now require TLB flushes when crossing the kernel/user boundary, but the description of KAISER @ lwn[1] suggests that these flushes are unnecessary with "more recent" processors supporting PCIDs. How recent is "more recent", and is the PCID support likely to be ported back to earlier kernels along with KPTI? TLB flushes for syscalls would…

If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent kernel ones. PCID doesn't help you here - indeed it hurts, because it means there are more TLB entries from the hypervisor or other virtual machines remaining in the TLB to be corrupted!

(Unless I have entirely the wrong end of the stick about this?)

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

#113

Post by vitaliyf »

This may or may not be related, but there is a Xen advisory embargoed until Thursday (see https://xenbits.xen.org/xsa/) and I am aware of at least one VM provider who scheduled emergency VM reboots across their entire fleet this week because the issue cannot be addressed through hot-patching.

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

#114

Post by tbrownaw »

madez wrote: post #73
cjbprime wrote: post #17

Earlier quoted context omitted.

They weren't really trying to uncover the exploit such that they can reproduce it. They were trying to learn who the exploit affects and what the impact is. I don't think there's anything wrong with that. If you're an AWS customer who depends on hypervisor isolation for critical security guarantees, it helps you to know that this is threatened and perhaps exploitable. Please don't buy into the idea that embargoes and…

The CCC stated also that they observed that companies take a more reactive rather than proactive stance regarding their IT security because they believe that they will be notified of vulnerabilities prior of public disclosure or attacks. This may justify not following embargoes and coordinated disclosure.

Do you have a link?

I'd expect the incentives to be a bit more complicated than that, and I'm also a bit skeptical that either is all that good of a solution. I'd also like to see how exactly "proactive" and "reactive" are being used here, is it about push vs pull for vulnerability notifications, or about hiring their own security researchers, or... ?

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

#115

Post by yeukhon »

saas_co_de wrote: post #75
avh02 wrote: post #39

Earlier quoted context omitted.

No, but they prevent everybody with ill-intent from exploiting the issue en-masse

Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps. Prior to disclosure there will always be the possibility that some users are being exploited without their knowledge. Therefore disclosure always improves the situation by giving those who could have been exploited without their knowledge the choice to take mitigation steps. All of the "responsible disclosure" nonsen…

> Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps.

And what are those mitigation steps?

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

#116

Post by ce4 »

tambre wrote: post #88

Non-AMP link: http://pythonsweetness.tumblr.com/post/169166980422/the-myst...

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).

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

#117

Post by lscotte »

jerrysievert wrote: post #18
ProAm wrote: post #6

Earlier quoted context omitted.

I missed what happened with AWS? Any details

not sure on exact details, but I received one as well, on a free-tier account I had sitting around with an empty dynamodb table that was showing very high projected usage. it was enough that I logged in immediately thinking that account had been hacked. nope, still empty table, deleted it and went to bed. glad I wasn't the only one who got that.

Same for me, a dynamodb table I created 5 years ago with one k/v pair (test=foo) and never accessed since...

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

#118

Post by cjbprime »

tbrownaw wrote: post #108
cjbprime wrote: post #17

Earlier quoted context omitted.

They weren't really trying to uncover the exploit such that they can reproduce it. They were trying to learn who the exploit affects and what the impact is. I don't think there's anything wrong with that. If you're an AWS customer who depends on hypervisor isolation for critical security guarantees, it helps you to know that this is threatened and perhaps exploitable. Please don't buy into the idea that embargoes and…

Please don't buy into the idea that embargoes and coordinated disclosure are sacred. They tend to just reinforce existing power structures, sometimes in an unethical (or at least unfair) way. They're an attempt to minimize harm, by getting things patched while minimizing information leaked to blackhats. Just because giving preference to groups with a better reputation and more market share isn't "fair", doesn't mean…

I didn't say it was automatically wrong. I said it was sometimes wrong, and not sacred.

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

#119

Post by Splines »

jstanley wrote: post #61
preordained wrote: post #34

Earlier quoted context omitted.

If you're taking off for vacation and forgot to lock your door, the best thing would be to go back and lock it. If you couldn't get the door locked right away for some reason, you probably wouldn't want the news of your unlocked door broadcast through your neighborhood... Obscurity actually is a layer of security. The mistake is is when people are dependent upon it.

But this isn't one persons' door that's unlocked. This is more like a company that shipped a faulty door lock and is trying to keep it secret until they can ship fixed doors to everybody.

But wouldn't you want to know if your door is faulty, so you can either replace your door, delay your vacation until the new door arrives, or beef up your security system?

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

#120

Post by nikanj »

bhouston wrote: post #99
neerajsi wrote: post #66

Earlier quoted context omitted.

Reverse engineers pretty much know how everything in NT works. Msft publishes enough symbols that it's even possible to automatically decompile much of the code. Something like page table splitting would be obvious.

And the source of an older version of NT leaked a while back.

I think that was NT 4. I don’t think there’s much of that 20-year old code left in the kernel.
Post reply on HN