| Message ID | 20171113154126.13038-16-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> 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
> 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
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,
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(+)