[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 16/16] SUPPORT.md: Add limits RFC
>>> 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_. > +### 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |