Re: [Xen-devel] [PATCH 2/2] x86/hvm: honor guest's option when updating secondary system time for guest

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.07.14 at 06:30, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, July 23, 2014 8:19 PM
>> To: Wu, Feng
>> Cc: linux@xxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx;
>> keir@xxxxxxx; tim@xxxxxxx 
>> Subject: Re: [PATCH 2/2] x86/hvm: honor guest's option when updating
>> secondary system time for guest
>> 
>> >>> On 08.07.14 at 01:18, <feng.wu@xxxxxxxxx> wrote:
>> > --- a/xen/include/public/vcpu.h
>> > +++ b/xen/include/public/vcpu.h
>> > @@ -227,6 +227,16 @@ struct vcpu_register_time_memory_area {
>> >  typedef struct vcpu_register_time_memory_area
>> > vcpu_register_time_memory_area_t;
>> >  DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t);
>> >
>> > +/*
>> > + * Flags to tell Xen whether we need to do the SMAP check when updating
>> > + * the secondary copy of the vcpu time when SMAP is enabled. Since the
>> > + * memory location for the secondary copy of the vcpu time may be mapped
>> > + * into userspace by guests intendedly, we let the guest to determine
>> > + * whether the check is needed. The default behavior of hypevisor is
>> > + * not doing the check.
>> > + */
>> > +#define VCPUOP_enable_smap_check_vcpu_time_memory_area   14
>> 
>> I think the new op to be VCPUOP_register_vcpu_time_memory_area_smap,
>> identical to VCPUOP_register_vcpu_time_memory_area apart from also
>> setting the flag, would be more natural. But considering what I just wrote
>> in the reply to Tim I guess we can expect a nun-user mapping to be
>> presented here anyway, i.e. we wouldn't need to new operation at all.
> 
> Do you mean since the user-paging is r/o, guest will pass a r/w kernel page 
> to
> Xen for updating the system time. So we don't need to do the SMAP check
> in this case?

If the user page is r/o, it's VA obviously can't be used for updating by
Xen. Hence the kernel has to provide a r/w mapped VA. That should be
subject to SMAP checking (consistent with the runstate area handling),
to make sure it's not a user accessible mapping.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel