[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.
On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan Beulich wrote: > >>> On 30.01.16 at 15:38, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: > > > On 1/30/2016 12:33 AM, Jan Beulich wrote: > >>>>> On 29.01.16 at 11:45, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: > >>> --- a/xen/arch/x86/hvm/hvm.c > >>> +++ b/xen/arch/x86/hvm/hvm.c > >>> @@ -940,6 +940,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct > >>> hvm_ioreq_server *s, > >>> { > >>> unsigned int i; > >>> int rc; > >>> + unsigned int max_wp_ram_ranges = > >>> + s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES]; > >> > >> You're still losing the upper 32 bits here. Iirc you agreed to range > >> check the value before storing into params[]... > > > > Thanks, Jan. :) > > In this version, the check is added in routine parse_config_data(). > > If option 'max_wp_ram_ranges' is configured with an unreasonable value, > > the xl will terminate, before calling xc_hvm_param_set(). Does this > > change meet your requirement? Or maybe did I have some misunderstanding > > on this issue? > > Checking in the tools is desirable, but the hypervisor shouldn't rely > on any tool side checking. > As in hypervisor needs to sanitise all input from toolstack? I don't think Xen does that today. What is the difference between this particular configuration option and all other options in the same hvm_set_conf_params function? Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |