Re: [PATCH 4/4] configfs-tsm-report: Introduce TCB stability enumeration and watchdog

[Dan Williams <dan.j.williams@intel.com>]

Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2024 at 05:26:26PM -0700, Dan Williams wrote:
> > One of the points of contention for enabling runtime updates of the TDX
> > Module has been what to do about the fact that it results in
> > confidential VMs seeing surprise updates to their TCB. The general
> > concern is that there is a non-zero confidentiality regression risk for
> > updating measured TCB components. Not only the TDX Module, but
> > microcode, SEV-SNP PSP firmware, RISCV and ARM equivalents etc. The
> > degree to which the TCB is or is not compromised by an unexpected update
> > is unknowable by the kernel, but it should at least try to be
> > transparent about what it knows about TCB stability.
> > 
> > Ironically, microcode and PSP firmware update flows predated this
> > launch-state attestation era of confidential computing and resulted in a
> > "permissive" by default policy. So while TDX Module update is a new
> > concern that triggers fresh questions, the resolution of that question
> > reads on more than just the TDX Module.
> > 
> > The proposal is: update the cross-vendor TSM Reports mechanism to have a
> > unified response to this question in the form of a "TCB Stability"
> > build-time configuration stance.
> > 
> > Likely hosting providers expect tenants to be permissive of updates at
> > all times in which case they can just mandate
> > CONFIG_TSM_REPORTS_TCB_STABILITY_PERMISSIVE in tenant Linux kernel
> > configs, and no need to read the rest of this changelog.
> > 
> > Outside of that case though the kernel has a responsibility to be
> > transparent about what it knows about the stability of launch
> > attestation reports, and it has the ability to supplement the lack of
> > proactive notification of pending updates with an after-the-fact
> > watchdog.
> > 
> > The expectation is that userspace that depends on remote attestation
> > (the common ecosystem expectation for confidential computing
> > deployments) already has everything it needs to periodically revalidate
> > the TCB. However, similar to how the typical watchdog backstops
> > unexpected lockup scenarios to limit downtime, the
> > CONFIG_TSM_REPORTS_TCB_STABILITY_RELAXED policy backstops unexpected
> > remote attestation connectivity losses in a common way.
> > 
> > Lastly, CONFIG_TSM_REPORTS_TCB_STABILITY_STRICT, for completeness,
> > allows the kernel to be toxic to even the possibility of runtime
> > updates. The inclusion of this option is mainly for the communication
> > value it provides to later survey how many Linux distributions, cloud
> > hosting providers and confidential computing host platforms offer
> > compatibility with a "no runtime TCB component update" policy. The
> > maintenance burden of this option is low compared to that communication
> > value.
> > 
> > The enforcement of "Relaxed" or "Strict" violations is expected to adopt
> > the kernel's "panic_on_warn" policy. I.e. a violation is only a WARN()
> > in either configuration.
> > 
> > For now, only tdx-guest is updated to convey when runtime updates are
> > disbaled. sev-guest always asserts that runtime updates are enabled.
> 
> I am not convinced it brings any value in TDX case.
> 
> Whether TDX module supports TD_PRESERVING depends on what TDX module it
> is.

...and, do not forget, what the tenant is willing to accept. If a
sufficiently motivated tenant wanted a module that asserted no updates I
have little reason to doubt they could request to run with such a
module.

> And TDX module is already attested, so attestation server can just
> fail attestation if it is not okay with it. It seems to be functionally
> equivalent to what you are proposing.

I address this in the cover letter. There is a measure of value for
requiring the connectivity with the attestation server to remain in
effect. That is the value of watchdog's in general, the kernel can set a
ceiling for exposure to an unattested TCB.

The cost of this mechanism in terms of complexity is negligible when
considering that small (userspace can always do this on its own) value.

Recall that the motivation for this mechanism is to allow forward
progress on update enabling while mitigating the impact to
theoretical hyper-vigilant tenants, and to survey the prevalance of
hyper-vigilant tenants who may not make themselves known until this
technology is more baked and widely avaialable.