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:   Thu, 7 Dec 2023 17:36:22 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
        "Huang, Kai" <kai.huang@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "mhkelley58@...il.com" <mhkelley58@...il.com>,
        "Cui, Dexuan" <decui@...rosoft.com>
CC:     "cascardo@...onical.com" <cascardo@...onical.com>,
        "tim.gardner@...onical.com" <tim.gardner@...onical.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "roxana.nicolescu@...onical.com" <roxana.nicolescu@...onical.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "stefan.bader@...onical.com" <stefan.bader@...onical.com>,
        "nik.borisov@...e.com" <nik.borisov@...e.com>,
        "kys@...rosoft.com" <kys@...rosoft.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "sashal@...nel.org" <sashal@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early
 TDX init

> >> The TDVMCALLs are related to the I/O path (networking/block io) into the L2
> guest, and
> >> so they intentionally go straight to L0 and are never injected to L1. L1 is not
> >> involved in that path at all.
> >>
> >> Using something different than TDVMCALLs here would lead to additional
> traps to L1 and
> >> just add latency/complexity.
> >
> > Looks by default you assume we should use TDX partitioning as "paravisor L1" +
> > "L0 device I/O emulation".
> >
> 
> I don't actually want to impose this model on anyone, but this is the one that
> could use some refactoring. I intend to rework these patches to not use a single
> "td_partitioning_active" for decisions.
> 
> > I think we are lacking background of this usage model and how it works.  For
> > instance, typically L2 is created by L1, and L1 is responsible for L2's device
> > I/O emulation.  I don't quite understand how could L0 emulate L2's device I/O?
> >
> > Can you provide more information?
> 
> Let's differentiate between fast and slow I/O. The whole point of the paravisor in
> L1 is to provide device emulation for slow I/O: TPM, RTC, NVRAM, IO-APIC, serial
> ports.

Out of my curiosity and not really related to this discussion, but could you please
elaborate on RTC part here? Do you actually host secure time in L1 to be provided
to the L2? 

Best Regards,
Elena.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ