On 02/11/2018 08:26, Jan Beulich wrote: >>>> On 01.11.18 at 17:27, <jgross@xxxxxxxx> wrote: >> On 01/11/2018 16:50, Jan Beulich wrote: >>>>>> Juergen Gross <jgross@xxxxxxxx> 11/01/18 3:23 PM >>> >>>> On 01/11/2018 15:18, Jan Beulich wrote: >>>>>>>> Juergen Gross <jgross@xxxxxxxx> 11/01/18 1:34 PM >>> >>>>>> Currently the size of hypercall buffers allocated via >>>>>> /dev/xen/hypercall is limited to a default of 64 memory pages. For live >>>>>> migration of guests this might be too small as the page dirty bitmask >>>>>> needs to be sized according to the size of the guest. This means >>>>>> migrating a 8GB sized guest is already exhausting the default buffer >>>>>> size for the dirty bitmap. >>>>>> >>>>>> There is no sensible way to set a sane limit, so just remove it >>>>>> completely. The device node's usage is limited to root anyway, so there >>>>>> is no additional DOS scenario added by allowing unlimited buffers. >>>>> >>>>> But is this setting of permissions what we want long term? What about a >>>>> de-privileged qemu, which still needs to be able to issue at least dm-op >>>>> hypercalls? >>>> >>>> Wouldn't that qemu have opened the node while still being privileged? >>> >>> Possibly, but how does this help? As soon as it's unprivileged it must not >>> be able to hog resources anymore. >>> >>> Anyway, with Andrew's reply my point may be irrelevant, but I have to >>> admit I'm not entirely sure. >> >> I guess we want Xen tools to close /dev/xen/hypercall (or more precise: >> don't dup2() it) when qemu is de-privileging itself. This will make it >> very clear that it can't hog memory via mmap(). >> >> When you are fine with that I'll send a Xen patch for this. > > If that doesn't prevent the process from making the hypercalls it > is permitted to do (I have to admit I don't recall if there are any > still needed besides the dmop ones), sure. Turns out that is already done: the restrict_all callback of libxencall will associate /dev/null with the file descriptor of /dev/xen/hypercall. Juergen
