Dave,
On Wed, Mar 09 2022 at 11:14, Dave Hansen wrote:
> On 3/9/22 11:01, Thomas Gleixner wrote:
>>> This series implements the infrastructure needed to track and tear
>>> down bare-metal enclaves and then run EUPDATESVN. This is expected
>>> to be triggered by administrators via sysfs at some convenient time
>>> after a microcode update, probably by the microcode update tooling
>>> itself.
>> Tear down after a microcode update? This does not make any sense at all,
>> really. If the enclaves become inconsistent due to the microcode update
>
> I don't think there's anything that makes the enclaves inconsistent from
> the microcode update itself.
>
> Let's imagine an extreme (thankfully imaginary) case: SGX has been
> totally broken by some attack. All running enclaves might have been
> compromised. A magical microcode update comes and saves the day and
> mitigates the attack.
>
> From the hardware perspective, at the time of the microcode update, the
> (presumably compromised) enclaves *can* still run. Nothing changes for
> them. The only thing they can't do is attest to the shiny new
> microcode.
So lets spin that further in a timeline of events:
6AM Info about CPU erratum which makes SGX vulnerable arrives with
a fix in form of a microcode update
12AM Microcode is updated
6PM Enclaves are torn down
It technically works, but it does not make any sense at all.
I fundamentaly detest procedures which are violating common sense
especially when those violations are not backed up by any technical
arguments.
> Are you saying that the kernel should consider the enclaves inconsistent
> at the time of the microcode update? Or, were you thinking that the
> microcode update process itself would make them inconsistent?
Inconsistent in the meaning that the attestation is moot at the point
of the microcode update because that attestation was done against the
previously loaded microcode.
That means if anything fundamentally changed by the microcode then the
enclave might become vulnerable by the microcode update itself because
the deployment decision based on the previous microcode is not longer
correct.
Unlikely, but not impossible and we had cases where certain mitigations
had to be redone in microcode which means that a code deployed based on
the previous microcode revision is not longer protected.
Again, this all might be a non issue, but with a cover letter based on
marketing ballyhoo, I'm not seeing how this can be correct under all
circumstances.
We write code and create proceedures based on the worst case assumptions
and by applying common sense and not based on what $customer has on his
wishlist. I'm all for serving customers, but ponies are not part of that.
Thanks,
tglx
