Re: [PATCH RFC 3/4] mm: guest_memfd: Add option to remove guest private memory from direct map

["Manwaring, Derek" <derekmn@amazon.com>]

On 2024-08-06 07:10-0700 David Hildenbrand wrote:
> > While guest_memfd is not available to be mapped by userspace, it is
> > still accessible through the kernel's direct map. This means that in
> > scenarios where guest-private memory is not hardware protected, it can
> > be speculatively read and its contents potentially leaked through
> > hardware side-channels. Removing guest-private memory from the direct
> > map, thus mitigates a large class of speculative execution issues
> > [1, Table 1].
>
> I think you have to point out here that the speculative execution issues
> are primarily only an issue when guest_memfd private memory is used
> without TDX and friends where the memory would be encrypted either way.
>
> Or am I wrong?

Actually, I'm not sure how much protection CoCo solutions offer in this
regard. I'd love to hear more from Intel and AMD on this, but it looks
like they are not targeting full coverage for these types of attacks
(beyond protecting guest mitigation settings from manipulation by the
host).  For example, see this selection from AMD's 2020 whitepaper [1]
on SEV-SNP:

"There are certain classes of attacks that are not in scope for any of
these three features. Architectural side channel attacks on CPU data
structures are not specifically prevented by any hardware means. As with
standard software security practices, code which is sensitive to such
side channel attacks (e.g., cryptographic libraries) should be written
in a way which helps prevent such attacks."

And:

"While SEV-SNP offers guests several options when it comes to protection
from speculative side channel attacks and SMT, it is not able to protect
against all possible side channel attacks. For example, traditional side
channel attacks on software such as PRIME+PROBE are not protected by
SEV-SNP."

Intel's docs also indicate guests need to protect themselves in some
cases saying, "TD software should be aware that potentially untrusted
software running outside a TD may be able to influence conditional
branch predictions of software running in a TD" [2] and "a TDX guest VM
is no different from a legacy guest VM in terms of protecting this
userspace <-> OS kernel boundary" [3]. But these focus on hardening
kernel & software within the guest.

What's not clear to me is what happens during transient execution when
the host kernel attempts to access a page in physical memory that
belongs to a guest. I assume if it only happens transiently, it will not
result in a machine check like it would if the instructions were
actually retired. As far as I can tell encryption happens between the
CPU & main memory, so cache contents will be plaintext. This seems to
leave open the possibility of the host kernel retrieving the plaintext
cache contents with a transient execution attack. I assume vendors have
controls in place to stop this, but Foreshadow/L1TF is a good example of
one place this fell apart for SGX [4].

All that said, we're also dependent on hardware not being subject to
L1TF-style issues for the currently proposed non-CoCo method to be
effective.  We're simply clearing the Present bit while the physmap PTE
still points to the guest physical page. This was found to be
exploitable across OS & VMM boundaries on Intel server parts before
Cascade Lake [5] (thanks to Claudio for highlighting this). So that's a
long way of saying TDX may offer similar protection, but not because of
encryption.

Derek

[1] https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf#page=19
[2] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-domain-security-guidance-for-developers.html
[3] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#transient-execution-attacks-and-their-mitigation
[4] https://foreshadowattack.eu/foreshadow.pdf
[5] https://foreshadowattack.eu/foreshadow-NG.pdf