lkml.org 
[lkml]   [2018]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Xen-devel] [PATCH] xen: remove size limit of privcmd-buf mapping interface
    From
    Date
    On 02/11/2018 08:26, Jan Beulich wrote:
    >>>> On 01.11.18 at 17:27, <jgross@suse.com> wrote:
    >> On 01/11/2018 16:50, Jan Beulich wrote:
    >>>>>> Juergen Gross <jgross@suse.com> 11/01/18 3:23 PM >>>
    >>>> On 01/11/2018 15:18, Jan Beulich wrote:
    >>>>>>>> Juergen Gross <jgross@suse.com> 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

    \
     
     \ /
      Last update: 2018-11-02 10:54    [W:4.169 / U:0.768 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site