Re: Suggestion: Use a unified kernel image by default in the future.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
> If it is really compromised, then you have to assume anything the vm sends
> you is fake. As far as the owner of guest knows, there could not even a a
> real vm, only a ssh shell that looks like it.
 
> In a real situation, the guest owner would send the host owner a "starting
> disk" or ISO. Then the host would tell the trusted cpu to boot a iso that
> sends the signature to the host, and also boot a modified iso in a normal
> hypervisor, and emulate the trusted part of the cpu. When the normal
> hypervisor vm wants the signature, the signature of vm1 is returned. The
> system in the normal hypervisor could also just lie to any connections
> outside the host system, so even if it knows its backdoored, it still test
> the guest owner its not.

This is a solved problem, and you need to read up on how remote attestation 
works in the presence of an attacker to understand fully how it's solved.

The core to the trick is that the CPU prevents the hypervisor from seeing into 
the state that belongs to the guest (measurements, memory content etc), unless 
the guest explicitly tells the CPU to share that memory. It does this using 
cryptographic primitives so that even an attacker who can monitor the DRAM bus 
externally to the CPU cannot see into guest state.

You can thus use key exchange protocols designed to work over a public channel 
(Diffie-Hellman for a simple example) to set up an encrypted channel between the 
guest and the remote system such that the hypervisor can only deny service - 
it cannot see into the channel, and thus cannot lie to the guest or its remote 
attestation service.

The same techniques are used in TLS to set up a secure channel between a 
service provider like https://start.fedoraproject.org/ and a user like my 
Fedora laptop

-- 
Simon Farnsworth

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux