lkml.org 
[lkml]   [2022]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv4 17/30] x86/tdx: Add port I/O emulation
On Thu, Feb 24, 2022 at 07:59:51PM -0800, Dave Hansen wrote:
> On 2/24/22 07:56, Kirill A. Shutemov wrote:
> > @@ -347,6 +399,8 @@ static bool virt_exception_kernel(struct pt_regs *regs, struct ve_info *ve)
> > return handle_cpuid(regs);
> > case EXIT_REASON_EPT_VIOLATION:
> > return handle_mmio(regs, ve);
> > + case EXIT_REASON_IO_INSTRUCTION:
> > + return handle_io(regs, ve->exit_qual);
>
> Sorry to keep throwing random new things at this patch set. Thanks for
> bearing with me.
>
> Is there anything to keep these port I/O #VE's from occurring in
> userspace? It's not how things are normally done, but is there
> something fundamental to keep ioperm() and friends from working in TDX
> guests?
>
> As it stands with this set, userspace would probably
> 1. Succeed with the ioperm()
> 2. Do a port I/O instruction
> 3. Trigger a #VE
> 4. Get killed by the SIGSEGV that came from the #VE handler
>
> That's not a horrible state of affairs. But, if this *can* happen, it
> might be nice to just refuse the ioperm() in the first place.

Right, there's a way to get port I/O from userspace and we are not
intended to support it. And, yes, ioperm() is the right place to do this.

We considered to make it happen via security lockdown mechanism. It
already block port I/O (LOCKDOWN_IOPORT) and does more stuff that can be
considered useful for paranoid guest. I'm not sure it is the right way to
go. Will see.

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.

--
Kirill A. Shutemov

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