- 14 May, 2021 3 commits
-
-
Connor Davis authored
Add a container for cross-compiling xen to riscv64. This just includes the cross-compiler and necessary packages for building xen itself (packages for tools, stubdoms, etc., can be added later). To build xen in the container run the following: $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen Signed-off-by:Connor Davis <connojdavis@gmail.com>
-
Connor Davis authored
Add the minimum code required to get xen to build with XEN_TARGET_ARCH=riscv64. It is minimal in the sense that every file and function added is required for a successful build, given the .config generated from riscv64_defconfig. The function implementations are just stubs; actual implmentations will need to be added later. Signed-off-by: -
Connor Davis authored
Move struct grant_table; in grant_table.h above ifdef CONFIG_GRANT_TABLE. This fixes the following: /build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 84 | static inline int mem_sharing_gref_to_gfn(struct grant_table *gt, | Signed-off-by:
-
- 12 May, 2021 2 commits
-
-
Connor Davis authored
The variables iommu_enabled and iommu_dont_flush_iotlb are defined in drivers/passthrough/iommu.c and are referenced in common code, which causes the link to fail when !CONFIG_HAS_PASSTHROUGH. Guard references to these variables in common code so that xen builds when !CONFIG_HAS_PASSTHROUGH. Signed-off-by: -
Connor Davis authored
Defaulting to yes only for X86 and ARM reduces the requirements for a minimal build when porting new architectures. Signed-off-by:
-
- 10 May, 2021 22 commits
-
-
Volodymyr Babchuk authored
OP-TEE mediator already have support for NULL memory references. It was added in patch 0dbed3ad ("optee: allow plain TMEM buffers with NULL address"). But it does not propagate OPTEE_SMC_SEC_CAP_MEMREF_NULL capability flag to a guest, so well behaving guest can't use this feature. Note: linux optee driver honors this capability flag when handling buffers from userspace clients, but ignores it when working with internal calls. For instance, __optee_enumerate_devices() function uses NULL argument to get buffer size hint from OP-TEE. This was the reason, why "optee: allow plain TMEM buffers with NULL address" was introduced in the first place. This patch adds the mentioned capability to list of known capabilities. From Linux point of view it means that userspace clients can use this feature, which is confirmed by OP-TEE test suite: * regression_1025 Test memref NULL and/or 0 bytes size o regression_1025.1 Invalid NULL buffer memref registration regression_1025.1 OK o regression_1025.2 Input/Output MEMREF Buffer NULL - Size 0 bytes regression_1025.2 OK o regression_1025.3 Input MEMREF Buffer NULL - Size non 0 bytes regression_1025.3 OK o regression_1025.4 Input MEMREF Buffer NULL over PTA invocation regression_1025.4 OK regression_1025 OK Signed-off-by:
Volodymyr Babchuk <volodymyr_babchuk@epam.com> Acked-by:
Julien Grall <jgrall@amazon.com>
-
Julien Grall authored
Commit e867af08 "tools/xenstore: save new binary for live update" seemed to have spuriously changed the indentation of the first line of the copyright header. The previous indentation is re-instated so all the lines are indented the same. Reported-by:
Bjoern Doebel <doebel@amazon.com> Signed-off-by:
Juergen Gross <jgross@suse.com>
-
Julien Grall authored
ASAN reported one issue when Live Updating Xenstored: ================================================================= ==873==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc194f53e0 at pc 0x555c6b323292 bp 0x7ffc194f5340 sp 0x7ffc194f5338 WRITE of size 1 at 0x7ffc194f53e0 thread T0 #0 0x555c6b323291 in dump_state_node_perms xen/tools/xenstore/xenstored_core.c:2468 #1 0x555c6b32746e in dump_state_special_node xen/tools/xenstore/xenstored_domain.c:1257 #2 0x555c6b32a702 in dump_state_special_nodes xen/tools/xenstore/xenstored_domain.c:1273 #3 0x555c6b32ddb3 in lu_dump_state xen/tools/xenstore/xenstored_control.c:521 #4 0x555c6b32e380 in do_lu_start xen/tools/xenstore/xenstored_control.c:660 #5 0x555c6b31b461 in call_delayed xen/tools/xenstore/xenstored_core.c:278 #6 0x555c6b32275e in main xen/tools/xenstore/xenstored_core.c:2357 #7 0x7f95eecf3d09 in __libc_start_main ../csu/libc-start.c:308 #8 0x555c6b3197e9 in _start (/usr/local/sbin/xenstored+0xc7e9) Address 0x7ffc194f53e0 is located in stack of thread T0 at offset 80 in frame #0 0x555c6b32713e in dump_state_special_node xen/tools/xenstore/xenstored_domain.c:1232 This frame has 2 object(s): [32, 40) 'head' (line 1233) [64, 80) 'sn' (line 1234) <== Memory access at offset 80 overflows this variable This is happening because the callers are passing a pointer to a variable allocated on the stack. However, the field perms is a dynamic array, so Xenstored will end up to read outside of the variable. Rework the code so the permissions are written one by one in the fd. Fixes: ed6eebf1 ("tools/xenstore: dump the xenstore state for live update") Signed-off-by:
Luca Fancellu <luca.fancellu@arm.com> -
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of vtimer structure's member: ctl to register_t. Add macro CNTFRQ_MASK containing mask for timer clock frequency field of CNTFRQ_EL0 register. Modify CNTx_CTL_* macros to return unsigned long instead of unsigned int as ctl is now of type register_t. Signed-off-by:
Michal Orzel <michal.orzel@arm.com> Acked-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify accesses to CTR_EL0 to use READ/WRITE_SYSREG. Signed-off-by:
-
Michal Orzel authored
The Armv8 specification describes the system register as a 64-bit value on AArch64 and 32-bit value on AArch32 (same as ARMv7). Unfortunately, Xen is accessing the system registers using READ/WRITE_SYSREG32() which means the top 32-bit are clobbered. This is only a latent bug so far because Xen will not yet use the top 32-bit. There is also no change in behavior because arch/arm/arm64/head.S will initialize SCTLR_EL2 to a sane value with the top 32-bit zeroed. Signed-off-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of vtcr to register_t. Signed-off-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify types of following members of struct gic_v3 to register_t: -vmcr -sre_el1 -apr0 -apr1 Add new macro GICC_IAR_INTID_MASK containing the mask for INTID field of ICC_IAR0/1_EL1 register as only the first 23-bits of IAR contains the interrupt number. The rest are RES0. Therefore, take the opportunity to mask the bits [23:31] as they should be used for an IRQ number (we don't know how the top bits will be used). Signed-off-by:
-
Michal Orzel authored
... as it is never used even in the patch introducing it. Signed-off-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. ACTLR_EL1 system register bits are implementation defined which means it is possibly a latent bug on current HW as the CPU implementer may already have decided to use the top 32bit. Signed-off-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of register cntkctl to register_t. Thumbee registers are only usable by a 32-bit domain and therefore we can just store the bottom 32-bit (IOW there is no type change). In fact, this could technically be restricted to Armv7 HW (the support was dropped retrospectively in Armv8) but leave it as-is for now. Signed-off-by:
-
Michal Orzel authored
AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of FPCR, FPSR, FPEXC32_EL2 to register_t. Signed-off-by:
-
According to syslog(3) the fmt string does not need a newline. The mini-os implementation of syslog requires the trailing newline. Other calls to syslog do include the newline already, add it also to WRL_LOG. Signed-off-by:
Olaf Hering <olaf@aepfle.de>
Reviewed-by: -
Add two patches: vtpm-microsecond-duration.patch fixes the units for timeouts and command durations. vtpm-command-duration.patch increases the timeout linux uses to allow commands to succeed. Linux works around low timeouts, but not low durations. The second patch allows commands to complete that often timeout with the lower command durations. Signed-off-by:
Jason Andryuk <jandryuk@gmail.com> Reviewed-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by:
Daniel P. Smith <dpsmith@apertussolutions.com>
-
vtpm_handle_cmd doesn't ensure there is enough space before unpacking the req buffer. Add a minimum size check. Called functions will have to do their own checking if they need more data from the request. The error case is tricky since abort_egress wants to rely with a corresponding tag. Just hardcode TPM_TAG_RQU_COMMAND since the vtpm is sending in malformed commands in the first place. Signed-off-by:
-
Argument parsing only matches to before ':' and then the string with leading ':' is passed to parse_auth_string which fails to parse. Extend the length to include the seperator in the match. While here, switch the seperator to "=". The man page documented "=" and the other tpm.* arguments already use "=". Since it didn't work before, we don't need to worry about backwards compatibility. Signed-off-by:
-
The UINT32 <-> UINT16 casting in TPM2_GetRandom is incorrect. Use a local UINT16 as needed for the TPM hardware command and assign the result. Suggested-by:
-
GetRandom passthrough currently fails when using vtpmmgr with a hardware TPM 2.0. vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom vtpm (12): vtpm_cmd.c:120: Error: TPM_GetRandom() failed with error code (30) When running on TPM 2.0 hardware, vtpmmgr needs to convert the TPM 1.2 TPM_ORD_GetRandom into a TPM2 TPM_CC_GetRandom command. Besides the differing ordinal, the TPM 1.2 uses 32bit sizes for the request and response (vs. 16bit for TPM2). Place the random output directly into the tpmcmd->resp and build the packet around it. This avoids bouncing through an extra buffer, but the header has to be written after grabbing the random bytes so we have the number of bytes to include in the size. Signed-off-by:
-
vtpmmgr uses the default, weak app_shutdown, which immediately calls the shutdown hypercall. This short circuits the vtpmmgr clean up logic. We need to perform the clean up to actually Flush our key out of the tpm. Setting do_shutdown is one step in that direction, but vtpmmgr will most likely be waiting in tpmback_req_any. We need to call shutdown_tpmback to cancel the wait inside tpmback and perform the shutdown. Signed-off-by:
Samuel Thibault <samuel.thibaut@ens-lyon.org> Reviewed-by:
-
We're only flushing 2 transients, but there are 3 handles. Use <= to also flush the third handle since TRANSIENT_LAST is inclusive The number of transient handles/keys is hardware dependent, so this should query for the limit. And assignment of handles is assumed to be sequential from the minimum. That may not be guaranteed, but seems okay with my tpm2. Signed-off-by:
-
Remove our key so it isn't left in the TPM for someone to come along after vtpmmgr shutsdown. Signed-off-by:
-
Bypass taking ownership of the TPM2 if an srk_handle is specified. This srk_handle must be usable with Null auth for the time being. Signed-off-by:
-
- 07 May, 2021 7 commits
-
-
Reposition vtpmmgr_shutdown so it can call flush_tpm2 without a forward declaration. Signed-off-by:
-
vtpmmgr was changed to print size_t with the %z modifier, but newlib isn't compiled with %z support. So you get output like: root seal: zu; sector of 13: zu root: zu v=zu itree: 36; sector of 112: zu group: zu v=zu id=zu md=zu group seal: zu; 5 in parent: zu; sector of 13: zu vtpm: zu+zu; sector of 48: zu Enable the C99 formats in newlib so vtpmmgr prints the numeric values. Fixes: 9379af08 ("stubdom: vtpmmgr: Correctly format size_t with %z when printing.") Signed-off-by:
-
tpm_get_error_name returns "Unknown Error Code" when an error string is not defined. In that case, we should print the Error Code so it can be looked up offline. tpm_get_error_name returns a const string, so just have the two callers always print the error code so it is always available. Signed-off-by:
-
The vtpmmgr TPM 2.0 support is incomplete. Add a warning about that to the documentation so others don't have to work through discovering it is broken. Signed-off-by:
Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by:
-
--log does not take a file, it specifies what is supposed to be logged. Also separate the XENSTORED and XENCONSOLED variables by a newline. Signed-off-by:
Olaf Hering <olaf@aepfle.de>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
-
Jan Beulich authored
The current use of xzalloc_bytes() in optee is nearly an open-coded version of xzalloc_flex_struct(), which was introduced after the driver was merged. The main difference is xzalloc_bytes() will also force the allocation to be SMP_CACHE_BYTES aligned and therefore avoid sharing the cache line. While sharing the cache line can have an impact on the performance, this is also true for most of the other users of x*alloc(), x*alloc_array(), and x*alloc_flex_struct(). So if we want to prevent sharing cache lines, arranging for this should be done in the allocator itself. In this case, we don't need stricter alignment than what the allocator provides. Hence replace the call to xzalloc_bytes() with one of xzalloc_flex_struct(). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Julien Grall <julien@xen.org> Acked-by:
-
Restore setting the virtual timer callback private data to NULL if the timer is not level triggered. This fixes the special casing done in pt_update_irq so that the RTC interrupt when originating from the HPET is suspended if the interrupt source is masked. Note the RTC special casing done in pt_update_irq should only apply to the RTC interrupt originating from the emulated RTC device (which does set the callback private data), as in that case the callback itself will destroy the virtual timer if the interrupt is ignored. While there also use RTC_IRQ instead of 8 when the HPET is configured in LegacyReplacement Mode. Fixes: be07023b ("x86/vhpet: add support for level triggered interrupts") Reported-by:
-
- 05 May, 2021 4 commits
-
-
Move a few #ifdef-s, to account for diagnostics like p2m.c:549:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type] which appear despite paging_mode_translate() resolving to constant "false" when !HVM. All of the affected functions are intended to become fully HVM-only anyway, with their non-translated stub handling split off elsewhere. Fixes: 8d012d3d ("x86/p2m: {get,set}_entry hooks and p2m-pt.c are HVM-only") Reported-by:
-
Andrew Cooper authored
It is bad form in C, perhaps best demonstrated by trying to read xc_cpu_policy_destroy(), and causes const qualification to have less-than-obvious behaviour (the hidden pointer becomes const, not the thing it points at). xc_cpu_policy_set_domain() needs to drop its (now normal) const qualification, as the policy object is modified by the serialisation operation. This also shows up a problem with the x86_cpu_policies_are_compatible(), where the intermediate pointers are non-const. Signed-off-by:
-
Julien Grall authored
literal strings are not meant to be modified. So we should use const char * rather than char * when we want to store a pointer to them. Signed-off-by:
Anthony PERARD <anthony.perard@citrix.com>
-
Wei Liu authored
It is reported that failed randconfig runs are missing the config file which makes debugging impossible. Fix this by moving the line that copies the config file before the build is executed. Signed-off-by:
Wei Liu <wl@xen.org> Acked-by:
-
- 04 May, 2021 2 commits
-
-
Andrew Cooper authored
The latter is a more descriptive name, as it explicitly highlights the query from hardware. Simplify the internal logic using cpuid_count_ebx(), and drop the curr/max assertion as this property is guaranteed by the x86 ISA. Signed-off-by:
-
Andrew Cooper authored
XSETBV is an expensive instruction as, amongst other things, it involves reconfiguring the instruction decode at the frontend of the pipeline. We have several paths which reconfigure %xcr0 in quick succession (the context switch path has 5, including the fpu save/restore helpers), and only a single caller takes any care to try to skip redundant writes. Update set_xcr0() to perform amortisation automatically, and simplify the __context_switch() path as a consequence. Signed-off-by:
-
