aboutsummaryrefslogtreecommitdiffstats
path: root/extras/mini-os/console/xenbus.c
Commit message (Collapse)AuthorAgeFilesLines
* mini-os: fix various memory leaks in consfrontMatthew Daley2013-09-211-4/+5
| | | | | | | | Coverity-ID: 1055816 Coverity-ID: 1055817 Coverity-ID: 1055818 Signed-off-by: Matthew Daley <mattjd@gmail.com> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
* mini-os: handle possibly overlong _nodename in init_consfrontMatthew Daley2013-09-131-2/+4
| | | | | | | | | The only current user that passes a non-NULL _nodename limits it to 64 bytes anyway. Coverity-ID: 1054993 Signed-off-by: Matthew Daley <mattjd@gmail.com> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
* minios: clean up allocation of char arrays used for xenbus pathsMatt Wilson2013-09-101-2/+2
| | | | | | | | | | This patch cleans up instances of char array allocation where string lengths were manually counted to use strlen() instead. There are no functional changes in this patch. Signed-off-by: Matt Wilson <msw@amazon.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-By: Samuel Thibault <samuel.thibault@ens-lyon.org>
* minios: correct char array allocation for xenbus pathsMatt Wilson2013-09-101-1/+1
| | | | | | | | | | | | | | | | | | | The char arrays used to hold xenbus paths have historically been allocated by manually counting the length longest string constants included in constructing the path. This has led to improperly sized buffers, both too large (with little consequence) and too small (which obviously causes problems). This patch corrects the instances where the length was incorrectly calculated by using strlen() on the longest string constant used in building a xenbus path. A follow-on clean-up patch will change all instances to use strlen(). Signed-off-by: Ben Cressey <bcressey@amazon.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-By: Samuel Thibault <samuel.thibault@ens-lyon.org> [msw: split this patch from a larger patch from Ben, reworked to use strlen()] Signed-off-by: Matt Wilson <msw@amazon.com>
* libxl: Restrict permissions on PV console device xenstore nodesIan Jackson2013-06-251-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matthew Daley has observed that the PV console protocol places sensitive host state into a guest writeable xenstore locations, this includes: - The pty used to communicate between the console backend daemon and its client, allowing the guest administrator to read and write arbitrary host files. - The output file, allowing the guest administrator to write arbitrary host files or to target arbitrary qemu chardevs which include sockets, udp, ptr, pipes etc (see -chardev in qemu(1) for a more complete list). - The maximum buffer size, allowing the guest administrator to consume more resources than the host administrator has configured. - The backend to use (qemu vs xenconsoled), potentially allowing the guest administrator to confuse host software. So we arrange to make the sensitive keys in the xenstore frontend directory read only for the guest. This is safe since the xenstore permissions model, unlike POSIX directory permissions, does not allow the guest to remove and recreate a node if it has write access to the containing directory. There are a few associated wrinkles: - The primary PV console is "special". It's xenstore node is not under the usual /devices/ subtree and it does not use the customary xenstore state machine protocol. Unfortunately its directory is used for other things, including the vnc-port node, which we do not want the guest to be able to write to. Rather than trying to track down all the possible secondary uses of this directory just make it r/o to the guest. All newly created subdirectories inherit these permissions and so are now safe by default. - The other serial consoles do use the customary xenstore state machine and therefore need write access to at least the "protocol" and "state" nodes, however they may also want to use arbitrary "feature-foo" nodes (although I'm not aware of any) and therefore we cannot simply lock down the entire frontend directory. Instead we add support to libxl__device_generic_add for frontend keys which are explicitly read only and use that to lock down the sensitive keys. - Minios' console frontend wants to write the "type" node, which it has no business doing since this is a host/toolstack level decision. This fails now that the node has become read only to the PV guest. Since the toolstack already writes this node just remove the attempt to set it. This is a security issue, XSA-57. Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
* mini-os: make frontends and xenbus optionalDaniel De Graaf2012-02-091-0/+198
This adds compile-time logic to disable certain frontends in mini-os: - pcifront is disabled by default, enabled for ioemu - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default - xenbus is required for any frontend, and is enabled by default If all frontends and xenbus are disabled, mini-os will run without needing to communicate with xenstore, making it suitable to run the xenstore daemon. The console frontend is not required for the initial console, only consoles opened via openpt or ptmx. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>