linux-kernel - Re: [PATCHv5 15/30] x86/boot: Port I/O: allow to hook up alternative helpers

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]

Date:   Wed, 2 Mar 2022 09:42:10 -0800
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...el.com, luto@...nel.org, peterz@...radead.org,
        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, 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,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCHv5 15/30] x86/boot: Port I/O: allow to hook up alternative
 helpers

On Wed, Mar 02, 2022 at 05:27:51PM +0300, Kirill A. Shutemov wrote:
> Port I/O instructions trigger #VE in the TDX environment. In response to
> the exception, kernel emulates these instructions using hypercalls.
> 
> But during early boot, on the decompression stage, it is cumbersome to
> deal with #VE. It is cleaner to go to hypercalls directly, bypassing #VE
> handling.
> 
> Add a way to hook up alternative port I/O helpers in the boot stub with
> a new pio_ops structure.  For now, set the ops structure to just call
> the normal I/O operation functions.
> 
> The approach has down sides: TDX boot will fail if any code bypass
> pio_ops and go for direct port I/O helper. The failure will only be
> visible on TDX boot (or other user of alternative pio_ops).
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>

Sorry, but this is still not convincing.

As you said earlier, it's a judgement call.  So, detail all the
considerations which were used when making that call.

Why is this the best approach compared to other alternatives?  It needs
to convince the reader.

Supporting #VE -- by building on the existing #VC support -- seems more
robust than this hack.  Convince me (and other patch reviewers)
otherwise.

At the very least, please remove the ability for future code to
accidentally bypass 'pio_ops'.  Going forward, are we really expected to
just remember to always use pio_ops for i/o?  Or else TDX will just
silently break?  That's just not acceptable.

-- 
Josh