In this case compat headers don't get generated (and aren't needed).
The changes made by 527922008bce ("x86: slim down hypercall handling
when !PV32") also weren't quite sufficient for this case.
Try to limit #ifdef-ary by introducing two "fallback" #define-s.
Fixes: d23d792478db ("x86: avoid bui
flight 161817 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi Julien,
> From: Julien Grall
> On 28/04/2021 10:28, Henry Wang wrote:
> > Hi Julien,
>
> Hi Henry,
>
> >
> > I've done some test about the patch series in
> > https://xenbits.xen.org/gitweb/?p=people/julieng/xen-
> unstable.git;a=shortlog;h=refs/heads/pt/rfc-v2
> >
>
> Thanks you for the te
flight 161812 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
OP-TEE mediator already have support for NULL memory references. It
was added in patch 0dbed3ad336 ("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 o
flight 161811 xen-unstable real [real]
flight 161822 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161811/
http://logs.test-lab.xenproject.org/osstest/logs/161822/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
flight 161807 xen-4.12-testing real [real]
flight 161819 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161807/
http://logs.test-lab.xenproject.org/osstest/logs/161819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 161814 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161814/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 880092854e5473558af77289bb7c01a9fa9dda5a
baseline version:
xtf 2cf3168661355565e2b803
On Thu, May 06, 2021 at 02:36:54PM +, Phillip Susi wrote:
> For reasons I still don't understand, the input subsystem allows
> input devices to advertise what keys they have, and adds this
> information to the modalias for the device. The Xen Virtual
> Keyboard was advertising every known key,
flight 161799 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ws16-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xen
On 06/05/2021 16:17, Olaf Hering wrote:
> --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
Acked-by: Andrew Cooper
On 06/05/2021 16:16, Olaf Hering wrote:
> The sysconfig variable XENSTORED_ROOTDIR is not used anymore.
> It used to point to a directory with tdb files, which is now a tmpfs.
>
> In case the database is not in tmpfs, like on sysv and BSD systems,
> xenstored will truncate existing database files d
osstest service owner writes ("[xen-4.12-testing test] 161776: regressions -
FAIL"):
> flight 161776 xen-4.12-testing real [real]
> flight 161806 xen-4.12-testing real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/161776/
> http://logs.test-lab.xenproject.org/osstest/logs/161806
From: Julien Grall
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
--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
---
tools/hotplug/FreeBSD/rc.d/xencommons.in | 5 +++--
tools/hotplug/NetBSD/rc.d/xencommons.in | 5 +++--
2 files changed, 6 i
The sysconfig variable XENSTORED_ROOTDIR is not used anymore.
It used to point to a directory with tdb files, which is now a tmpfs.
In case the database is not in tmpfs, like on sysv and BSD systems,
xenstored will truncate existing database files during start.
Fixes commit 2ef6ace428dec4795b8b0a
On 06.05.2021 16:43, Luca Fancellu wrote:
>> On 6 May 2021, at 10:58, Jan Beulich wrote:
>> On 06.05.2021 10:48, Luca Fancellu wrote:
On 4 May 2021, at 23:27, Stefano Stabellini wrote:
On Tue, 4 May 2021, Luca Fancellu wrote:
> @@ -51,13 +55,10 @@
> * know the real machine addre
> On 6 May 2021, at 10:58, Jan Beulich wrote:
>
> On 06.05.2021 10:48, Luca Fancellu wrote:
>>> On 4 May 2021, at 23:27, Stefano Stabellini wrote:
>>> On Tue, 4 May 2021, Luca Fancellu wrote:
@@ -51,13 +55,10 @@
* know the real machine address of a page it is sharing. This makes
>>>
On 06/05/2021 11:42, Julien Grall wrote:
From: Julien Grall
Looks good in general... just a few comments below...
Administrators often require updating the Xen hypervisor to address
security vulnerabilities, introduce new features, or fix software defects.
Currently, we offer the following
For reasons I still don't understand, the input subsystem allows
input devices to advertise what keys they have, and adds this
information to the modalias for the device. The Xen Virtual
Keyboard was advertising every known key, which resulted in a
modalias string over 2 KiB in length, which cause
Am Tue, 4 May 2021 18:47:12 +0100
schrieb Andrew Cooper :
> I'd also be tempted to fold this and the NetBSD change together. It's
> not as if these bugfixes are distro-specific.
I will redo the BSD patches as you suggested.
Olaf
pgpl9o7VzEidt.pgp
Description: Digitale Signatur von OpenPGP
On 06/05/2021 14:09, Jan Beulich wrote:
> On 06.05.2021 14:47, George Dunlap wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -55,7 +55,7 @@ config PV
>> config PV32
>> bool "Support for 32bit PV guests"
>> depends on PV
>> -default y
>> +default PV_SHIM
>
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 h
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 alread
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
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: Samuel Thibault
Signed-off-by: Jason Andryuk
---
stubdom/vtpmmgr/tpm2.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions
On Thu, May 6, 2021 at 10:00 AM Jason Andryuk wrote:
>
> 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_shutd
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_GetRand
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 b
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 minimu
Remove our key so it isn't left in the TPM for someone to come along
after vtpmmgr shutsdown.
Signed-off-by: Jason Andryuk
Reviewed-by: Samuel Thibault
---
stubdom/vtpmmgr/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index de
Reposition vtpmmgr_shutdown so it can call flush_tpm2 without a forward
declaration.
Signed-off-by: Jason Andryuk
Reviewed-by: Samuel Thibault
---
stubdom/vtpmmgr/init.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/stubdom/vtpmmgr/init.c b/s
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: Jason Andryuk
---
v2: Use "=" seperator
---
docs/man/xen-vtpmmgr.7.pod | 7 +++
stubdom/vtpmmgr/init.c | 11 ++-
2 files changed,
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
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-
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: Jason Andryuk
Acked-by: Andrew Cooper
---
docs/man/xen-vtpmmgr.7.pod | 11 +++
1 file changed, 11 insertions(+)
diff -
vtpmmgr TPM 2.0 support is incomplete. There is no code to save the
tpm2 keys generated by the vtpmmgr, so it's impossible to restore vtpm
state with tpm2. The vtpmmgr also issues TPM 1.2 commands to the TPM
2.0 hardware which naturally fails. Dag reported this [1][2], and I
independently re-dis
On 06.05.2021 14:47, George Dunlap wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -55,7 +55,7 @@ config PV
> config PV32
> bool "Support for 32bit PV guests"
> depends on PV
> - default y
> + default PV_SHIM
> select COMPAT
> ---help---
>
Hi Jan,
On 06/05/2021 07:21, Jan Beulich wrote:
On 05.05.2021 19:35, Julien Grall wrote:
On 29/04/2021 14:26, Jan Beulich wrote:
On 29.04.2021 13:27, Julien Grall wrote:
On 21/04/2021 11:22, Jan Beulich wrote:
While for the original library's purposes these functions of course want
to be e
The support status of 32-bit guests doesn't seem particularly useful.
With it changed to fully unsupported outside of PV-shim, adjust the PV32
Kconfig default accordingly.
Reported-by: Jann Horn
Signed-off-by: George Dunlap
Signed-off-by: Jan Beulich
---
v2:
- add in Kconfig from advisory, po
> On May 6, 2021, at 1:29 PM, George Dunlap wrote:
>
> The support status of 32-bit guests doesn't seem particularly useful.
>
> Signed-off-by: George Dunlap
> ---
>
> NB this patch should be considered a proposal to the community, as a
> follow-on to XSA-370. As mentioned in the advisory,
flight 161780 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
The support status of 32-bit guests doesn't seem particularly useful.
Signed-off-by: George Dunlap
---
NB this patch should be considered a proposal to the community, as a
follow-on to XSA-370. As mentioned in the advisory, we will wait
until 25 May for comments before checking it in.
---
SUPP
flight 161778 xen-unstable real [real]
flight 161809 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161778/
http://logs.test-lab.xenproject.org/osstest/logs/161809/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 06.05.2021 12:23, Roger Pau Monné wrote:
> On Wed, May 05, 2021 at 09:42:09AM +0200, Jan Beulich wrote:
>> On 04.05.2021 17:34, Roger Pau Monné wrote:
>>> On Mon, May 03, 2021 at 01:09:41PM +0200, Jan Beulich wrote:
On 30.04.2021 17:52, Roger Pau Monne wrote:
> @@ -1086,3 +1075,42 @@ in
From: Julien Grall
Administrators often require updating the Xen hypervisor to address
security vulnerabilities, introduce new features, or fix software defects.
Currently, we offer the following methods to perform the update:
* Rebooting the guests and the host: this is highly disrupting to
From: Julien Grall
Hi all,
A couple of years ago, AWS presented at Xen Summit [1] a new method called
"Live Update" to replace the underlying the hypervisor without
rebooting/migrating VMs.
Since then we worked on implementing the feature in Xen and now have
a working PoC. This series is a spl
From: Julien Grall
Unfortunately, the code to support Live Update has already been merged in
Kexec and shipped since 2.0.21. Reserve the IDs used by Kexec before they
end up to be re-used for a different purpose.
This patch reserves two IDs:
* KEXEC_TYPE_LIVEUPDATE: New operation to request
On Wed, May 05, 2021 at 09:42:09AM +0200, Jan Beulich wrote:
> On 04.05.2021 17:34, Roger Pau Monné wrote:
> > On Mon, May 03, 2021 at 01:09:41PM +0200, Jan Beulich wrote:
> >> On 30.04.2021 17:52, Roger Pau Monne wrote:
> >>> @@ -1086,3 +1075,42 @@ int xc_cpu_policy_calc_compatible(xc_interface
>
On 06.05.2021 10:48, Luca Fancellu wrote:
>> On 4 May 2021, at 23:27, Stefano Stabellini wrote:
>> On Tue, 4 May 2021, Luca Fancellu wrote:
>>> @@ -51,13 +55,10 @@
>>> * know the real machine address of a page it is sharing. This makes
>>> * it possible to share memory correctly with domains run
Do this before adding any more stuff to xg_cpuid_x86.c.
The placement in xenctrl.h is wrong, as they are implemented by the
xenguest library. Note that xg_cpuid_x86.c needs to include
xg_private.h, and in turn also fix xg_private.h to include
xc_bitops.h. The bitops definition of BITS_PER_LONG nee
> On 4 May 2021, at 23:27, Stefano Stabellini wrote:
>
> On Tue, 4 May 2021, Luca Fancellu wrote:
>> Modification to include/public/grant_table.h:
>>
>> 1) Add doxygen tags to:
>> - Create Grant tables section
>> - include variables in the generated documentation
>> - Used @keepindent/@endkee
flight 161776 xen-4.12-testing real [real]
flight 161806 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161776/
http://logs.test-lab.xenproject.org/osstest/logs/161806/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 161804 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
55 matches
Mail list logo
