Dave Hansen <dave.han...@linux.intel.com> wrote: > On 02/15/2018 04:25 PM, Nadav Amit wrote: >> Dave Hansen <dave.han...@linux.intel.com> wrote: >> >>> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>>> I removed the PTI disabling while SMEP is unsupported, although I >>>> must admit I did not fully understand why it is required. >>> >>> Do you mean you don't fully understand how PTI gives SMEP-like behavior >>> on non-SMEP hardware? >> >> No. I understand how it provide SMEP-like behavior, and I understand the >> value >> of SMEP by itself. >> >> However, I do not understand why SMEP-like protection is required to protect >> processes that run in compatibility-mode from Meltdown/Spectre attacks. As >> far as I understand, the process should not be able to manipulate the kernel >> to execute code in the low 4GB. > > There are two problems: one is that regardless of Meltdown/Spectre, SMEP > is valuable. It's valuable to everything, compatibility-mode or not. > > The second problem is the RSB. It has a full-width virtual address and, > unlike the other indirect branch prediction, can steer you anywhere > including to the low 4GB.
Thanks for the explanation. Based on Linus response, I guess this series is nak’d, but still thanks for your patience. I suspected the RSB might be the reason but it seemed to me that all the ROP opportunities are still there, so I assumed it is not a reason. Anyhow, thanks again.