Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 28 Feb 2022 04:16:27 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation
Message-ID: <20220228011627.63355pcbpn7tosiy@black.fi.intel.com>
References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com>
 <20220224155630.52734-18-kirill.shutemov@linux.intel.com>
 <dd370f1e-e9f9-0843-da24-83ad6f99ec76@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dd370f1e-e9f9-0843-da24-83ad6f99ec76@intel.com>
Precedence: bulk

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