On 2/25/19 11:34 PM, Julien Grall wrote:
Hi,
On 2/25/19 9:13 PM, Stefano Stabellini wrote:
I think it is fine to exploit compiler specific checks when available.
However, I don't think we should make any decisions on code correctness
based on the compiler checks that we introduce.
In other
On 14/02/2019 14:19, Jan Beulich wrote:
On 14.02.19 at 13:49, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3964,26 +3964,28 @@ static void hvm_s3_resume(struct domain *d)
>> }
>> }
>>
>> -static int hvmop_flush_tlb_all(void)
>> +bool
flight 133407 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade broken
test-xtf-amd64-amd64-3
flight 133430 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133430/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
flight 133421 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133421/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
flight 133406 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub broken
test-armhf-armhf-xl-vhd
flight 133399 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd broken
test-amd64-amd64-qemuu-nested-intel
Hi Oleksandr,
On 2/25/19 2:43 PM, Oleksandr wrote:
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
On Feb 25, 2019, at 10:14, George Dunlap wrote:
>
> 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
On Mon, 18 Feb 2019, Julien Grall wrote:
> Since commit 25eb5eec79 "xen: Fix inconsistent callers of panic()" all
> the panic message should end with a newline. Unfortunately, some
> commits pushed afterwards does not follow the rule.
>
> Modify the offending panic messages to avoid more
On Mon, 18 Feb 2019, Julien Grall wrote:
> The 3rd argument of function dt_property_read_u32() is only valid when
> the call succeeded. So we cannot assume the value will not be modifed
> in case of failure.
>
> The documentation of Dom0less does not give a default value when the
> property
On Mon, 18 Feb 2019, Julien Grall wrote:
> Commit 0bc6a68da5 "xen/arm: Replace call_smc with arm_smccc_smc"
> mistakenly forgot to populate arm_smccc_res. So a garbagge value was
^ garbage
> used as return value.
>
> Coverity-ID: 1476827
>
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
->
Hi,
On 2/25/19 9:13 PM, Stefano Stabellini wrote:
I think it is fine to exploit compiler specific checks when available.
However, I don't think we should make any decisions on code correctness
based on the compiler checks that we introduce.
In other words, I think it is a good idea to use
On 2/25/19 10:26 AM, Jan Beulich wrote:
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 /
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
->
On Mon, 25 Feb 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 25/02/2019 17:47, Stefano Stabellini wrote:
> > On Mon, 25 Feb 2019, George Dunlap wrote:
> > > 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
Use DEFINE_SYMBOL and the two static inline functions that come with it
for comparisons and subtractions of:
__note_gnu_build_id_start, __note_gnu_build_id_end,
__lock_profile_start, __lock_profile_end, __initcall_start,
__initcall_end, __presmp_initcall_end, __ctors_start, __ctors_end,
Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
subtractions of:
__2M_rwdata_start, __2M_rwdata_end, __end_vpci_array,
__start_vpci_array, _stextentry, _etextentry, __trampoline_rel_start,
__trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_stop
__per_cpu_start,
Introduce the new type "ptrdiff_t" which is defined as the signed
integer type of the result of subtracting two pointers. Use
__PTRDIFF_TYPE__ to define it.
Also, use __UINTPTR_TYPE__ for uintptr_t for consistency.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC:
Use DEFINE_SYMBOL and the two static inline functions that come with it
for comparisons and subtractions of:
__init_begin, __init_end, __alt_instructions, __alt_instructions_end,
__per_cpu_start, __per_cpu_data_end, _splatform, _eplatform, _sdevice,
_edevice, _asdevice, _aedevice.
Use explicit
Hi all,
This version of the series makes use of the macro suggested by Jan with
few modifications.
The main changes are:
- introduce the WHATEVER macro, named DEFINE_SYMBOL
- make use of the static inline functions to subtract and compare
pointers when possible
- when not possible, cast to
Use DEFINE_SYMBOL and the two static inline functions that come with it
for comparisons and subtractions of:
_start, _end, _stext, _etext, _srodata, _erodata, _sinittext,
_einittext
Use explicit casts to uintptr_t when it is not possible to use the
provided static inline functions.
M3CM:
Introduce a MACRO to be used to declare array variables corresponding to
linker symbols, plus two static inline functions to be used for
comparing and subtracting pointers with the linker symbols.
Note that the start and end symbols are declared of different types to
help avoid errors and
Newer AMD processors (F17h) have mwait support. Add some checks to make
sure vendor specific code is run correctly and some infrastructure to
facilitate adding AMD processors.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/mwait-idle.c | 25 +++--
1 file changed, 23
Add the needed data structures for enabling Naples (F17h M01h). Since
Rome (F17h M31h) has the same c-state latencies and entry methods, the
c-state information can be used for Rome as well. For both Naples and
Rome, mwait is used for c1 (cc1) and halt is functionally the same as
c2 (cc6). If
Some AMD processors can use a mixture of mwait and halt for accessing
various c-states. In preparation for adding support for AMD processors,
update the mwait-idle driver to optionally use halt.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/mwait-idle.c | 40
This patch series add support and enablement for mwait on AMD Naples
and Rome processors. Newer AMD processors support mwait, but only for
c1, and for c2 halt is used. The mwait-idle driver is modified to be
able to use both mwait and halt for idling.
Brian Woods (3):
mwait-idle: add support
On 25/02/2019 14:34, Norbert Manthey wrote:
> 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.
On 20/02/2019 16:15, Jan Beulich wrote:
> The assumption (according to one comment) and hope (according to
> another) that map_domain_page_global() can't fail are both wrong on
> large enough systems. Do away with the guest_vtable field altogether,
> and establish / tear down the desired mapping
On 25/02/2019 14:34, Norbert Manthey wrote:
> 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
On 25/02/2019 16:52, Ian Jackson wrote:
> 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,
On 25/02/2019 14:34, Norbert Manthey wrote:
> 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
flight 83667 examine real [real]
http://osstest.xensource.com/osstest/logs/83667/
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
On Wed, Feb 20, 2019 at 08:15:50PM +, Joao Martins wrote:
>
> Implement module_exit to allow users to do module unload of blkback.
> We prevent users from module unload whenever there are still interfaces
> allocated, in other words, do module_get on xen_blkif_alloc() and
> module_put on
flight 133398 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl-credit2
flight 133404 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133404/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-amd64-i386-libvirt-xsm
The logic currently tries to work out if a recent overflow (that indicates
that NMI comes from the watchdog) happened by checking MSB of performance
counter MSR that is initially sign extended from a negative value
that we program it to. A possibly incorrect assumption here is that
MSB is always
Hi all:
a quick note the we have *not* been accepted into GSoC this year (the current
acceptance rate seems to be that projects get GSOC slots every 3 years). A big
thank you to those who contributed to the project list.
This does not mean that there won't be Xen related projects. There are a
On 22/02/2019 17:34, Oleksandr wrote:
Hi, Julien
Hi Oleksandr,
Your solution below require to overwrite EARLY_PRINTK_INC and not very easy
to extend of other version (e.g scifb). As I suggested earlier, we can
introduce an option the same way REG_SHIFT exist for 8250. The definition of
Hi Stefano,
On 25/02/2019 17:47, Stefano Stabellini wrote:
On Mon, 25 Feb 2019, George Dunlap wrote:
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
On 25/02/2019 17:01, Jan Beulich wrote:
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)
>>
>>
Slight correction: in March daylight saving comes into effect with DST in
Europe starting March 31st and in the US March 10th. This means the meeting
times in March will be slightly off. Thank you to Stefano for spotting this
> ## Meeting time
> 16:00 - 17:00 UTC
> 8:00 - 9:00 EDT (San
Hi all,
I had an action to determine the best day for community calls going forward:
Wednesday clashes with a meeting that Andrew has to attend. This was a
consequence of moving the meeting to the following time slot
## Meeting time
16:00 - 17:00 UTC
8:00 - 9:00 EDT (San Francisco)
11:00 -
On Mon, 25 Feb 2019, George Dunlap wrote:
> 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
> > >
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
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
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
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
>>> 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)
>
> >x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)],
>
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
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
>>> 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
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
>>> 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
>>> 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
> 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
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,
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
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
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:
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|
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,
>>> 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
>>> 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.
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
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
>>> 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.
> +{
> +
>>> 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
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 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
>
>>> 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, >arch.hvm.viridian->vp_assist);
> break;
>
> +case HV_X64_MSR_SCONTROL:
> +if (
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
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
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
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
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
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
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
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:
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
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
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
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:
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/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
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
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:
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:
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
>>> 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,
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:
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/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;
>>
>
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,
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
1 - 100 of 145 matches
Mail list logo
