Re: [PATCH 16/16] SUPPORT.md: Add limits RFC

["Jan Beulich" <JBeulich@suse.com>]

>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote:
> +### Virtual CPUs
> +
> +    Limit, x86 PV: 8192
> +    Limit-security, x86 PV: 32
> +    Limit, x86 HVM: 128
> +    Limit-security, x86 HVM: 32

Personally I consider the "Limit-security" numbers too low here, but
I have no proof that higher numbers will work _in all cases_.

> +### Virtual RAM
> +
> +    Limit-security, x86 PV: 2047GiB

I think this needs splitting for 64- and 32-bit (the latter can go up
to 168Gb only on hosts with no memory past the 168Gb boundary,
and up to 128Gb only on larger ones, without this being a processor
architecture limitation).

> +### Event Channel FIFO ABI
> +
> +    Limit: 131072

Are we certain this is a security supportable limit? There is at least
one loop (in get_free_port()) which can potentially have this number
of iterations.

That's already leaving aside the one in the 'e' key handler. Speaking
of which - I think we should state somewhere that there's no security
support if any key whatsoever was sent to Xen via the console or
the sysctl interface.

And more generally - surely there are items that aren't present in
the series and no-one can realistically spot right away. What do we
mean to imply for functionality not covered in the doc? One thing
coming to mind here are certain command line options, an example
being "sync_console" - the description states "not suitable for
production environments", but I think this should be tightened to
exclude security support.

Jan


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