Messages in this thread |  | | Date | Sun, 27 Feb 2022 20:32:38 -0800 | From | Dave Hansen <> | Subject | Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation |
| |
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.
|  |