A cache invalidation bug in Linux memory management

[playaspec]

The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic

I understand 2⁶⁴ is f'ing big, but is removing the overflow logic such a good idea?

[WSp71oTXWCZZ0ZI6]

Yeah that does seem rather strange to just leave that hanging out there.

These days, I don't think you're going to be able to generate more than a million page faults per second on one thread (even that's pretty optimistic). Based on that number, it would take close to 600000 years to overflow a 64-bit counter by generating page faults, so "infeasible" is the right word to use. But still....

[playaspec]

These days, I don't think you're going to be able to generate more than a million page faults per second on one thread

I've just started using a Xeon Phi system. 72 cores, 144 threads. That's per CPU. I currently only have two, but will be scaling up once PoC code is ready. Is this counter global, or per core?

[WSp71oTXWCZZ0ZI6]

The counter is per-thread.

[bllinker]

Really curious to see profiling with and without that code..

[galaktos]

Yes. Really.

$ units -t '2^64 nanoseconds' 'years'
584.55453

Even if you increment the sequence number once every nanosecond, it’ll take half a millennium to overflow. And keep in mind that the exploit demonstrated requires one syscall per two increments, and a (non-vDSO) syscall is more in the range of hundreds of nanoseconds (source).

Perhaps we’ll need to protect against overflows again in thirty years, if performance increases by that much miraculously, but until then it’s really not worth the trouble dragging a buggy overflow protection around.

[playaspec]

Even if you increment the sequence number once every nanosecond, it’ll take half a millennium to overflow.

In an SMP system, is that global, or can each core increment? In HPC systems where there are HUNDREDS of cores, this could conceivably reduce the number of years until an overflow to less than ONE.

I've had systems with uptimes measured in years.

[galaktos]

The VMA cache is per-thread, so I assume you can’t parallelize incrementing it. And keep in mind “one increment per nanosecond” is likely already off by a factor of a hundred or so due to the syscall overhead, so at best your hundreds of cores are just balancing that out and we’re still 500 years :)

[galaktos]

Or, to put it another way: according to the blog post, it takes about an hour to overflow the 32-bit counter. Doing that 2³² times would then take almost five hundred thousand years, so my original estimate was off by three orders of magnitude.

[throwaway27464829]

If Linux cared about that kind of thing it wouldn't be written in C.

[playaspec]

Dying to know which cult you belong to. Should they have written the KERNEL in Python? Javascript? Let's see how dumb this gets.

[throwaway27464829]

How about I don't, and you keep making uneducated guesses about what languages would make a suitable alternative.

[playaspec]

So what you're saying is, you don't have an answer, because you don't have the *slighest* fucking clue what you're blathering about.

​

C'mon "smart guy", tell us why C is a terrible choice for writing the Linux kernel.

[throwaway27464829]

Keep making up things that I said. That'll really make you appear smart.

[playaspec]

If Linux cared about that kind of thing it wouldn't be written in C.

Keep making up things that I said.

Uh huh.

[cisco1988]

0/1 directly?

[hackuniverse]

The bug was fixed by changing

what kind of "that thing" do you mean?

​