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
| ||
|
Message-ID: <20220302174210.q5r6zl2lsa6hut6q@treble> 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
Powered by blists - more mailing lists