Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 12, 2018 at 03:19:38AM -0700, Jan Beulich wrote:
> This is a very simplistic change limiting the amount of memory a running
> 64-bit PV guest has mapped (and hence available for attacking): Only the
> mappings of stack, IDT, and TSS are being cloned from the direct map
> into per-CPU page tables. Guest controlled parts of the page tables are
> being copied into those per-CPU page tables upon entry into the guest.
> Cross-vCPU synchronization of top level page table entry changes is
> being effected by forcing other active vCPU-s of the guest into the
> hypervisor.
> 
> The change to context_switch() isn't strictly necessary, but there's no
> reason to keep switching page tables once a PV guest is being scheduled
> out.
> 
> There is certainly much room for improvement, especially of performance,
> here - first and foremost suppressing all the negative effects on AMD
> systems. But in the interest of backportability (including to really old
> hypervisors, which may not even have alternative patching) any such is
> being left out here.

Thanks. I bet many people will be very grateful for this.

Not many comments since I'm not familiar with the code.

> @@ -799,6 +982,10 @@ void __init smp_prepare_cpus(unsigned in
>  
>      stack_base[0] = stack_start;
>  
> +    if ( !setup_cpu_root_pgt(0) )
> +        panic("No memory for root page table\n");
> +    get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));

Wouldn't it be helpful to have a command line option to decide whether
to enable this feature or not?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel