Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation

Dave Hansen
2022-02-28T04:32:58Z

On 2/27/22 17:16, Kirill A. Shutemov wrote:
> Anyway, it is in our plans to sort it out, but it is not in scope of core
> enabling. Let's make it functional first.

Yeah, but we need to know what these plans are. There's still a _bit_
too much hand-waving and "trust us" going on in this set.

If this can induce extra SIGSEV's in userspace that aren't possible in
non-TDX systems, please call that out.

For instance, something like this in the changelog of this patch would
be really nice:

== Userspace Implications ==

The ioperm() facility allows userspace access to I/O
instructions like inb/outb. Among other things, this allows
writing userspace device drivers.

This series has no special handling for ioperm(). Users
will be able to successfully request I/O permissions but will
induce a #VE on their first I/O instruction. If this is
undesirable users can <add advice here about LOCKDOWN_IOPORT>

More robust handling of this situation (denying ioperm() in
all TDX guests) will be addressed in follow-on work.

That says: This causes a problem. The problem looks like this. It can
be addressed now by doing $FOO or later by doing $BAR.

But, the *problem* needs to be called out. That way, folks can actually
think about the problem rather than just reading a happy changelog that
neglects to mention any of the problems that the patch leaves in its wake.

The same goes for the CPUID mess. I'm not demanding a full solution in
the patch or the series even. But, what I am demanding is a full
_problem_ disclosure.