Side note - and this may be crazy talk - I wonder if it might make sense to have a mode where we allow executable read-only kernel pages to be marked global too (but only in the kernel mapping).
Yes, yes, that potentially means that you can run meltdown on recently run kernel code that is still in the TLB, but even if so, that may be something people are ok with. Because it would leak data that can generally be gotten other ways (aka "just download the vendor kernel from a website"), and from a security standpoint the biggest issue is likely that you can break KASLR. But again, that is something that some people may be perfectly fine with - it's certainly much less of an issue than leaking actual *data*. And it might be an easy option to give people, with something like "pti=data" or similar. It's also quite possible that depending on how separate the ITLB and DTLB is, an ITLB entry might not even really be amenable to Meltdown leaking at all. Since the pages wouldn't actually exist in the user page tables, the only sign of them would be in the TLB entries, and if the ITLB is separate enough it might be practically impossible to really use those ITLB entries for meltdown. Of course, maybe the performance advantage from keeping the ITLB entries around isn't huge, but this *may* be worth at least asking some Intel architects about? Because my gut feel is that a noticeable amount of the TLB cost from PTI comes from the code side. I suspect a lot of kernel code has a bigger instruction footprint than data. (And yes, like this set of global bit patches, it probably matters a whole lot more on CPU's that don't have PCID. With PCID it's probably not all that noticeable at all). Linus