[SPAM]: RE: Nasty new Intel processor bug
> Changing CR3 flushes some cached processor state (like TLBs),
IIRC, this does not apply to the pages that are marked as 'Global' ones in their
PTEs - after all, this is the very purpose of a 'Global' bit.
> It looks like the first bug, known as Meltdown, will require a fix along the
lines of keeping >separate user mode and kernel mode page tables, and changing
the page table base register, >CR3, anytime the processor shifts between user
and kernel mode, like on every system
>call and every interrupt.
Well, in order to make it work they will have to mark all kernel pages as
non-global ones, plus, as you have mentioned already, keep separate kernel and
On one hand, performance penalty seems to be just dramatic if they go this way,
at least at tye first glance. However, if you think of a kernel just as of a
special process with its own page directory and page tables, then you arrive to
the solution that is more or less reminiscent of,say, Linux running on top of
L4, i.e. something that is known to show an acceptable performance
> A second related bug, impacts Intel, AMD, and some ARM processors.
This is what all the media keeps on reiterating again and again and again, but
I am somehow surprised by this combination. As long as we are speaking about
Intel and AMD, we can make an assumption that the bug is inherent to the very
x86_64 architecture( which means this is not really a bug but just an
architectural flaw,but anyway). However, when I see ARM in this "company", I am
getting pretty confused. After all, ARM is a totally different architecture.
How come that the same _hardware_ vulnerability is sort of "portable" across