The current code was incorrectly using SECCLASS_XEN instead of
SECCLASS_XEN2, resulting in the wrong permission being checked.
GET_CPU_LEVELLING_CAPS was checking MTRR_DEL
GET_CPU_FEATURESET was checking MTRR_READ
The default XSM policy only allowed these permissions to dom0, so this
didn't result in a security issue there.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add two missing allow rules:
1. Device model domain construction uses getvcpucontext, discovered by
Andrew Cooper while chasing an unrelated issue.
2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t). It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor. The policy provided by the bootloader, if present, will
override the built-in policy.
The XSM policy is not moved out of tools because that remains the
primary location for installing and configuring the policy.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This makes the buffers function parameters instead of globals, in
preparation for adding alternate locations for the policy.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor. The policy provided by the bootloader, if present, will
override the built-in policy.
Enabling this option only builds the policy if checkpolicy is available
during compilation of the hypervisor; otherwise, it does nothing. The
XSM policy is not moved out of tools because that remains the primary
location for installing and configuring the policy.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
provider, hide the option to disable FLASK under EXPERT.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex. Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and that can be placed in xsm_core.c.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
to decide if the permission should be allowed or denied. This allows
new operations to be tested without needing to immediately add security
checks; however, it is not flexible enough to avoid adding the actual
permission checks. An error message is printed to the hypervisor
console when this fallback is encountered.
This patch will allow operations that are not handled by the existing
hooks only if the policy was compiled with "checkpolicy -U allow". In
previous releases, this bit did nothing, and the default remains to deny
the unknown operations.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
This operation has no known users, and is primarily useful when an MLS
policy is in use (which has never been shipped with Xen). In addition,
the information it provides does not actually depend on hypervisor
state (only on the XSM policy), so an application that needs it could
compute the results without needing to involve the hypervisor.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
This field was originally used in Linux for a default message code for
network interfaces. It has never been used in Xen, so remove it.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
These permissions were initially split because they were in separate
domctls, but this split is very unlikely to actually provide security
benefits: it would require a carefully contrived situation for a domain
to both need access to one type of CPU register and also need to be
prohibited from accessing another type.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This adds the xenstore_t type to the example policy for use by a
xenstore stub domain; see the init-xenstore-domain tool for how this
type needs to be used.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
This also renames the example users created by vm_role.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
When the all_system_role module is enabled, any domain type can be
created using the system_r role, which was the default. When it is
disabled, domains not using the default types (dom0_t and domU_t) must
use another role such as vm_r.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
The previous default of "permissive" is meant for developing or
debugging a disaggregated system. However, this default makes it too
easy to accidentally boot a machine in this state, which does not place
any restrictions on guests. This is not suitable for normal systems
because any guest can perform any operation (including operations like
rebooting the machine, kexec, and reading or writing another domain's
memory).
This change will cause the boot to fail if you do not specify an XSM
policy during boot; if you need to load a policy from dom0, use the
"flask=late" boot parameter.
Original patch by Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; modified
to also change the default value of flask_enforcing so that the policy
is not still in permissive mode. This also removes the (no longer
documented) command line argument directly changing that variable since
it has been superseded by the flask= parameter.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
When FLASK_{GET,SET}BOOL is called with a named boolean, the call to
flask_security_resolve_bool is made prior to bool_maxstr being populated
by flask_security_make_bools. This results in the maximum string length
being specified as zero, which is not useful. While it would be
possible to initialize bool_maxstr correctly prior to its use, it is
simpler to use a fixed maximum of PAGE_SIZE as is done for the other
calls to safe_copy_string_from_guest.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Migration and HVM domain creation both trigger AVC denials that should
be allowed in the default policy; add these rules.
Guest console writes need to be either allowed or denied without audit
depending on the decision of the local administrator; introduce a policy
boolean to switch between these possibilities.
Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Add default security contexts to the XSM policy for use by the toolstack
when a domain is created without specifying an explicit security label.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The definitions of static device labels must be placed at the end of the
policy.conf before passing it to checkpolicy; the existing examples
(which are commented out) are in the wrong location. Create a new file
for device contexts which will place them in the proper location.
This also removes some directions about using the xen policy type in
checkpolicy which is no longer needed.
Reported-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This adds support in the hypervisor and policy build toolchain for
Xen/Flask policy version 30, which adds the ability to label ARM device
tree nodes and expands the IOMEM ocontext entries to 64 bits.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This unifies the flask_enforcing and flask_enabled boot parameters into
a single parameter with additional states. Defined options are:
enforcing - require policy to be loaded at boot time and enforce it
permissive - a missing or broken policy does not panic
disabled - revert to dummy (no XSM) policy. Was flask_enabled=0
late - bootloader policy is not used; later loadpolicy is enforcing
The default mode remains "permissive" and the flask_enforcing boot
parameter is retained for compatibility. If flask_enforcing=1 is
specified and flask= is not, the bootloader policy will be loaded in
enforcing mode if present, but errors will disable access controls until
a successful loadpolicy instead of causing a panic at boot.
Suggested-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This removes the FLASK_DEVELOP and FLASK_BOOTPARAM configuration
parameters which have never been settable by users. Disabling the
FLASK_DEVELOP configuration option has not produced a compiling
hypervisor for some time, and the FLASK_BOOTPARAM option will be
replaced with a more flexible boot parameter.
This also changes the return type of xsm_initcall_t to void to properly
reflect the fact that the caller ignores the return value.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Rather than using the internal MPI format for the Diffie-Hellman group,
whose representation depends on the size of the t_uint type, store the
value as a big-endian integer and use mpi_read_binary to convert it in
an architecture-independent manner. This patch also removes the
unnecessary range check on the exponent which ended up being different
between 32- and 64-bit code.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The internal MPI word size matches the word size of the platform rather
than using uint32_t/uint64_t, so constant MPI objects need to be
initialized with that in mind.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Because there is not currently a method for the vTPM Manager to obtain a
build hash of a vTPM, use the hash of the vTPM's XSM label as a
substitute. This allows the vTPM Manager to distinguish between vTPMs
intended to be paired with a hardware domain kernel (which cannot use
pv-grub) and vTPMs which are paired with a pv-grub domain and therefore
contain reliable measurements of the guest kernel in PCRs 4 and 5.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This adds an optional argument --vtpm-label=<label> to the pv-grub
command line. If specified, a vtpm device must be connected to the
pv-grub domain and the backend of this device must have the given XSM
label (which may start with a * to indicate a wildcard). Verifying the
label of the vTPM before sending measurements prevents a disaggregated
control domain that has access to xenstore but not to the guest domains
from causing the measurements performed by pv-grub to be discarded,
allowing the forgery of arbitrary kernel measurements in the TPM.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This allows the client of a vTPM to request a quote from the physical
TPM which includes PCRs from both the physical and virtual TPMs, signed
by an AIK from the physical TPM. This quote can be used to provide
evidence of the complete launch environment of a virtual machine.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
For a vTPM to be useful for remote attestation, proof that the vTPM's EK
was generated and held within a secure vTPM implementation is necessary.
This patch adds an ordinal to the vTPM which will request a quote
providing this evidence from the TPM Manager; it only functions during
the first startup of a given vTPM in order to provide proof that the EK
was freshly generated (and not a key whose private part is available
elsewhere).
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When sending commands to a vTPM, commands with the VTPM_TAG_REQ2 tag are
passed directly to the TPM Manager since they are used in the management
interface to the TPM Manager. The VTPM_TAG_REQ tag is translated to
TPM_TAG_RQU_COMMAND to allow access to the physical TPM for certain
ordinals (PCRRead, Extend, and GetRandom).
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The manage-vtpmmgr.pl script is an example client for interacting with
the TPM Manager; it is intended to run in a management domain with a
vTPM (which may be dom0). It is used to create and manage vTPMs and
vTPM groups.
The calc.pl script is an example manager of a vTPM group. It signs
the configuration lists used by the TPM Manager with a locally held
private key.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This is a complete rewrite of the disk format and key hierarchy for the
TPM Manager. The new format supports multiple groups of vTPMs which
define the permitted configurations where a given vTPM's keys are
available, allowing upgrades of critical components while retaining the
secrecy of cryptographic keys.
New features of the TPM Manager are explained in the README and in the
definitions of the management commands in vtpm_manager.h.
New features for vTPMs:
1. The size of the state blob for a vTPM is expanded from 52 to 64
bytes in order to support future vTPMs using SHA-2/3 instead of SHA-1.
2. vTPMs can obtain a quote from the physical TPM with certain
resettable PCRs set to include information about the vTPM. This can be
used by a vTPM to provide evidence of its integrity, including the
secrecy of its EK, and for deep quotes.
Some additional changes made by this rewrite that may impact existing
users:
1. The value of WELLKNOWN_OWNER_AUTH was incorrect for the physical TPM;
the convention is to use all zero bits for well-known authentication
values, not all one bits.
2. Randomly generating the owner auth value for the physical TPM is no
longer supported, as it prevents later creation or certification of
AIKs (which the old manager did not support).
3. The vTPM Manager needs to be provisioned with a PCR composite and an
upgrade authority's public key before it will save data across boots.
The current implementation still has some limitations:
* 5 valid system PCR selections per group
* The vTPM Manager's disk can use at most 2MB of space
* The vTPM domain's build hash is always set to null/zero
Most of the code relating to upgrade and rollback protection is
currently stubbed out, but future versions can add:
* Support for using the TPM's monotonic counter to prevent rollback
of vTPM data by taking and restoring disk snapshots
* Masking the master disk encryption key using a value stored in the
TPM's NVRAM so that revocation of old data is possible without
relying on all previously authorized software stacks to respect the
monotonic counter's value
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This adds a hypervisor command line option "hardware_dom=" which takes a
domain ID. When the domain with this ID is created, it will be used
as the hardware domain.
This is intended to be used when domain 0 is a dedicated stub domain for
domain building, allowing the hardware domain to be de-privileged and
act only as a driver domain.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This requires setting the hardware_domain variable earlier in
domain_create so that functions called from it (primarily in
arch_domain_create) observe the correct results when they call
is_hardware_domain.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When dom0 is not the hardware domain, it can be destroyed in the same
way as any other service domain. To avoid accidental use when a domain
is not resolved, destroying domain 0 requires passing -f to xl destroy.
Since the hypervisor already prevents a domain from destroying itself,
this patch is only useful in a disaggregated environment.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Most of these functions actually act on the hardware domain, so change
their names to reflect this.
Command line parameters and variables based on those parameters are
excluded since those changes would be user-visible, as are any public
headers.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
This should not change any functionality other than renaming the global
variable. In a few cases (primarily the domain building code), a local
variable or argument named dom0 was created and used instead of the
global hardware_domain to clarify that the domain being used in this
case is actually domain 0.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Christoph Egger <chegger@amazon.de>
Acked-by: Keir Fraser <keir@xen.org>
When the hardware domain is made distinct from dom0, it becomes possible
to shut down and destroy domain 0 while leaving the hypervisor running.
If this happens, prevent this domain ID from being considered for
allocation to a new guest.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Keir Fraser <keir@xen.org>
When the hardware domain is split from domain 0, the initialization code
for the hardware domain cannot be in the __init section, since the
actual domain creation happens after these sections have been discarded.
Create a __hwdom_init section designator to annotate these functions,
and control it using the XSM configuration option for now (since XSM is
required to take advantage of the security benefits of disaggregation).
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Instead of checking is_privileged to determine if a domain should
control the hardware, check that the domain_id is equal to zero (which
is currently the only domain for which is_privileged is true). This
allows other places where domain_id is checked for zero to be replaced
with is_hardware_domain.
The distinction between is_hardware_domain, is_control_domain, and
domain 0 is based on the following disaggregation model:
Domain 0 bootstraps the system. It may remain to perform requested
builds of domains that need a minimal trust chain (i.e. vTPM domains).
Other than being built by the hypervisor, nothing is special about this
domain - although it may be useful to have is_control_domain() return
true depending on the toolstack it uses to build other domains.
The hardware domain manages devices for PCI pass-through to driver
domains or can act as a driver domain itself, depending on the desired
degree of disaggregation. It is also the domain managing devices that
do not support pass-through: PCI configuration space access, parsing the
hardware ACPI tables and system power or machine check events. This is
the only domain where is_hardware_domain() is true. The return of
is_control_domain() may be false for this domain.
The control domain manages other domains, controls guest launch and
shutdown, and manages resource constraints; is_control_domain() returns
true. The functionality guarded by is_control_domain may in the future
be adapted to use explicit hypercalls, eliminating the special treatment
of this domain. It may be reasonable to have multiple control domains
on a multi-tenant system.
Guest domains and other service or driver domains are all treated
identically by the hypervisor; the security policy may further constrain
administrative actions on or communication between these domains.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Event channel arrays are allocated in blocks with EVTCHNS_PER_BUCKET
elements, which must be a power of 2. When XSM is disabled, struct
evtchn is 32 bytes including padding; however, when XSM is enabled, the
structure becomes larger and EVTCHNS_PER_BUCKET is halved. Rearranging
some of the fields in struct evtchn allows a 4-byte XSM field to fit
within the 32-byte structure.
This rearrangement turns the xen_consumer field of struct evtchn into a
bitfield and adjusts the xen_consumers array to fit the number of
addressable elements from this value. Since there are currently only
two users of this array, only 3 bits (7 values) are reserved. This
field is also used rarely enough that the slight overhead from applying
a bitmask should not cause problems.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
When FLASK is the only enabled implementation of the XSM hooks in Xen,
some of the abstractions required to handle multiple XSM providers are
redundant and only produce unneeded overhead. This patch reduces the
memory overhead of enabling XSM on event channels by replacing the
untyped ssid pointer from struct evtchn with a union containing the
contents of the structure. This avoids an additional heap allocation
for every event channel, and on 64-bit systems, reduces the size of
struct evtchn by 4 bytes. If an out-of-tree XSM module needs the full
flexibility of the generic evtcnn ssid pointer, defining the symbol
XSM_NEED_GENERIC_EVTCHN_SSID will include a suitable pointer field.
This also cleans up the unused selinux_checkreqprot declaration left
from the Linux port.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Move the preprocessor definitions for all FLASK parameters other than
the enable flag off the compiler command line and into config.h, which
is the preferred location for such definitions.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
The automatic shutdown feature of the vTPM was removed because it
interfered with pv-grub measurement support and was also not triggered
if the guest did not use the vTPM. Virtual TPM domains will need to be
shut down or destroyed on guest shutdown via a script or other user
action.
This also fixes an incorrect reference to the vTPM being PV-only.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Some XSM hooks in dummy.h used current->domain when this was also passed
as a parameter; use the parameter in these cases. There are two hooks
where this does not apply and which are not immediately obvious:
xsm_set_target's parameters are the device model and HVM domains, and
xsm_mem_sharing_op's first parameter is the source of the shared page,
not the domain making the hypercall.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The CONSOLEIO_read operation was incorrectly allowed to PV guests if the
hypervisor was compiled in debug mode (with VERBOSE defined).
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
When the permission checks for memory mapping were moved from
get_pg_owner to xsm_mmu_update in aaba7a677, the exception for DOMID_IO
was not taken into account. This will cause IO memory mappings by PV
domains (mini-os in particular) to fail when XSM/FLASK is not being
used. This patch reintroduces the exception for DOMID_IO; the actual
restrictions on IO memory mappings have always been checked separately
using iomem_access_permitted, so this change should not break existing
access control.
Reported-by: Eduardo Peixoto Macedo <epm@cin.ufpe.br>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
When the permission checks for memory mapping were moved from
get_pg_owner to xsm_mmu_update in aaba7a677, the exception for DOMID_IO
was not taken into account. This will cause IO memory mappings by PV
domains (mini-os in particular) to fail when XSM/FLASK is not being
used. This patch reintroduces the exception for DOMID_IO; the actual
restrictions on IO memory mappings have always been checked separately
using iomem_access_permitted, so this change should not break existing
access control.
Reported-by: Eduardo Peixoto Macedo <epm@cin.ufpe.br>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Guests other than domain 0 using the console output have previously been
controlled by the VERBOSE #define, but with no designation of which
guest's output was on the console. This patch converts the HVM output
buffering to be used by all domains except the hardware domain (dom0):
stripping non-printable characters, line buffering the output, and
prefixing it with the domain ID. This is especially useful for debugging
stub domains during early boot.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Keir Fraser <keir@xen.org>
This fixes framebuffer support for device model stubdoms after 3f28d007
which added the target_hack permission but did not allow the permission
to the stubdom it was created for.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since the remaining uses of IS_PRIV are actually concerned with the
domain having control of the hardware (i.e. being the initial domain),
clarify this by renaming IS_PRIV to is_hardware_domain. This also
removes IS_PRIV_FOR since the only remaining user was xsm/dummy.h.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)
Acked-by: Keir Fraser <keir@xen.org>
This function (and rcu_lock_remote_target_domain_by_id) has no remaining
users, having been replaced with XSM hooks and the other rcu_lock_*
functions. Remove it.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)
Acked-by: Keir Fraser <keir@xen.org>
This function has been replaced with rcu_lock_domain_by_any_id and an
XSM check. Two callers already had an XSM check; add a check to the
third.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)
Acked-by: Ian Campbell <ian.campbell@citrix.com> (for thae ARM bits)
Adds XSM hooks for the recently introduced XENMEM_claim_pages and
XENMEM_get_outstanding_pages operations, and adds FLASK access vectors
for them. This makes the access control decisions for these operations
match those in the rest of the hypervisor.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (for 4.3 release)
Acked-by: Keir Fraser <keir@xen.org>
Since libxl checks for the existance of /var/run/xenstored.pid in order
to ensure xenstore is running, create this file when starting the
xenstore stub domain. This also changes the Makefile to enable the
creation of the init-xenstore-domain tool during tools compilation,
since the existing Makefile incorrectly added to the ALL_TARGETS list
when compiling the stubdom, when this variable is not used.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The check in guest_physmap_mark_populate_on_demand is redundant, since
its only caller is populate_physmap whose only caller checks the
xsm_memory_adjust_reservation hook prior to calling.
Add a new XSM hook for the other two checks since they allow privileged
domains to arbitrarily map a guest's memory.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (release perspective)
This adds an XSM hook for enabling nested HVM support, replacing an
IS_PRIV check. This hook is a partial duplicate with the xsm_hvm_param
hook, but using the existing hook would require adding the index to the
hook and would require the use of a custom hook for the xsm-disabled
case (using XSM_OTHER, which is less immediately readable) - whereas
adding a new hook retains the clarity of the existing code.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> (release perspective)
In the XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN operation, the existing check
for domid == 0 should be checking that a domain does not attempt to
modify its own cpupool; fix this by using rcu_lock_remote_domain_by_id.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
This prevents a process in dom0 from granting a domU access to an IRQ without
adding the IRQ to the domU's list of permitted IRQs. This operation currently
succeeds in dom0 but would fail if the device model were running in a stubdom,
so making the failure consistent should ease debugging of the device-model
stubdoms.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Several domctl functions dealing with rangesets contain a short-circuit
bypass if the domain is privileged. Since the construction of domain 0
permits access to all I/O ranges, the call to irq_access_permitted will
normally return true even without the IS_PRIV check, and the presence of
the IS_PRIV check prevents the creation of a privileged domain without
access to specific devices or IO memory ranges.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This avoids returning unallocated memory in the libxl_device_vtpm
structure in libxl_device_vtpm_list, and uses libxl_device_nic_init
instead of memset when initializing libxl_device_nics.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This adds a backend_domname field in libxl devices that contain a
backend_domid field, allowing either a domid or a domain name to be
specified in the configuration structures. The domain name is resolved
into a domain ID in the _setdefault function when adding the device.
This change allows the backend of the block devices to be specified
(which previously required passing the libxl_ctx down into the block
device parser), and will simplify specification of backend domains in
other users of libxl.
The check on run_hotplug_scripts in parse_config_data is removed because
it is a duplicate of the one in libxl__device_nic_setdefault, and is
removed here because it no longer has the resolved domain ID to check.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran flex ]
This adds the ability for a vTPM to constrain what localities a given
client domain can use based on its XSM label. For example:
locality=user_1:vm_r:domU_t=0,1,2 locality=user_1:vm_r:watcher_t=5
An arbitrary prefix can be matched by using a '*'.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This changes the save format of the vtpm stubdom to include two copies
of the saved data: one active, and one inactive. When saving the state,
data is written to the inactive slot before updating the key and hash
saved with the TPM Manager, which determines the active slot when the
vTPM starts up.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The vTPM protocol now contains a field allowing the locality of a
command to be specified; pass this to the TPM when processing a packet.
While the locality is not currently checked for validity, a binding
between locality and some distinguishing feature of the client domain
(such as the XSM label) will need to be defined in order to properly
support a multi-client vTPM.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
The vtpm2 ABI supports packets of up to 4088 bytes by default; expose
this property though the TPM's interface so clients do not attempt to
send larger packets.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Instead of only recording the UUID field, which may not be of interest
to all tpmback implementations, provide a user-settable opaque pointer
associated with the tpmback instance.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The open/close callbacks in tpmback cannot be properly initalized in
order to catch the initial enumeration events because init_tpmback
clears the callbacks and then asynchronously starts the enumeration of
existing tpmback devices. Fix this by passing the callbacks to
init_tpmback so they can be installed before enumeration.
This also removes the unused callbacks for suspend and resume.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Allow the vtpm device to be disconnected and reconnected so that a
bootloader (like pv-grub) can submit measurements and return the vtpm
device to its initial state before booting the target kernel.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This changes the vTPM shared page ABI from a copy of the Xen network
interface to a single-page interface that better reflects the expected
behavior of a TPM: only a single request packet can be sent at any given
time, and every packet sent generates a single response packet. This
protocol change should also increase efficiency as it avoids mapping and
unmapping grants when possible. The vtpm xenbus device now requires a
feature-protocol-v2 node in xenstore to avoid conflicts with existing
(xen-patched) kernels supporting the old interface.
While the contents of the shared page have been defined to allow packets
larger than a single page (actually 4088 bytes) by allowing the client
to add extra grant references, the mapping of these extra references has
not been implemented; a feature node in xenstore may be used in the
future to indicate full support for the multi-page protocol. Most uses
of the TPM should not require this feature.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Jan Beulich <JBeulich@suse.com>
When NEWLIB_STAMPFILE is updated but gmp has already been extracted, the mv
command will incorrectly create a subdirectory instead of renaming. Remove the
old target before renaming to fix this.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch enables the compilation of the FLASK policy as part of the
tools build if the needed prerequisites are present.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This adds the ability to define security classes and access vectors in
FLASK policy not defined by the hypervisor, for the use of stub domains
or applications without their own security policies.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
For the example policy shipped with Xen, it makes sense to allow dom0
access to all system calls so that policy does not need to be updated
for each new hypervisor or toolstack feature used.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The IRQs beyond nr_static_irqs do not all have an associated PCI
device, so only query the device SID if pci is not NULL.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
Manipulation of a domain's pirq namespace was not fully protected by
XSM hooks because the XSM hooks for IRQs needed a physical IRQ. Since
this may not apply to HVM domains, a complete solution needs to split
the XSM hook for this operation, using one hook for the PIRQ
manipulation and one for controlling access to the hardware IRQ.
This reworking has the advantage of providing the same MSI data to
remove_irq that is provided to add_irq, allowing the PCI device to be
determined in both functions. It also eliminates the last callers of
rcu_lock_target_domain_by_id in x86 and common code in preparation for
this function's removal.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
These hypercalls are usable by HVM guests. Once connected, simple
functions of the Xen toolstack can be run from an HVM domain if that
domain is permitted access (which is currently only possible via XSM).
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
When the console is connected to a domain other than dom0, the console
device's backend field should be set so the xenstore permissions for the
console device reflect the domain that will be accessing them.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Grant references for the xenstore and xenconsole shared pages exist, but
currently only xenstore uses these references. Change the xenconsole
daemon to prefer using the grant reference over map_foreign_range when
mapping the shared console ring.
This allows xenconsoled to be run in a domain other than dom0 if set up
correctly - for libxl, the xenstore path /tool/xenconsoled/domid
specifies the domain containing xenconsoled.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Daniel De Graaf