Patchwork [16/16] SUPPORT.md: Add limits RFC

login
register
mail settings
Submitter George Dunlap
Date Nov. 13, 2017, 3:41 p.m.
Message ID <20171113154126.13038-16-george.dunlap@citrix.com>
Download mbox | patch
Permalink /patch/383517/
State New
Headers show

Comments

George Dunlap - Nov. 13, 2017, 3:41 p.m.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Could someone take this one over as well?

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Tim Deegan <tim@xen.org>
---
 SUPPORT.md | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)
Jan Beulich - Nov. 21, 2017, 9:26 a.m.
>>> 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
George Dunlap - Nov. 22, 2017, 6:01 p.m.
> On Nov 21, 2017, at 9:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>>>> 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_.

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

Patch

diff --git a/SUPPORT.md b/SUPPORT.md
index e72f9f3892..d11e05fc2a 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -64,6 +64,53 @@  for the definitions of the support status levels etc.
 
 Extension to the GICv3 interrupt controller to support MSI.
 
+## Limits/Host
+
+### CPUs
+
+    Limit, x86: 4095
+    Limit, ARM32: 8
+    Limit, ARM64: 128
+
+Note that for x86, very large number of cpus may not work/boot,
+but we will still provide security support
+
+### x86/RAM
+
+    Limit, x86: 123TiB
+    Limit, ARM32: 16GiB
+    Limit, ARM64: 5TiB
+
+## Limits/Guest
+
+### Virtual CPUs
+
+    Limit, x86 PV: 8192
+    Limit-security, x86 PV: 32
+    Limit, x86 HVM: 128
+    Limit-security, x86 HVM: 32
+    Limit, ARM32: 8
+    Limit, ARM64: 128
+
+### Virtual RAM
+
+    Limit-security, x86 PV: 2047GiB
+    Limit-security, x86 HVM: 1.5TiB
+    Limit, ARM32: 16GiB
+    Limit, ARM64: 1TiB
+
+Note that there are no theoretical limits to PV or HVM guest sizes
+other than those determined by the processor architecture.
+
+### Event Channel 2-level ABI
+
+    Limit, 32-bit: 1024
+    Limit, 64-bit: 4096
+
+### Event Channel FIFO ABI
+
+    Limit: 131072
+
 ## Guest Type
 
 ### x86/PV
@@ -685,6 +732,20 @@  If support differs based on implementation
 (for instance, x86 / ARM, Linux / QEMU / FreeBSD),
 one line for each set of implementations will be listed.
 
+### Limit-security
+
+For size limits.
+This figure shows the largest configuration which will receive
+security support.
+It is generally determined by the maximum amount that is regularly tested.
+This limit will only be listed explicitly
+if it is different than the theoretical limit.
+
+### Limit
+
+This figure shows a theoretical size limit.
+This does not mean that such a large configuration will actually work.
+
 ## Definition of Status labels
 
 Each Status value corresponds to levels of security support,