[lkml]   [2022]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

 \ /
  Last update: 2022-02-28 05:33    [W:0.122 / U:3.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site