linux-kernel - Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dd370f1e-e9f9-0843-da24-83ad6f99ec76@intel.com>
Date:   Thu, 24 Feb 2022 19:59:51 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        luto@...nel.org, peterz@...radead.org
Cc:     sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
        ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
        hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
        joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
        pbonzini@...hat.com, sdeep@...are.com, seanjc@...gle.com,
        tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
        thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation

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.