ing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
consider smt and l1dflush in auto setting for l1tf-barrier
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/s
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), namely to avoid
touching memory from the hypervisor speculatively that would not be touched
without speculation. To block speculative execution on Intel
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
change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit messate
drop system.h include
drop arch prefix
add outer brackets
: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: add speculative hardening to commit message
add lfence to a.index updates (other parts of that commit have
been committed already
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
, speculative
execution might perform out-of-bound accesses of version 2 while
the table is actually using version 1. Hence, speculation is prevented
when accessing memory based on the grant table version.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes
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
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/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
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
hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
xen/arch/x86/hvm/vioapic.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
--- a
: Norbert Manthey
Acked-by: Jan Beulich
---
Notes:
v8: added acked-by
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10
only one access needs to be protected.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
drop blank line change
xen/common/event_channel.c | 28 +---
xen/common
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
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
, speculative
execution might perform out-of-bound accesses of version 2 while
the table is actually using version 1. Hence, speculation is prevented
when accessing memory based on the grant table version.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes
change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
Notes:
v8: add acked-by
replace macros with inline functions (ARM)
replace macros with
ing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
drop == 0 and exchange != 0 with negation
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c
the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v8: drop a.index update before block_speculation
improve comments
xen/arch/x86/hvm/hvm.c | 10 ++
1 file changed, 10 insertions(+)
diff
On 2/25/19 16:54, Jan Beulich wrote:
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.
On 2/25/19 16:59, Jan Beulich wrote:
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
On 2/25/19 17:46, Jan Beulich wrote:
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);
>> +
>>
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-of-bound acc
ing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c | 17 +++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/s
code change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
Notes:
v9: fixed indentation (ARM)
dropped CONFIG_HVM in evaluate_nospec
dropped cast in
: Norbert Manthey
Acked-by: Jan Beulich
---
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10 +913,10 @@ void
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
protective mechanisms in case a potential speculative out-of-bound
access matches all the above properties.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v8: extended commit message with reason when to block speculation
fix order assert_unreachable
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Jan Beulich
---
Notes:
v9: fixed inline comments
added acked-by
xen/arch/x86/hvm/hvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a
On 2/28/19 11:00, Jan Beulich wrote:
On 27.02.19 at 14:01, wrote:
>> On 2/25/19 17:46, Jan Beulich wrote:
>>> I would really like to ask that I (or someone else) don't need to
>>> go through and list remaining version checks again - after all I
>>> had done so for v6 already, and I didn't go
On 3/5/19 17:38, Jan Beulich wrote:
On 27.02.19 at 17:13, wrote:
>> Speculative execution is not blocked in case one of the following
>> properties is true:
>> - path cannot be triggered by the guest
>> - path does not return to the guest
>> - path does not result in an out-of-bound access
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
ing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c | 17 +++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/s
code change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
xen/include/asm-arm/nospec.h | 25 +
xen/include/asm-x86/nospec.h | 39
: Norbert Manthey
Acked-by: Jan Beulich
---
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10 +913,10 @@ void
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
memory accesses
are protected in gnttab_get_status_frame_mfn
* gnttab_usage_print, as this function cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v10: extended commit message with explanation when to
the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
When issuing a vcpu_op hypercall, guests have control over the
vcpuid variable. In the old code, this allowed to perform
speculative out-of-bound accesses. To block this, we make use
of the domain_vcpu function.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
l leaks with
>> a simple unintrusive code change. During performance testing, we did not
>> notice performance effects.
>>
>> This is part of the speculative hardening effort.
>>
>> Signed-off-by: Norbert Manthey
>> Acked-by: Julien Grall
> I did give my ack on v
On 4/5/19 17:34, Andrew Cooper wrote:
> On 14/03/2019 12:50, Norbert Manthey wrote:
>> 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 th
On 4/24/19 20:10, Andrew Cooper wrote:
> c/s f8303458 restricted speculative access for do_vcpu_op(), but neglected its
> compat counterpart, which is reachable by guests using the 32bit ABI.
>
> Make an identical adjustment.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
On 10/25/19 17:40, Jan Beulich wrote:
> On 25.10.2019 17:27, Andrew Cooper wrote:
>> On 25/10/2019 13:34, Jan Beulich wrote:
>>> On 25.10.2019 14:10, Andrew Cooper wrote:
The two choices to unblock 4.13 are this patch, or the previous version
which made CONFIG_HARDEN_BRANCH depend on BROK
On 10/28/19 18:05, Andrew Cooper wrote:
> On 25/10/2019 22:56, Norbert Manthey wrote:
>> On 10/25/19 17:40, Jan Beulich wrote:
>>> On 25.10.2019 17:27, Andrew Cooper wrote:
>>>> On 25/10/2019 13:34, Jan Beulich wrote:
>>>>> On 25.10.2019 14:10, A
On 10/29/19 15:16, Andrew Cooper wrote:
> On 29/10/2019 14:03, Jan Beulich wrote:
>> On 29.10.2019 14:46, Andrew Cooper wrote:
>>> If this patch series does not agreement, I will unblock livepatching on
>>> 4.13 by committing the v2 patch which causes BRANCH_HARDEN to depend on
>>> BROKEN and force
CPROVER tool
suite), the missing semicolon is added in this commit.
Reported-by: Elizabeth Polgreen
Signed-off-by: Norbert Manthey
---
xen/common/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 75010b7..e29d596 100644
To be able to compile Xen with gotocc, the label statement has to be
followed by a semicolon.
Reported-by: Elizabeth Polgreen
Signed-off-by: Norbert Manthey
---
xen/common/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
Sorry for putting you in the To field, I'll use Cc in the future.
I agree that the commit message is a little short, and I will iterate on
that. Furthermore, I agree that gcc compatibility would allow to parse
this statement. However, the given sequence is not unique, and the gcc
documentation sta
://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
Reported-by: Julian Stecklina
Reported-by: Pawel Wieczorkiewicz
Signed-off-by: Norbert Manthey
---
xen/arch/x86/Rules.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index cc301cd..3f2687b 100644
On 11/20/18 17:37, Andrew Cooper wrote:
> On 20/11/2018 15:49, Jan Beulich wrote:
> On 20.11.18 at 16:37, wrote:
>>> To mitigate Meltdown, Xen has been fixed with a software fix, namely
>>> using retpoline sequences generated by the compiler. This way, indirect
>>> branches are protected again
files.
This commit adds handling comments in the assembler during the creation of
the asm header files.
Signed-off-by: Norbert Manthey
Signed-off-by: Michael Tautschnig
Reviewed-by: Pawel Wieczorkiewicz
Reviewed-by: Bjoern Doebel
---
xen/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion
To measure how long a certain interaction takes, we need time
primitives. This commit introduces these primitives, so that
future tests can use the gettimeofday function to retrieve the
current time.
Signed-off-by: Paul Semel
Signed-off-by: Norbert Manthey
---
build/files.mk | 1
for 1000 calls to the hypercall,
and next calculates the number of calls to take about 5 minutes.
Signed-off-by: Norbert Manthey
Reviewed-by: Bjoern Doebel
---
tests/perf-PV-MMUEXT_MARK_SUPER-noop/Makefile | 9 +++
tests/perf-PV-MMUEXT_MARK_SUPER-noop/main.c | 80 +++
2 files
tests of this kind.
Signed-off-by: Norbert Manthey
---
build/common.mk | 2 +-
xtf-runner | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build/common.mk b/build/common.mk
--- a/build/common.mk
+++ b/build/common.mk
@@ -1,4 +1,4 @@
-ALL_CATEGORIES := special
micro benchmarks. I
already implemented a few more that I will publish once the environment is
agreed on.
Best,
Norbert
Norbert Manthey (4):
categories: add benchmark
time: add stubs
time: provide measurement template
perf: measure MMUEXT_MARK_SUPER test
build/common.mk
processing the output further.
This format is, where average-time provides ns with ps granularity:
perf test_name ns
Signed-off-by: Norbert Manthey
---
common/time.c | 76 ++
include/xtf/time.h | 15 +
2 files changed, 91 insertions
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
---
xen/arch/x86/hvm/hvm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
---
v2: Add another speculative blocker, which protects the return code check
of the function hvm_allow_set_param.
xen/arch/x86/hvm/hvm.c | 19 +++
1 file change
On 2/8/21 3:21 PM, Jan Beulich wrote:
> On 05.02.2021 21:39, Norbert Manthey wrote:
>> To prevent leaking HVM params via L1TF and similar issues on a
>> hyperthread pair, let's load values of domains as late as possible.
>>
>> Furthermore, speculative barriers ar
VCPUs to leak hvm parameter values of
other domains.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
Release-Acked-by: Ian Jackson
---
v3: * rephrased commit message to better explain code relocation
* added release-acked
xen/arc
On 2/9/21 10:40 AM, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 08.02.2021 20:47, Norbert Manthey wrote:
>
On 2/9/21 2:45 PM, Jan Beulich wrote:
> On 09.02.2021 14:41, Norbert Manthey wrote:
>> On 2/9/21 10:40 AM, Jan Beulich wrote:
>>> On 08.02.2021 20:47, Norbert Manthey wrote:
>>>> On 2/8/21 3:21 PM, Jan Beulich wrote:
>>>>> On 05.02.2021 21:39, Norb
On 2/9/21 3:21 PM, Jan Beulich wrote:
> On 09.02.2021 14:56, Norbert Manthey wrote:
>> On 2/9/21 2:45 PM, Jan Beulich wrote:
>>> On 09.02.2021 14:41, Norbert Manthey wrote:
>>>> On 2/9/21 10:40 AM, Jan Beulich wrote:
>>>>> On 08.02.2021 20:47, Norbert
On 2/12/21 11:04 AM, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 11.02.2021 21:46, Norbert Manthey wrote:
>>
metry between the get and set operations, function
hvmop_set_param is made static.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
Release-Acked-by: Ian Jackson
---
v4: * add 'static' attribute to hvmop_set_param
* drop i
Sorry for the late reply. I try to pick up where we left the discussion
the last time.
On 5/24/19 13:10, Jan Beulich wrote:
On 24.05.19 at 11:54, wrote:
>> On 5/23/19 16:17, Jan Beulich wrote:
>> On 21.05.19 at 09:45, wrote:
Guests can issue grant table operations and provide guest
On 5/23/19 17:01, Jan Beulich wrote:
On 21.05.19 at 09:45, wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. Depending on the grant table version, the
>> size of ele
On 7/10/19 05:04, Jan Beulich wrote:
> On 08.07.2019 14:58, Norbert Manthey wrote:
>> On 5/24/19 13:10, Jan Beulich wrote:
>>>>>> On 24.05.19 at 11:54, wrote:
>>>> On 5/23/19 16:17, Jan Beulich wrote:
>>>>>>>> On 21.05.19 at 09:45,
On 7/10/19 05:12, Jan Beulich wrote:
> On 08.07.2019 15:53, Norbert Manthey wrote:
>> On 5/23/19 17:01, Jan Beulich wrote:
>>>>>> On 21.05.19 at 09:45, wrote:
>>>> * gnttab_set_version: all accessible data is allocated for both versions
>>> This
speculative hardening effort.
Best,
Norbert
Norbert Manthey (2):
common/grant_table: harden bound accesses
common/grant_table: harden version dependent accesses
xen/common/grant_table.c | 115 ---
1 file changed, 79 insertions(+), 36 deletions
equals
two might not hold under speculation.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v2: Mention version based blocking for upcoming commit
Introduce local variable as op->ref replacement
Use array_nospec_index
the
gnttab_grow_table function call.
* gnttab_usage_print: cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v2: Add block_speculation to gnttab_populate_status_frames and
gnttab_unpopulate_status_fra
On 7/11/19 14:34, Jan Beulich wrote:
> On 10.07.2019 14:54, Norbert Manthey wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative
speculative hardening effort.
Best,
Norbert
Norbert Manthey (2):
common/grant_table: harden bound accesses
common/grant_table: harden version dependent accesses
xen/common/grant_table.c | 107 +--
1 file changed, 75 insertions(+), 32 deletions
equals
two might not hold under speculation.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v3: Drop local variable for function local gop structure.
Wrap too long lines
xen/common/grant_table.c | 72
the
gnttab_grow_table function call.
* gnttab_usage_print: cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
xen/common/grant_table.c | 37 +
1 file changed, 25 inserti
gnment = 128;
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
--- a/xen
On 2/11/22 11:34, Jan Beulich wrote:
> On 11.02.2022 08:23, Norbert Manthey wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -609,7 +609,7 @@ void __init init_guest_cpuid(void)
>> bool recheck_cpu_features(unsigned int cpu)
>> {
>>
gnment = 128;
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
--- a/xen
Dear all,
we have been running some code analysis tools on the xenstore code, and triaged
the results. This series presents the robustness fixes we identified.
Best,
Norbert
Michael Kurth (1):
xenstore: add missing NULL check
Norbert Manthey (9):
xenstore: add missing NULL check
xenstore
Use the correct format specifier for unsigned values. Additionally, a
cast was dropped, as the format specifier did not require it anymore.
This was reported by analysis with cppcheck.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore
In case of allocation error, we should not dereference the obtained
NULL pointer. Hence, fail early.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien
When passing format strings to the trace function, allow gcc to analyze
those and warn on issues.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools
discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstore_client.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/xenstore
Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
--- a
From: Michael Kurth
In case of allocation error, we should not dereference the obtained
NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Michael Kurth
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas
Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c
+++ b
efore, this change only covers the corner case to make
sure we stay in the 32 bit range.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
d still be
fixed to not result in a NULL pointer dereference.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/libs/store/xs.c | 3 +
In case of a failure deep in the call tree, we might return NULL as the
value of the domain. In that case, error out instead of dereferencing
the NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert
On 2/26/21 3:53 PM, Julien Grall wrote:
> Hi Norbert,
>
> On 26/02/2021 14:41, Norbert Manthey wrote:
>> In case of a failure deep in the call tree, we might return NULL as the
>> value of the domain. In that case, error out instead of dereferencing
>> the NULL
On 3/2/21 6:15 AM, Jürgen Groß wrote:
> On 26.02.21 16:36, Andrew Cooper wrote:
>> On 26/02/2021 14:41, Norbert Manthey wrote:
>>> The read value could be larger than a signed 32bit integer. As -1 is
>>> used as error value, we should not rely on using the full 32 bits.
On 3/3/21 5:13 PM, Ian Jackson wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> Norbert Manthey writes ("[PATCH XENSTORE v1 09/10
101 - 198 of 198 matches
Mail list logo
