Greetings, ----- Original Message ----- > As I understand from dasunsrule32's post, affected CPUs show a flag > X86_BUG_CPU_INSECURE (?!). > Does this mean that Intel is distributing CPUs marking them as > defective?! ...or is this flag from kernel detection?
It is detected by the kernel and not a real CPU flag. If I understood a LWN article on the subject correctly (currently only available to subscribers but freely available later this week), the KPTI code in 4.15-rcX can tell whether the bug is present or not and use the fix if needed and avoid the fix (and the performance penalties it includes) if not needed. I believe there is also a runtime parameter that can be used to manually disable the fix if desired. > + Is somebody listing fixed CPU models? To the best of my knowledge, Intel hasn't yet released any new CPUs without the issue. They will in the future however. > Note: I suppose neither OpenVZ 6 nor LXC are affected by this > hardware bug. Given the fact that the specifics haven't been publicly released and much of the discussion is speculation... it is hard to answer some of the questions that have been posed. Also given that it is supposed to be a very low level bug that can violate memory access protections between user mode and kernel mode... I would imagine everything is violatable including containers unless OpenVZ/Virtuozzo modified kernel page tables and provided their own isolation (doubtful). The bug is believed to allow one VM to spy on another VM so I don't know why one container wouldn't be able to spy on another... but again, this is all speculation at this point. It is pretty much a given that Red Hat will backport the KPTI to all of the kernels they support. Upstream is said to be doing it in the 4.15 kernel in development as well as backporting it to all LTS kernels so there should be good sources for the fix available to Virtuozzo for patching... but of coruse they'll have to interweave it with their own container patches and do their own QA so there will surely be at the very least a reasonable amount of delay. Hopefully we'll know more when the bug details are publicly released. We have seen absolutely horrible Linux kernel bugs in the past and as long as one patches their systems immediately after the release of updates, I don't think there is much to fear. Of course the main difference here is that the bug is in the hardware and the OSes are having to rewrite their page table code to mitigate it. I've also read that while some other CPU arches have hardware specifically to avoid the issue, others may also have a similar issue. The fix is said to be ported to aarch64 and at least one other arch that I don't recall. Perhaps they are just trying to be over protective? TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
