On 2/22/19 15:39, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4109,6 +4109,13 @@ static int hvmop_set_param(
>> if ( a.index >= HVM_NR_PARAMS )
>> return -EINVAL;
>>
>> +/*
>> + * Make sure the
On 2/22/19 14:17, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,38 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef _ASM_X
flight 133393 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133393/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
Warn whenever a switch statement does not have a default case.
Will you be ok to turn this particu
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 22 February 2019 19:13
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun Nakajima
> ; Kevin Tian
> Subject: [PATCH 2/6] x86/vtd: Rename struct iommu to vtd_iommu
>
> VT-d's local
On 2/22/19 16:08, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> @@ -226,10 +228,18 @@ nr_maptrack_frames(struct grant_table *t)
>> static grant_entry_header_t *
>> shared_entry_header(struct grant_table *t, grant_ref_t ref)
>> {
>> -if ( t->gt_version == 1 )
>> +switch ( t->gt
On 2/23/19 1:34 AM, Julien Grall wrote:
Hi,
On 22/02/2019 22:38, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 2
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 22 February 2019 19:13
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> ; Kevin Tian
> Subject: [PATCH 3/6] x86/vtd: Drop struct qi_ctrl
>
> It is unclear why this abstraction exist
On 2/23/19 1:41 AM, Andrew Cooper wrote:
On 22/02/2019 23:22, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 21:00,
> -Original Message-
[snip]
> struct iommu_flush {
> int __must_check (*context)(void *iommu, u16 did, u16 source_id,
> u8 function_mask, u64 type,
> @@ -523,7 +517,6 @@ struct iommu_flush {
> };
>
> struct intel_iommu {
> -struct ir_ctrl ir_ctr
On 2/23/19 12:08 AM, Julien Grall wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 22 February 2019 19:13
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> ; Kevin Tian
> Subject: [PATCH 5/6] x86/vtd: Drop struct iommu_flush
>
> It is unclear why this abstraction
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 22 February 2019 19:13
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> ; Kevin Tian
> Subject: [PATCH 6/6] x86/vtd: Drop struct intel_iommu
>
> The sole remaining member of struct
On 2/23/19 1:13 AM, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22
flight 133412 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-i386-libvirt
Hi,
On 25/02/2019 10:27, Oleksandr Andrushchenko wrote:
On 2/23/19 1:13 AM, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
>>> On 25.02.19 at 11:02, wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 22 February 2019 19:13
>>
>> --- a/xen/drivers/passthrough/vtd/qinval.c
>> +++ b/xen/drivers/passthrough/vtd/qinval.c
>> @@ -84,7 +84,7 @@ static int __must_check
>> queue_invalidate_context_sync(
>>> On 25.02.19 at 11:09, wrote:
>> -Original Message-
> [snip]
>> struct iommu_flush {
>> int __must_check (*context)(void *iommu, u16 did, u16 source_id,
>> u8 function_mask, u64 type,
>> @@ -523,7 +517,6 @@ struct iommu_flush {
>> };
>>
>> stru
On 25/02/2019 10:59, Jan Beulich wrote:
On 25.02.19 at 11:02, wrote:
>>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>>> Sent: 22 February 2019 19:13
>>>
>>> --- a/xen/drivers/passthrough/vtd/qinval.c
>>> +++ b/xen/drivers/passthrough/vtd/qinval.c
>>> @@ -84,7 +84,7 @@ static int _
Hi Oleksandr,
On 25/02/2019 10:00, Oleksandr Andrushchenko wrote:
On 2/23/19 1:34 AM, Julien Grall wrote:
What are the consequences of not following them in Xen Project? I
know that some upstream project chose to not apply to all the rules.
Not all of the upstream projects want to be certifi
Hi,
On 25/02/2019 10:06, Oleksandr Andrushchenko wrote:
On 2/23/19 1:41 AM, Andrew Cooper wrote:
On 22/02/2019 23:22, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fr
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
Warn whenever a switch statement does not
Don't emit the "ignored" warning when there's no placement specification
and the tail of the specified option is actually empty.
Signed-off-by: Jan Beulich
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -173,7 +173,7 @@ static int __init parse_crashkernel(cons
kexec_crash_area
>>> On 25.02.19 at 12:07, wrote:
> On 25/02/2019 10:59, Jan Beulich wrote:
> On 25.02.19 at 11:02, wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: 22 February 2019 19:13
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/q
On 2/25/19 1:08 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 10:00, Oleksandr Andrushchenko wrote:
On 2/23/19 1:34 AM, Julien Grall wrote:
What are the consequences of not following them in Xen Project? I
know that some upstream project chose to not apply to all the rules.
Not all of
Hey Lars
If you want some help putting the business case together at the top of Day 1, I
am more than happy to help with that. Also, should we have some discussion
around the Elisa project and if there should be any cross working between Xen
and that group?
/Matt
_
On Fri, Feb 22, 2019 at 7:15 PM Andrew Cooper wrote:
>
> iremap_maddr and qinval_maddr point to the base of a block of contiguous RAM,
> allocated by the driver, holding the Interrupt Remapping table, and the Queued
> Invalidation ring.
>
> Despite their name, they are actually the values of the h
>>> On 22.02.19 at 22:33, wrote:
> P.S. There is a solution here which could work, but IMO a better use of
> time and energy would be to get MISRA to update their rules to match
> this century, and stop getting in the way of compiler features intended
> to help the programmer avoid bugs.
As much
On 07/01/2019 10:52, Jan Beulich wrote:
>> diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
>> index 5a3159b..7fc4148 100644
>> --- a/xen/lib/x86/cpuid.c
>> +++ b/xen/lib/x86/cpuid.c
>> @@ -233,6 +233,112 @@ int x86_cpuid_copy_to_buffer(const struct cpuid_policy
>> *p,
>> return 0;
>>
flight 83665 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83665/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Hi,
On 22/02/2019 10:27, Andrew Cooper wrote:
On 22/02/2019 09:57, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, everybody!
We at EPAM Systems would like to present first series of patches targeting Xen
on ARM Functional Safety certification (ISO61508 based): implementa
On 2/25/19 1:10 PM, Julien Grall wrote:
Hi,
On 25/02/2019 10:06, Oleksandr Andrushchenko wrote:
On 2/23/19 1:41 AM, Andrew Cooper wrote:
On 22/02/2019 23:22, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/201
Hi,
On 25/02/2019 10:11, Oleksandr Andrushchenko wrote:
On 2/23/19 12:08 AM, Julien Grall wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
As 16.4 clearly state, even a simple comm
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
Hi Matt,
> If you want some help putting the business case together at the top of Day 1,
> I am more than happy to help with that.
thank you, that would be appreciated. Artem and Alex are also looking at
helping. But nothing is set in stone: I will fire off
> Also, should we have some discuss
On 25/02/2019 11:23, Jan Beulich wrote:
> Don't emit the "ignored" warning when there's no placement specification
> and the tail of the specified option is actually empty.
>
> Signed-off-by: Jan Beulich
What command line triggers this?
~Andrew
>
> --- a/xen/common/kexec.c
> +++ b/xen/common/ke
On 07/01/2019 11:19, Jan Beulich wrote:
On 04.01.19 at 16:33, wrote:
>> The AFL harness currently notices that there are cases where we optimse the
>> serialised stream by omitting data beyond the various maximum leaves.
>>
>> Both sets of tests will be extended with further libx86 work.
>>
>
On 2/25/19 1:47 PM, Julien Grall wrote:
Hi,
On 25/02/2019 10:11, Oleksandr Andrushchenko wrote:
On 2/23/19 12:08 AM, Julien Grall wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
A
On 2/25/19 1:43 PM, Julien Grall wrote:
Hi,
On 22/02/2019 10:27, Andrew Cooper wrote:
On 22/02/2019 09:57, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, everybody!
We at EPAM Systems would like to present first series of patches
targeting Xen
on ARM Functional Safety
>>> On 25.02.19 at 12:47, wrote:
> For enum, a compiler supporting -Wswitch can helps us to catch when we forgot
> to
> handle a element of the enum. The default case defeats -Wswitch. Yet having a
> default could protect us against code error. It looks like that GCC have an
> option -Wswitch-
>>> On 25.02.19 at 12:49, wrote:
> I am not defending BUG() in any way which is obviously a no-go.
> I am just trying to say that BUG() usage in the existing code needs to be
> fixed first. Once done, we can then move to "default" w/o BUG()
Why? A first step to not make things worse is to not int
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I c
>>> On 25.02.19 at 12:52, wrote:
> On 25/02/2019 11:23, Jan Beulich wrote:
>> Don't emit the "ignored" warning when there's no placement specification
>> and the tail of the specified option is actually empty.
>>
>> Signed-off-by: Jan Beulich
>
> What command line triggers this?
crashkernel=1G-
>>> On 25.02.19 at 12:56, wrote:
> On 07/01/2019 11:19, Jan Beulich wrote:
> On 04.01.19 at 16:33, wrote:
>>> The AFL harness currently notices that there are cases where we optimse the
>>> serialised stream by omitting data beyond the various maximum leaves.
>>>
>>> Both sets of tests will b
Hey Lars
Sure, I think Kate would be a good speaker for this event. She can share the
scope of ELISA and help us to reduce process duplication if possible. We don't
need to solve all of the problems ourselves!
/Matt
From: Lars Kurth
Sent: 25 February 2019 11:
On 2/25/19 2:11 PM, Jan Beulich wrote:
On 25.02.19 at 12:49, wrote:
I am not defending BUG() in any way which is obviously a no-go.
I am just trying to say that BUG() usage in the existing code needs to be
fixed first. Once done, we can then move to "default" w/o BUG()
Why? A first step to not
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 2
On 2/22/19 14:00, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> @@ -813,6 +817,7 @@ int set_global_virq_handler(struct domain *d, uint32_t
>> virq)
>>
>> if (virq >= NR_VIRQS)
>> return -EINVAL;
>> +
>> if (!virq_is_global(virq))
>> return -EINVAL;
>>
> S
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 2/25/19 2:50 PM, Julien Grall wrote:
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
O
>>> On 23.02.19 at 00:48, wrote:
> On 2/22/19 5:44 PM, Andrew Cooper wrote:
>> On 22/02/2019 21:58, Boris Ostrovsky wrote:
>>> On 2/22/19 4:13 PM, Andrew Cooper wrote:
vPMU isn't security supported, and in general guests can't access any of
the
performance counter MSRs. However, t
On 23.02.19 15:05, Amit Tomer wrote:
Hello,
Hi
Did removing reserved-memory regions together with users work out well
for you?
Removing "reserved-memory" node along with "mmngr" worked well. Tested it
with v3.15 BSP release.
ok
Also, just tried loading XEN from one of your branch[1
The regression/ directory was identified as already broken in 2012 (c/s
953953cc5). The logic is intended to test *.py files in the Xen tree against
different versions of python, but every identified version is now obsolete.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Juer
Hi,
On 25/02/2019 13:06, Oleksandr Andrushchenko wrote:
On 2/25/19 2:50 PM, Julien Grall wrote:
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
H
On 22/02/2019 16:10, Jan Beulich wrote:
> Since we can't seem to be able to settle our discussion for the wider
> adjustment previously posted, let's at least add the missing dependency
> for 4.12. I'm not convinced though that attaching it to SSE is correct.
>
> Signed-off-by: Jan Beulich
Acked-
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to
introduce one atomic field per event to record the number of event
received. I will explore tha
Despite all the other desirable adjustments I think the proposed change
is worthwhile in its own right. I certainly don't mean to extend the scope
of the change, and feedback so far hasn't really pointed out anything
that needs to change _within_ its scope.
Jan
>>> On 06.02.19 at 11:54, wrote:
>
On 2/25/19 3:22 PM, Julien Grall wrote:
Hi,
On 25/02/2019 13:06, Oleksandr Andrushchenko wrote:
On 2/25/19 2:50 PM, Julien Grall wrote:
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
O
On 25/02/2019 12:14, Jan Beulich wrote:
On 25.02.19 at 12:52, wrote:
>> On 25/02/2019 11:23, Jan Beulich wrote:
>>> Don't emit the "ignored" warning when there's no placement specification
>>> and the tail of the specified option is actually empty.
>>>
>>> Signed-off-by: Jan Beulich
>> What
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
When interacting with io apic, a guest can specify values that are used
as index to structures, and whose values are not compared against
upper bounds to prevent speculative out-of-bound accesses. This change
prevents these speculative accesses.
Furthermore, variables are initialized and the compi
Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
might be bypassed by speculatively executing these instructions. A reason
for bypassing these checks is that these macros access the domain
structure via a pointer, and check a certain field. Since this memory
access is slow,
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros,
or the domain_vcpu function. Where appropriate, we use the vcpu_id of
the seleceted vcpu instead of the parameter that can be influenced by
the guest, so that
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by:
The get_page_from_gfn method returns a pointer to a page that belongs
to a gfn. Before returning the pointer, the gfn is checked for being
valid. Under speculation, these checks can be bypassed, so that
the function get_page is still executed partially. Consequently, the
function page_get_owner_and
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
speculative out-of-bound accesses, we use the array_index_nospec macro
where applicable. However, there are also memory accesses that cannot
be protected by a single
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problematic, because when hyperthreading is used as well, a
guest running on the sibling core can leak this potentially secret data.
To prevent these speculative accesses, we block speculation after
accessing the
To control the runtime behavior on L1TF vulnerable platforms better, the
command line option l1tf-barrier is introduced. This option controls
whether on vulnerable x86 platforms the lfence instruction is used to
prevent speculative execution from bypassing the evaluation of
conditionals that are pr
The params array in hvm can be accessed with get and set functions.
As the index is guest controlled, make sure no out-of-bound accesses
can be performed.
As we cannot influence how future compilers might modify the
instructions that enforce the bounds, we furthermore block speculation,
so that th
Hi,
On 25/02/2019 13:32, Oleksandr Andrushchenko wrote:
On 2/25/19 3:22 PM, Julien Grall wrote:
Why? If we *first* deal with BUG() and *then* introduce "defaults" patch
which will use the already fixed code?
This is not how your e-mail came out. It came out as it is fine to add
"default" with
On 2/25/19 3:40 PM, Julien Grall wrote:
Hi,
On 25/02/2019 13:32, Oleksandr Andrushchenko wrote:
On 2/25/19 3:22 PM, Julien Grall wrote:
Why? If we *first* deal with BUG() and *then* introduce "defaults"
patch
which will use the already fixed code?
This is not how your e-mail came out. It came
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to introduce one
atomic field p
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up
>>> On 31.01.19 at 11:47, wrote:
> @@ -105,6 +132,73 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
> uint64_t val)
> viridian_map_guest_page(d, &v->arch.hvm.viridian->vp_assist);
> break;
>
> +case HV_X64_MSR_SCONTROL:
> +if ( !(viridian_feature_mas
On 25/02/2019 13:11, Jan Beulich wrote:
On 23.02.19 at 00:48, wrote:
>> On 2/22/19 5:44 PM, Andrew Cooper wrote:
>>> On 22/02/2019 21:58, Boris Ostrovsky wrote:
On 2/22/19 4:13 PM, Andrew Cooper wrote:
> vPMU isn't security supported, and in general guests can't access any of
>
Hi Julien
While I know that Xen does not deal with reserved area yet, we should
have been
able to write in that region. We don't even reach that state as we
can't get the
associated page.
It might be possible that the p2m entry is overwritten when going
through the DT
for mapping all the
>>> On 31.01.19 at 11:47, wrote:
> --- a/xen/arch/x86/hvm/viridian/synic.c
> +++ b/xen/arch/x86/hvm/viridian/synic.c
> @@ -329,7 +329,53 @@ void viridian_synic_domain_deinit(struct domain *d)
>
> void viridian_synic_poll_messages(struct vcpu *v)
> {
> -/* There are currently no message sou
>>> On 31.01.19 at 11:47, wrote:
> @@ -659,7 +663,64 @@ int viridian_hypercall(struct cpu_user_regs *regs)
> status = HV_STATUS_SUCCESS;
> break;
> }
> +case HvSendSyntheticClusterIpi:
Missing blank line again, and one more at the end of this case block.
> +{
> +
The logic in xstate_init() is a rementent of the pre-featuremask days.
Collect the xstate features in generic_identify(), like all other feature
leaves, after which identify_cpu() will apply the known_feature[] mask derived
from the automatically generated CPUID information.
Signed-off-by: Andrew
This is an attempt to do a 'post-mortem' on XSA-283, to find out how
the error came about, and consider what changes we could make to code
/ processes to prevent such errors from happening in the future. The
Security Team hopes to make it a habit to perform such analyses in the
future.
As it happ
>>> On 25.02.19 at 14:33, wrote:
> On 25/02/2019 12:14, Jan Beulich wrote:
> On 25.02.19 at 12:52, wrote:
>>> On 25/02/2019 11:23, Jan Beulich wrote:
Don't emit the "ignored" warning when there's no placement specification
and the tail of the specified option is actually empty.
>>> On 25.02.19 at 15:11, wrote:
> On 25/02/2019 13:11, Jan Beulich wrote:
>> For Intel, afaics, we indeed produce a blank CPUID leaf in
>> all cases, so the behavior looks reasonably consistent. I would
>> question though whether a blank CPUID leaf / the absence of any
>> counters wouldn't call f
Hi Oleksandr,
On 25/02/2019 14:08, Oleksandr Andrushchenko wrote:
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, J
Andrew Cooper (2):
libx86: Introduce a helper to deserialise cpuid_policy objects
tools/cpu-policy: Add unit tests
Roger Pau Monné (1):
libx86: introduce a helper to deserialise msr_policy objects
tools/tests/Makefile | 1 +
tools/tests/cpu-policy/.gitignore|
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
v2:
* Avoid explicit type overlap.
* Fix comment.
* Use array_access_nospec(), with a dummy implementation for userspace
build
These will be extended with further libx86 work.
Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
unit tests.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
v2:
* Pospone the AFL fuzzer for now. It needs a bit
From: Roger Pau Monné
As with the serialise side, Xen's copy_from_guest API is used, with a
compatibility wrapper for the userspace build.
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey
We have about a 10% failure rate of a problem where the symptoms are
that the test box fails to get some thing from security.debian.org.
The apt-cacher-ng logs show the relevant test box's ip address
fetching the file that it is supposed to. But, it is possible that
there are different timeouts,
> On 25 Feb 2019, at 13:47, Oleksandr Andrushchenko wrote:
>
> On 2/25/19 3:40 PM, Julien Grall wrote:
>>
My point is not about sending such code on the mailing list. My point is
you need to provide as much as possible details in your cover letter so we
can be more efficient w
>>> On 25.02.19 at 14:34, wrote:
> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
> L1 cache is problematic, because when hyperthreading is used as well, a
> guest running on the sibling core can leak this potentially secret data.
>
> To prevent these speculative accesse
>>> On 25.02.19 at 14:34, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4109,6 +4109,11 @@ static int hvmop_set_param(
> if ( a.index >= HVM_NR_PARAMS )
> return -EINVAL;
>
> +/*
> + * Make sure the above bound check is not bypassed during specu
On Tue, Feb 19, 2019 at 04:36:28PM +, Paul Durrant wrote:
> > The locally allocated QDict-s need to be freed. ('file_layer' will be
> > freed implicitly since it is added as an object to 'driver_layer').
> >
> > Spotted by Coverity: CID 1398649
> >
> > While in the neighbourhood free 'driver'
>>> On 25.02.19 at 14:34, wrote:
> @@ -634,14 +649,24 @@ static unsigned int nr_grant_entries(struct grant_table
> *gt)
> case 1:
> BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 1) <
> GNTTAB_NR_RESERVED_ENTRIES);
> +
> +/* Make sure we return a value indep
Andrew Cooper writes ("[PATCH for-4.12] tools/tests: Drop obsolete test
infrastructure"):
> The regression/ directory was identified as already broken in 2012 (c/s
> 953953cc5). The logic is intended to test *.py files in the Xen tree against
> different versions of python, but every identified v
On Mon, Feb 25, 2019 at 11:42 AM Jan Beulich wrote:
>
> >>> On 22.02.19 at 22:33, wrote:
> > P.S. There is a solution here which could work, but IMO a better use of
> > time and energy would be to get MISRA to update their rules to match
> > this century, and stop getting in the way of compiler f
>>> On 25.02.19 at 16:03, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -414,6 +414,10 @@ static void generic_identify(struct cpuinfo_x86 *c)
>
> &c->x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)],
> &c->x86
On 2/21/19 4:50 PM, Roger Pau Monne wrote:
> Current callers pass the p2m to paging_write_p2m_entry, but the
> implementation specific handlers of the write_p2m_entry hook instead
> of a p2m get a domain struct due to the handling done in
> paging_write_p2m_entry.
>
> Change the code so that the i
On Fri, 22 Feb 2019, Julien Grall wrote:
> On 22/02/2019 22:34, Stefano Stabellini wrote:
> > On Fri, 22 Feb 2019, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 22/02/2019 21:58, Stefano Stabellini wrote:
> >>> On Fri, 22 Feb 2019, Andrew Cooper wrote:
> On 22/02/2019 21:00, Stefano Stabel
On Mon, 25 Feb 2019, Lars Kurth wrote:
> On 25 Feb 2019, at 13:47, Oleksandr Andrushchenko
> wrote:
>
> On 2/25/19 3:40 PM, Julien Grall wrote:
>
> My point is not about sending such code on the mailing
> list. My point is you need to
> provide as much
On 2/21/19 4:50 PM, Roger Pau Monne wrote:
> This is in preparation for also changing p2m_entry_modify to return an
> error code.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> ---
[snip]
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 04e9d81c
1 - 100 of 147 matches
Mail list logo
