Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

2024-12-19 Thread Edgecombe, Rick P
On Wed, 2024-12-18 at 18:33 -0800, Sean Christopherson wrote: > > So that is how I arrived at that we need some list of host affecting bits to > > verify match in the TD. > > At the end of the day, the list is going to be human-generated.  For the UX > side > of things, it makes sense to push that

Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

2024-12-18 Thread Edgecombe, Rick P
On Tue, 2024-12-17 at 16:08 -0800, Sean Christopherson wrote: > On Tue, Dec 17, 2024, Rick P Edgecombe wrote: > > It seems like an anti-pattern to have KVM maintaining any code to defend > > against > > TDX module changes that could instead be handled with a promise. > > I disagree, sanity check

Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

2024-12-17 Thread Edgecombe, Rick P
On Mon, 2024-12-16 at 17:53 -0800, Sean Christopherson wrote: > Every new feature that lands in hardware needs to either be "benign" or have > the > appropriate virtualization controls.  KVM already has to deal with cases where > features can effectively be used without KVM's knowledge.  E.g. ther

Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

2024-12-10 Thread Edgecombe, Rick P
On Tue, 2024-12-10 at 11:22 +0800, Xiaoyao Li wrote: > > The solution in this proposal decreases the work the VMM has to do, but in > > the > > long term won't remove hand coding completely. As long as we are designing > > something, what kind of bar should we target? > > For this specific #VE red

Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

2024-12-06 Thread Edgecombe, Rick P
On Fri, 2024-12-06 at 10:42 +0800, Xiaoyao Li wrote: > # Interaction with TDX_FEATURES0.VE_REDUCTION > > TDX introduces a new feature VE_REDUCTION[2]. From the perspective of > host VMM, VE_REDUCTION turns several CPUID bits from fixed1 to > configurable, e.g., MTRR, MCA, MCE, etc. However, from

Re: [PATCH v6 29/60] i386/tdx: Handle KVM_SYSTEM_EVENT_TDX_FATAL

2024-11-06 Thread Edgecombe, Rick P
On Tue, 2024-11-05 at 12:55 -0800, Rick Edgecombe wrote: > Binbin was looking at re-arranging the TDX dev branch to try to move these > patches earlier in the series so we could get them finalized for the purpose > of > fully settling the uAPI for QEMU. > > I wonder if we should just post a very

Re: [PATCH v6 09/60] i386/tdx: Initialize TDX before creating TD vcpus

2024-11-05 Thread Edgecombe, Rick P
+Tony On Tue, 2024-11-05 at 01:23 -0500, Xiaoyao Li wrote: > +int tdx_pre_create_vcpu(CPUState *cpu, Error **errp) > +{ > +    X86CPU *x86cpu = X86_CPU(cpu); > +    CPUX86State *env = &x86cpu->env; > +    g_autofree struct kvm_tdx_init_vm *init_vm = NULL; > +    int r = 0; > + > +    QEMU_LOCK_GUA

Re: [PATCH v6 29/60] i386/tdx: Handle KVM_SYSTEM_EVENT_TDX_FATAL

2024-11-05 Thread Edgecombe, Rick P
+Binbin On Tue, 2024-11-05 at 01:23 -0500, Xiaoyao Li wrote: > TD guest can use TDG.VP.VMCALL to request > termination. KVM translates such request into KVM_EXIT_SYSTEM_EVENT with > type of KVM_SYSTEM_EVENT_TDX_FATAL. > > Add hanlder for such exit. Parse and print the error message, and > termina

Re: [PATCH v6 13/60] i386/tdx: Validate TD attributes

2024-11-05 Thread Edgecombe, Rick P
On Tue, 2024-11-05 at 01:23 -0500, Xiaoyao Li wrote: > -static void setup_td_guest_attributes(X86CPU *x86cpu) > +static int tdx_validate_attributes(TdxGuest *tdx, Error **errp) > +{ > +    if ((tdx->attributes & ~tdx_caps->supported_attrs)) { > +    error_setg(errp, "Invalid attributes 0x%l

Re: [RFC PATCH v2 17/19] heki: x86: Update permissions counters during text patching

2023-11-30 Thread Edgecombe, Rick P
On Wed, 2023-11-29 at 15:07 -0600, Madhavan T. Venkataraman wrote: > Threat Model > > > In the threat model in Heki, the attacker is a user space attacker > who exploits > a kernel vulnerability to gain more privileges or bypass the kernel's > access > control and self-protection mech

Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

2023-05-30 Thread Edgecombe, Rick P
On Fri, 2023-05-26 at 17:22 +0200, Mickaël Salaün wrote: > > > Can the guest kernel ask the host VMM's emulated devices to DMA > > > into > > > the protected data? It should go through the host userspace > > > mappings I > > > think, which don't care about EPT permissions. Or did I miss > > > where

Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

2023-05-25 Thread Edgecombe, Rick P
On Thu, 2023-05-25 at 09:07 -0700, Sean Christopherson wrote: > On Thu, May 25, 2023, Rick P Edgecombe wrote: > > I wonder if it might be a good idea to POC the guest side before > > settling on the KVM interface. Then you can also look at the whole > > thing and judge how much usage it would get f

Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

2023-05-25 Thread Edgecombe, Rick P
On Thu, 2023-05-25 at 15:59 +0200, Mickaël Salaün wrote: [ snip ] > > The kernel often creates writable aliases in order to write to > > protected data (kernel text, etc). Some of this is done right as > > text > > is being first written out (alternatives for example), and some > > happens > > way

Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

2023-05-24 Thread Edgecombe, Rick P
On Fri, 2023-05-05 at 17:20 +0200, Mickaël Salaün wrote: > # How does it work? > > This implementation mainly leverages KVM capabilities to control the > Second > Layer Address Translation (or the Two Dimensional Paging e.g., > Intel's EPT or > AMD's RVI/NPT) and Mode Based Execution Control (Inte