Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 6/9] is_control_domain: block speculation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.01.19 at 15:43, <nmanthey@xxxxxxxxx> wrote:
> @@ -908,10 +909,10 @@ void watchdog_domain_destroy(struct domain *d);
>   *    (that is, this would not be suitable for a driver domain)
>   *  - There is never a reason to deny the hardware domain access to this
>   */
> -#define is_hardware_domain(_d) ((_d) == hardware_domain)
> +#define is_hardware_domain(_d) evaluate_nospec((_d) == hardware_domain)
>  
>  /* This check is for functionality specific to a control domain */
> -#define is_control_domain(_d) ((_d)->is_privileged)
> +#define is_control_domain(_d) evaluate_nospec((_d)->is_privileged)

I'm afraid there's another fly in the ointment here: While looking at
the still questionable grant table change I've started wondering
about constructs like

    case XENMEM_machphys_mapping:
    {
        struct xen_machphys_mapping mapping = {
            .v_start = MACH2PHYS_VIRT_START,
            .v_end   = MACH2PHYS_VIRT_END,
            .max_mfn = MACH2PHYS_NR_ENTRIES - 1
        };

        if ( !mem_hotplug && is_hardware_domain(current->domain) )
            mapping.max_mfn = max_page - 1;
        if ( copy_to_guest(arg, &mapping, 1) )
            return -EFAULT;

        return 0;
    }

Granted the example here could be easily re-arranged, but there
are others where this is less easy or not possible at all. What I'm
trying to get at are constructs where the such-protected
predicates sit on the right side of && or || - afaict (also from
looking at some much simplified code examples) the intended
protection is gone in these cases.

Jan



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