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

[Dave Hansen]

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.