Verify ACPI table checksum

[osteffenrh]

Calculate the checksum when parsing ACPI tables and return an error if
it does not match (is == 0).
This means SVSM will fail to read the ACPI tables, especially MADT, and thus fail to boot if the checksum is incorrect.

Keeping this PR as a draft for now, since QEMU does not set a correct checksum in the MADT table (IGVM parameter) yet.

[msft-jlange]

What is the benefit of this change? Are we seeing boot failures as a result of corrupt ACPI tables? Do we think that checksum verification makes a meaningful difference in the stability of the boot process?

From the standpoint of confidential computing, the checksum is no more trusted than any of the rest of the contents, so it doesn't provide any particular security benefit.

[luigix25]

What is the benefit of this change? Are we seeing boot failures as a result of corrupt ACPI tables? Do we think that checksum verification makes a meaningful difference in the stability of the boot process?

From the standpoint of confidential computing, the checksum is no more trusted than any of the rest of the contents, so it doesn't provide any particular security benefit.

@msft-jlange From the security POV I 100% agree with you.

MADT provides a checksum, this could help for unintentional data corruption (bug in the hypervisor?).
So it's not a new field we are introducing. We don't have it in our qemu fork but in upstream qemu (https://lore.kernel.org/qemu-devel/[email protected]/) it is supported.

On the other hand, do you see a problem in introducing it?

[msft-jlange]

On the other hand, do you see a problem in introducing it?

Introducing this change will cause COCONUT to fail on hypervisors that do not correctly set the checksum. This doesn't seem like a positive change - in fact, it seems worse than living with the potential for the bug that you're trying to reduce.

[luigix25]

On the other hand, do you see a problem in introducing it?

Introducing this change will cause COCONUT to fail on hypervisors that do not correctly set the checksum. This doesn't seem like a positive change - in fact, it seems worse than living with the potential for the bug that you're trying to reduce.

If you're referring to our fork of QEMU, it's a bug. However, I agree with you.
After all, Linux will still boot even if the checksum is incorrect, it will just emit a warning. Why not do the same here?

[msft-jlange]

If you're referring to our fork of QEMU, it's a bug.

QEMU is not the only virtualization host, and I don't think we're prepared to promise that all of them provide the correct checksums.

[stefano-garzarella]

If you're referring to our fork of QEMU, it's a bug. However, I agree with you. After all, Linux will still boot even if the checksum is incorrect, it will just emit a warning. Why not do the same here?

A warning makes sense to me, but I agree on continuing the boot.
IIUC this table is not exposed to the guest OS, but it's the one received with the IGVM, so a guest owner could use the observability features (when we will support it), to at least check the hypervisor is behaving well.

[kraxel]

A warning makes sense to me, but I agree on continuing the boot.

Best approach I think. A checksum mismatch indicates some working as it should, be it critical or harmless. So warn about that but (try to) continue booting makes sense to me.

IIUC this table is not exposed to the guest OS

Correct, although this could be changed if needed, for example if we ever want reserve one vcpu for SVSM exclusively. SVSM could pass on a modified MADT then, simliar to what we are doing with the memory map. Requires some significant changes in OVMF though.

[msft-jlange]

IIUC this table is not exposed to the guest OS
Correct, although this could be changed if needed, for example if we ever want reserve one vcpu for SVSM exclusively. SVSM could pass on a modified MADT then, simliar to what we are doing with the memory map. Requires some significant changes in OVMF though.

In that case, the MADT would have to be modified by the SVSM, and that would obligate the SVSM to recalculate the checksum before passing the modified tables to the guest. So the host-calculated checksum (right or wrong) would still not be guest-visible and therefore wouldn't matter at all.