search for: idt_tables

idt_table is meaningless in paravirtualized guests, but there were still a couple of references to it left. The easiest way to locate them was to get rid of the variable altogether. It depends on the previously submitted patch cleaning up head.S (which, among other things, eliminated early_idt_handler). It also fixes the non-Xen cpu_gdt_init() handling (for easier later merging). Jan

Hi, this is a series of patches that unify the struct desc_struct and friends across x86_64 and i386. As usual, it provides paravirt capabilities as a side-effect for x86_64. I consider the main goal, namely, of unifying the desc_struct, an ongoing effort, being this the beginning. A lot of old code has to be touched to accomplish that. I don't consider this patch ready for inclusion.

Hi, this is a series of patches that unify the struct desc_struct and friends across x86_64 and i386. As usual, it provides paravirt capabilities as a side-effect for x86_64. I consider the main goal, namely, of unifying the desc_struct, an ongoing effort, being this the beginning. A lot of old code has to be touched to accomplish that. I don't consider this patch ready for inclusion.

...* handler is immue to corrupt exception frames, by virtue of + * being designed never to return. + * + * This update is safe from a security point of view, as this + * pcpu is never going to try to sysret back to a PV vcpu. + */ + set_ist(&idt_tables[cpu][TRAP_machine_check], IST_NONE); + + kexec_crash_save_cpu(); + __stop_this_cpu(); + + this_cpu(crash_save_done) = 1; + atomic_dec(&waiting_for_crash_ipi); + } + + /* Poor mans self_nmi(). __stop_this_cpu() has reverted the LAPIC + * back to its boot st...

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

Hi, I am working on a security architecture. In this architecture, the application in DomU has to communicate directly with the hypervisor. But as I can see, the xen architecture allows only DomU kernel to raise a hypercall. I am planning to enable application to communicate with xen directly. I am assuming, setting up a trap gate with Ring-3 access should do the trick. I have few questions

(Andrew, please sit these in the -mm tree for cooking) Create a paravirt.h header for (almost) all the critical operations which need to be replaced with hypervisor calls. For the moment, this simply includes no_paravirt.h, where all the native implementations now live. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Zachary Amsden <zach@vmware.com>

(Andrew, please sit these in the -mm tree for cooking) Create a paravirt.h header for (almost) all the critical operations which need to be replaced with hypervisor calls. For the moment, this simply includes no_paravirt.h, where all the native implementations now live. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Zachary Amsden <zach@vmware.com>

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

From: Joerg Roedel <jroedel at suse.de> With SEV-ES, exception handling is needed very early, even before the kernel has cleared the bss segment. In order to prevent clearing the currently used IDT, move the IDT to the data segment. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/idt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

From: Joerg Roedel <jroedel at suse.de> With SEV-ES, exception handling is needed very early, even before the kernel has cleared the bss segment. In order to prevent clearing the currently used IDT, move the IDT to the data segment. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/idt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

On Mon, Aug 24, 2020 at 10:54:37AM +0200, Joerg Roedel wrote: > +#ifdef CONFIG_AMD_MEM_ENCRYPT > +static void set_early_idt_handler(gate_desc *idt, int n, void *handler) > +{ > + struct idt_data data; > + gate_desc desc; > + > + init_idt_data(&data, n, handler); > + idt_init_desc(&desc, &data); > + native_write_idt_entry(idt, n, &desc); > +} >

On Mon, Aug 24, 2020 at 10:54:37AM +0200, Joerg Roedel wrote: > +#ifdef CONFIG_AMD_MEM_ENCRYPT > +static void set_early_idt_handler(gate_desc *idt, int n, void *handler) > +{ > + struct idt_data data; > + gate_desc desc; > + > + init_idt_data(&data, n, handler); > + idt_init_desc(&desc, &data); > + native_write_idt_entry(idt, n, &desc); > +} >

From: Joerg Roedel <jroedel at suse.de> The #VC exception will trigger very early in head_64.S, when the first CPUID instruction is executed. When secondary CPUs boot, they already load the real system IDT, which has the #VC handler configured to be using an IST stack. IST stacks require a TSS to be loaded, to set up the TSS early for bringing up the secondary CPUs. Use the RW version of

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is

From: Joerg Roedel <jroedel at suse.de> Setup an early handler for #VC exceptions. There is no GHCB mapped yet, so just re-use the vc_no_ghcb_handler. It can only handle CPUID exit-codes, but that should be enough to get the kernel through verify_cpu() and __startup_64() until it runs on virtual addresses. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link:

I would like to propose an interface change to the following paravirt-ops calls: void (fastcall *write_ldt_entry)(void *dt, int entrynum, u64 entry); void (fastcall *write_gdt_entry)(void *dt, int entrynum, u64 entry); void (fastcall *write_idt_entry)(void *dt, int entrynum, u64 entry); Can we consolidate the dt and entrynum parameters and just pass dt+entrynum*8? I