[svsm-devel] Kernel security features

[Thomas Leroy]

Thanks for your feedback Joerg :)

On 8/29/24 09:02, Jörg Rödel wrote:
> Thanks for starting this list, I think this is very relevant. The
> project already has the ground-work for KASLR. Making GDT and IDT
> read-only should be a low-hanging fruit. SMEP and SMAP is a bit more
> work, though also not that complicated.
>
> Shadow stacks is probably the hardest item to implement. What about
> KPTI, is that still necessary with recent processors? If we do KPTI then
> we also need PCID.
KPTI was also suggested my Carlos, so I appended it to the list but I'm
also unsure about it (I'll also add PCID).
If we allow an unprivileged user to run code on the same CPU, my
understanding is that KPTI would still be relevant to prevent leaking
sensitive data through side channel. However, with memory encrypted,
what exactly could an attacker leak?
Moreover, KPTI is also relevant to prevent an attacker with a powerful
primitive (like ROP, or arbitrary read/write) to access any gadgets or
memory from kernel space (however this can be bypassed on Linux by
chaining the correct gadgets).
Maybe we could try to reproduce the side-channel attacks before as a
starting analysis.

-- 
Thomas Leroy
Security Engineer
SUSE Software Solutions