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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Nov 21, 2017, at 9:26 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

On 13.11.17 at 16:41, <george.dunlap@xxxxxxxxxx> 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_.

You don’t have to have conclusive proof that the numbers work in all cases; we only need to have reasonable evidence that higher numbers are generally reliable.  To use US legal terminology, it’s “preponderance of evidence” (usually used in civil trials) rather than “beyond a reasonable doubt” (used in criminal trials).

In this case, there are credible claims that using more vcpus opens users up to a host DoS, and no evidence (or arguments) to the contrary.  I think it would be irresponsible, under those circumstances, to tell people that they should provide more vcpus to untrusted guests.

It wouldn’t be too hard to gather further evidence.  If someone competent spent a few days trying to crash a larger guest and failed, then that would be reason to think that perhaps larger numbers were safe.

+### 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).

OK.  Below is an updated section.  It might be good to specify how large is "larger".

---
### Virtual RAM

    Limit-security, x86 PV 64-bit: 2047GiB
    Limit-security, x86 PV 32-bit: 168GiB (see below)
    Limit-security, x86 HVM: 1.5TiB
    Limit, ARM32: 16GiB
    Limit, ARM64: 1TiB

Note that there are no theoretical limits to 64-bit PV or HVM guest sizes
other than those determined by the processor architecture.

All 32-bit PV guest memory must be under 168GiB;
this means the total memory for all 32-bit PV guests cannot exced 168GiB.
On larger hosts, this limit is 128GiB.

---

+### 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.

I have no idea.  Do you have another limit you’d like to propose instead?

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.

That's a good starting point.  I've added the following:

---
### Hypervisor synchronous console output (sync_console)

    Status: Supported, not security supported

Xen command-line flag to force synchronous console output.
Useful for debugging, but not suitable for production environments
due to incurred overhead.

---

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.

Well specifically for sync_console, I would think given our definition of "Supported", "not suitable for production environments" would imply "not security supported"; but it wouldn't hurt to add an entry for it under "Debugging, analysis, and post-mortem", so I've written one up:

---
### Hypervisor 'debug keys'

    Status: Supported, not security supported
   
These are functions triggered either from the host serial console,
or via the xl 'debug-keys' command,
which cause Xen to dump various hypervisor state to the console.
---

In general, if a feature is explicitly listed *but* some configuration is not listed (e.g., 'x86 PV' and 'x86 HVM' are listed but not 'x86 PVH') then that feature is not implemented for that configuration is not implemented.

If a feature is not listed at all, then this document isn't saying anything one way or another (which is no worse than you were before).

Also, I realized that I somehow failed to send out the 17th patch (!), which primarily had XXX entries for qemu-upstream/qemu-traditional, and host serial console support.

Shall I try to make a list of supported serial cards from /build/hg/xen.git/xen/drivers/char/Kconfig?

 -George

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