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;
Message-ID: <dd370f1e-e9f9-0843-da24-83ad6f99ec76@intel.com>
Date:   Thu, 24 Feb 2022 19:59:51 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Language: en-US
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        luto@kernel.org, peterz@infradead.org
Cc:     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
References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com>
 <20220224155630.52734-18-kirill.shutemov@linux.intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation
In-Reply-To: <20220224155630.52734-18-kirill.shutemov@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.