n for working on identifying the bottleneck with
me!
Reported-by: Tingting Mao
Cc: Serge Guelton
Cc: Honghao Wang
Cc: Paolo Bonzini
Cc: Daniele Buono
Signed-off-by: Stefan Hajnoczi
---
include/qemu/coroutine-pool-timer.h | 36 +
include/qemu/coroutine.h| 7
I agree, making these manual tasks until we find a fix for this is the
only solution I can think of too.
Daniele
On 7/28/2021 3:51 AM, Thomas Huth wrote:
These two jobs are currently failing very often - the linker seems to
get killed due to out-of-memory problems. Since apparently nobody has
Hi Philippe,
I'm looking at the public QEMU pipelines and it seems that that job
usually takes between 50 and 55 minutes, but there are higher spikes at
56, 57 and one where it failed at 1h.
We could perhaps set the timeout a bit higher, like 1h 10m, to not
terminate the outliers immediately?
On 3/5/2021 12:18 PM, Paolo Bonzini wrote:
Ok, so let's go with your patch for now. Independently we could change
libslirp to:
- add a separate callback (timer_new_v2?) in SlirpCb. If it is set, we
use it and pass an enum instead of the SlirpTimerCb cb.
- add a function
On 3/8/2021 6:19 AM, Daniel P. Berrangé wrote:
My concern is that libslirp is just showing us one known example of
the problem. QEMU links to many more external libraries, which might
exhibit similar issues. If we need to rebuild all the dependancies
with CFI too, to be confident that the
On 3/4/2021 5:37 AM, Daniel P. Berrangé wrote:
Is there work being done, or at least an active plan, for fixing this ?
Distros generally won't want to static link slirp to QEMU when there is
a shared slirp available. It increases the security burden to maintain
slirp twice, especially as slirp
On 3/4/2021 5:56 AM, Paolo Bonzini wrote:
On 04/03/21 11:37, Daniel P. Berrangé wrote:
On Wed, Mar 03, 2021 at 09:59:38PM -0500, Daniele Buono wrote:
For CFI, we need to compile slirp as a static library together with
qemu.
This is because we register slirp functions as callbacks for QEMU
QEMU has had options to enable control-flow integrity features
for a few months now. Add two sets of build/check/acceptance
jobs to ensure the binary produced is working fine.
The three sets allow testing of x86_64 binaries for x86_64, s390x,
ppc64 and aarch64 targets
Signed-off-by: Daniele
the ability to maintain high parallelism at
compile time, but limit the number of linkers executed in parallel.
Signed-off-by: Daniele Buono
---
.gitlab-ci.yml | 4
1 file changed, 4 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 8b6d495288..814f51873f 100644
--- a/.gitlab
484574
v3:
- Restricted the targets to x86_64, ppc64, aarch64 and s390x, under
suggestion from Daniel.
v2:
- More details in the code about the issue of using system-wide slirp
- Use meson to only limit linker parallelism instead of forcing no
parallelism on the whole compilation process.
D
.
With this patch, meson will stop if CFI is enabled with system-wide slirp
Signed-off-by: Daniele Buono
---
meson.build | 12
1 file changed, 12 insertions(+)
diff --git a/meson.build b/meson.build
index f3db83e974..e1ec5020ac 100644
--- a/meson.build
+++ b/meson.build
@@ -1569,6
On 3/2/2021 11:40 AM, Daniel P. Berrangé wrote:
The CFI protection is something I'd say is relevant to virtualization
use cases, not to emulation use cases
https://qemu-project.gitlab.io/qemu/system/security.html
IOW, the targets that are important to test are the ones where KVM
is
On 3/2/2021 10:38 AM, Daniel P. Berrangé wrote:
Is this scenario going to upset CFI, or is it happy that 'void *'
is compatible with 'mytype *', and ok with the intermediate casts
to/from GCallback ?
This is a valid scenario. LLVM does offer the ability of considering all
pointer types
On 3/2/2021 5:30 AM, Daniel P. Berrangé wrote:
On Mon, Mar 01, 2021 at 03:39:42PM -0500, Daniele Buono wrote:
Hi Daniel,
On 3/1/2021 10:08 AM, Daniel P. Berrangé wrote:
What are the unique failure scenarios for CFI that these jobs are
likely to expose ? Is it likely that we'll have cases
Hi Daniel,
On 3/1/2021 10:08 AM, Daniel P. Berrangé wrote:
What are the unique failure scenarios for CFI that these jobs are
likely to expose ? Is it likely that we'll have cases where
CFI succeeds in say, x86_64 target, but fails in aarch64 target ?
For CFI to fail (even if it shouldn't)
Hi Daniel,
On 3/1/2021 5:06 AM, Daniel P. Berrangé wrote:
On Fri, Feb 26, 2021 at 10:21:06AM -0500, Daniele Buono wrote:
Build jobs are on the longer side (about 2h and 20m), but I thought it
would be better to just have 6 large jobs than tens of smaller ones.
IMHO that is a not viable.
Our
Define a new variable LD_JOBS, that can be used to select
the maximum number of linking jobs to be executed in parallel.
If the variable is not defined, maintain the default given by
make -j
Signed-off-by: Daniele Buono
---
.gitlab-ci.yml | 4
1 file changed, 4 insertions(+)
diff --git
QEMU has had options to enable control-flow integrity features
for a few months now. Add two sets of build/check/acceptance
jobs to ensure the binary produced is working fine.
The two sets allow testing of x86_64 binaries for every target
that is not deprecated.
Signed-off-by: Daniele Buono
elines/261311362
v2:
- More details in the code about the issue of using system-wide slirp
- Use meson to only limit linker parallelism instead of forcing no
parallelism on the whole compilation process.
Daniele Buono (2):
gitlab-ci.yml: Allow custom # of parallel linkers
gitlab-ci.yml: Ad
On 2/24/2021 2:44 AM, Paolo Bonzini wrote:
On 23/02/21 20:34, Daniele Buono wrote:
This works, but setting this value to 1 for everybody seems a bit too
restrictive. While the gitlab ci runners don't have enough memory for
this, that's not necessarily true for every build platform
On 2/23/2021 3:11 AM, Paolo Bonzini wrote:
On 23/02/21 00:01, Daniele Buono wrote:
+# Set JOBS=1 because this requires LTO and ld consumes a large amount
of memory.
+# On gitlab runners, default JOBS of 2 sometimes end up calling 2 lds
concurrently
+# and triggers an Out-Of-Memory error
, a compilation is either
sequential or parallel based on #cpus
On 2/23/2021 3:12 AM, Paolo Bonzini wrote:
On 23/02/21 00:01, Daniele Buono wrote:
Currently, make parallelism at build time is defined as #cpus+1. Some
build jobs may need (or benefit from) a different number. An example
is builds
931154
Daniele Buono (2):
gitlab-ci.yml: Allow custom make parallelism
gitlab-ci.yml: Add jobs to test CFI flags
.gitlab-ci.yml | 94 +-
1 file changed, 93 insertions(+), 1 deletion(-)
--
2.30.0
QEMU has had options to enable control-flow integrity features
for a few months now. Add two sets of build/check/acceptance
jobs to ensure the binary produced is working fine.
The two sets allow testing of x86_64 binaries for every target
that is not deprecated.
Signed-off-by: Daniele Buono
the default value of #cpus+1 but allows setting
the "JOBS" variable to a different number when applying the template
Signed-off-by: Daniele Buono
---
.gitlab-ci.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 8b6d495288..5c198f0
On 1/28/2021 3:19 PM, Wainer dos Santos Moschetta wrote:
Hi,
On 1/26/21 10:09 PM, Daniele Buono wrote:
Local acceptance tests run with "make check-acceptance" are now
showing some cases canceled like the following:
(01/39)
tests/acceptance/boot_linux.py:BootLinuxX8664.test_pc_
interested.
Daniele Buono (1):
tests/acceptance/boot_linux: Switch to Fedora 32
tests/acceptance/boot_linux.py | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
--
2.30.0
Some acceptance test require a full VM image.
The tests were using Fedora 31, which is now EOL.
Probably as a consequence, the Avocado framework is not
able to download such images anymore.
Switch to Fedora 32, which is still supported.
Signed-off-by: Daniele Buono
---
tests/acceptance
On 1/14/2021 3:17 AM, Marc-André Lureau wrote:
Any update on this patch?
thanks
Hi,
I had been waiting for a feedback on my previous message.
I don't know the UAS subsystem that well, but can't find where the
variable-sized field that is causing the issue is actually used.
If it helps, I can
I had a similar issue in the past with the acceptance tests.
Some VMs send UTF-8 output in their console and the acceptance test
script would bail out if the locale was not UTF-8.
I sent a patch on the ml but it probably got lost:
lls are forbidden. QEMU relies on dlopen/dlsym when using modules,
so we make modules incompatible with CFI.
All the checks are performed in meson.build. configure is only used to
forward the flags to meson
Signed-off-by: Daniele Buono
---
configure | 21 -
meson.bu
Document how to compile with CFI and how to maintain CFI-safe code
Signed-off-by: Daniele Buono
---
docs/devel/control-flow-integrity.rst | 137 ++
1 file changed, 137 insertions(+)
create mode 100644 docs/devel/control-flow-integrity.rst
diff --git a/docs/devel
This patch allows to compile QEMU with link-time optimization (LTO).
Compilation with LTO is handled directly by meson. This patch only
adds the option in configure and forwards the request to meson
Tested with all major versions of clang from 6 to 12
Signed-off-by: Daniele Buono
---
configure
iotests
with a set of known-to-be-safe -fsanitize option. Then marks SafeStack
and the new options used for cfi-icall safe for iotests
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/check-block.sh b
that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono
Acked-by: Alex Bennée env_ptr;
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index c76281f354..c87c242063 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
://www.mail-archive.com/qemu-devel@nongnu.org/msg757930.html
Link to v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg753675.html
Link to v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg718786.html
Daniele Buono (5):
configure,meson: add option to enable LTO
cfi: Initial support
ere a info somewhere
on how to do that?
Thanks,
Daniele
On 11/6/2020 9:50 AM, Alexander Bulekov wrote:
On 201105 1718, Daniele Buono wrote:
LLVM's linker, LLD, supports the keyword "INSERT AFTER", starting with
version 11.
However, when multiple sections are defined in the same "INSE
Hi Alex,
Yeah I assumed it was an older version because the errors triggered by
clang11 stop the compilation.
I checked again and for oss-fuzz, you disable failing on warnings.
So again, these patches are not directly connected to CFI and therefore
could land independently.
On 11/6/2020 9:58
Hi Philippe,
Since you have a patch upcoming, may I drop this patch
from this set?
Daniele
On 11/9/2020 8:26 AM, Philippe Mathieu-Daudé wrote:
I did it. Will post later as this is 6.0 material.
Hi Philippe,
On 11/6/2020 9:28 AM, Philippe Mathieu-Daudé wrote:
On 11/5/20 11:18 PM, Daniele Buono wrote:
The UASStatus data structure has a variable sized field inside of type uas_iu,
that however is not placed at the end of the data structure.
This placement triggers a warning with clang
:
On Thu, 5 Nov 2020 17:18:56 -0500
Daniele Buono wrote:
This patch adds supports for Control-Flow Integrity checks
on indirect function calls.
Requires the use of clang, and link-time optimizations
Changes in v3:
- clang 11+ warnings are now handled directly at the source,
instead of disabling
;
^
1 error generated.
Fix this by moving uas_iu at the end of the struct
Signed-off-by: Daniele Buono
---
hw/usb/dev-uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/dev-uas.c b/hw/usb/dev-uas.c
index cec071d96c..5ef3f4fec9 100644
--- a/hw/usb/dev-uas.c
+++ b/hw/usb
lls are forbidden. QEMU relies on dlopen/dlsym when using modules,
so we make modules incompatible with CFI.
All the checks are performed in meson.build. configure is only used to
forward the flags to meson
Signed-off-by: Daniele Buono
---
configure | 21 -
meson.bu
the command anyway, for debugging purposes.
Since knowing the size of the command in the buffer is impossible (could not
decode the command), only print the header by setting len=1 if scsi_cdb_length
returned -1
Signed-off-by: Daniele Buono
---
If we had a way to know the (maximum) size of the buffer
iotests
with a set of known-to-be-safe -fsanitize option. Then marks SafeStack
and the new options used for cfi-icall safe for iotests
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/check-block.sh b
;
^~
4 errors generated.
Avoid this warning by casting the pointer to uintptr_t first.
Signed-off-by: Daniele Buono
---
target/s390x/cpu_models.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index
This patch allows to compile QEMU with link-time optimization (LTO).
Compilation with LTO is handled directly by meson. This patch only
adds the option in configure and forwards the request to meson
Tested with all major versions of clang from 6 to 12
Signed-off-by: Daniele Buono
---
configure
and should produce the
same code.
Signed-off-by: Daniele Buono
---
There is the possibility of removing IplBlockFcp from
IplParameterBlock, since it is not actually used.
This would also allow to entirely remove the definition of
IplBlockFcp, but we may want to keep it for completeness.
hw
inkers.
Each section now has its own "INSERT AFTER" keyword, so proper ordering is
defined between the sections added.
Signed-off-by: Daniele Buono
---
tests/qtest/fuzz/fork_fuzz.ld | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/qtest/fuzz/f
that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono
Acked-by: Alex Bennée for plugins
---
accel/tcg/cpu-exec.c| 11 +++
include/qemu/compiler.h | 12
plugins/core.c | 37
checks for cfi support and dependencies
has been moved from configure to meson
Link to v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg753675.html
Link to v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg718786.html
Daniele Buono (9):
fuzz: Make fork_fuzz.ld compatible with LLVM's
On 10/28/2020 5:35 AM, Alex Bennée wrote:
Breakage in both system and linux-user emulation probably points at
something in the instruction decode being broken. Shame we don't have a
working risu setup for sparc64 to give the instruction handling a proper
work out.
This is what I'm thinking
of warnings at compile time, and a binary that won't pass some of
the tests in make check.
On 10/28/2020 2:44 AM, Paolo Bonzini wrote:
On 27/10/20 21:42, Daniele Buono wrote:
Ok, no problem. I can definitely disable the check on GCC.
Paolo, would you like me to disable checks on AR/linker for lto
, Daniele Buono wrote:
In terms of ar and linker, if you don't have the right mix it will just
stop at link time with an error.
In terms of using gcc the errors may be a bit more subtle, similar to
what Daniel mentioned. Succesfully compiling but then showing issues at
runtime or in the test suite
Huth wrote:
On 26/10/2020 16.12, Paolo Bonzini wrote:
On 26/10/20 16:03, Daniele Buono wrote:
Hi Paolo,
I reorganized UASStatus to put uas_iu at the end and it works fine.
Unfortunately, this uncovered another part of the code with a similar
issue (variable sized type not at the end of the struct
compile QEMU with
--enable-debug the tests magically work.
I briefly tested with gcc-9 and that seemed to work ok, buy your mileage
may vary
On 10/26/2020 11:50 AM, Daniel P. Berrangé wrote:
On Mon, Oct 26, 2020 at 10:51:43AM +0100, Paolo Bonzini wrote:
On 23/10/20 22:06, Daniele Buono wrote
Using an array of length 0 seems to be enough to avoid the warning
Will use that solution in v3.
Thanks,
Daniele
On 10/26/2020 11:12 AM, Paolo Bonzini wrote:
On 26/10/20 16:03, Daniele Buono wrote:
Hi Paolo,
I reorganized UASStatus to put uas_iu at the end and it works fine.
Unfortunately
of these IplParameterBlock may contain
either a IPLBlockPV or a IplBlockFcp, which both end with a variable
sized field (an array).
Adding maintainers of s390x to see if they have a suggested solution to
avoid disabling the warning.
On 10/26/2020 5:50 AM, Paolo Bonzini wrote:
On 23/10/20 22:06, Daniele Buono wrote:
1
On 10/24/2020 1:17 AM, Thomas Huth wrote:
Compiling all code with -Wno-void-pointer-to-enum-cast sounds like the wrong
approach to me, since this might hide some real bugs in other spots instead.
Could you please try to cast the value through (uintptr_t) first, e.g. :
S390Feat feat =
On 10/23/2020 4:33 PM, Eric Blake wrote:
On 10/23/20 3:06 PM, Daniele Buono wrote:
v2: Several months (and structural changes in QEMU) have passed since v1.
While the spirit of the patch is similar, the implementation is changed
in multiple points, and should address most if not all
iotests
with a set of known-to-be-safe -fsanitize option. Then marks SafeStack
and the new options used for cfi-icall safe for iotests
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/check-block.sh b
that jump to callbacks
- Functions in util that directly call a signal handler
4) Add a new section in MAINTAINERS with me as a maintainer for
include/qemu/sanitizers.h, in case a maintainer is deemed
necessary for this feature
Signed-off-by: Daniele Buono
---
MAINTAINERS | 5 ++
lls are forbidden. QEMU relies on dlopen/dlsym when using modules,
so we make modules incompatible with CFI.
Signed-off-by: Daniele Buono
---
configure | 84 +
meson.build | 2 ++
2 files changed, 86 insertions(+)
diff --git a/configur
-by: Daniele Buono
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index e6754c1e87..9dc05cfb8a 100755
--- a/configure
+++ b/configure
@@ -2000,6 +2000,8 @@ add_to nowarn_flags -Wno-shift-negative-value
add_to nowarn_flags -Wno-string-plus-int
add_to
.
In case fuzzing is enabled, automatically switch to llvm's linker (lld).
The standard bfd linker has a bug where function wrapping (used by the fuzz*
targets) is used in conjunction with LTO.
Tested with all major versions of clang from 6 to 12
Signed-off-by: Daniele Buono
---
configure | 128
[2] Nelson Elhage. Virtunoid: Breaking out of KVM
[3] Marco Grassi and Kira. Vulnerability Discovery and Exploitation
of Virtualization Solutions for Cloud Computing and Desktops
[4] https://github.com/dbuono/QEMU-CFI-Performance
*** BLURB HERE ***
Daniele Buono (6):
fuzz: Make fork_fuzz.
inkers.
Each section now has its own "INSERT AFTER" keyword, so proper ordering is
defined between the sections added.
Signed-off-by: Daniele Buono
---
tests/qtest/fuzz/fork_fuzz.ld | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/qtest/fuzz/f
Yes, Something like that, probably with a small python script.
On 8/10/2020 5:33 PM, Alexander Bulekov wrote:
On 200810 2139, Paolo Bonzini wrote:
On 10/08/20 21:01, Daniele Buono wrote:
So I'm thinking of adding a check in configure. If gold is the linker,
automatically create (somehow
On 7/2/2020 11:43 AM, Daniele Buono wrote:
Hey Alex!
I agree, in most cases (possibly all of them), a wrong indirect function
call will end up with something that is catched by ASan or UBSan.
This way, however, you may catch it earlier and it may make debug easier
(especially with --enable-cfi
it to a UTF-8
locale fixed the issue, but a safer approach should be to just tell
Python to always use a UTF-8 charset for the socket. This is what the
patch does.
Daniele Buono (1):
tests/acceptance: set VM socket encoding to UTF-8
tests/acceptance/avocado_qemu/__init__.py | 2 +-
1 file changed, 1
the host is using a plain ASCII encoding, the VM test will fail
with an error. This patch explicitly sets the encoding to be UTF-8.
Signed-off-by: Daniele Buono
---
tests/acceptance/avocado_qemu/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/acceptance
On 7/2/2020 5:52 AM, Daniel P. Berrangé wrote:
The need to maintain this list of functions makes me feel very
uneasy.
How can we have any confidence that this list of functions is
accurate ? How will maintainers ensure that they correctly update
it as they are writing/changing code, and how
9:38 AM, Alexander Bulekov wrote:
Can't wait to try this out!
On 200702 1459, Paolo Bonzini wrote:
On 02/07/20 14:50, Daniele Buono wrote:
I also wonder if this is something that could be put in the fuzzing
environment. It would probably also help in finding coding error in
corner cases quicker
On 7/2/2020 9:12 AM, Daniel P. Berrangé wrote:
On Thu, Jul 02, 2020 at 08:50:08AM -0400, Daniele Buono wrote:
On 7/2/2020 5:52 AM, Daniel P. Berrangé wrote:
On Thu, Jul 02, 2020 at 01:49:48AM -0400, Daniele Buono wrote:
This patch adds a flag to enable/disable control flow integrity checks
On 7/2/2020 5:52 AM, Daniel P. Berrangé wrote:
On Thu, Jul 02, 2020 at 01:49:48AM -0400, Daniele Buono wrote:
This patch adds a flag to enable/disable control flow integrity checks
on indirect function calls. This feature is only provided by LLVM/Clang
v3.9 or higher, and only allows
On 7/2/2020 5:45 AM, Paolo Bonzini wrote:
On 02/07/20 07:49, Daniele Buono wrote:
This patch adds a flag to enable/disable control flow integrity checks
on indirect function calls. This feature is only provided by LLVM/Clang
v3.9 or higher, and only allows indirect function calls to functions
dependencies are met.
Signed-off-by: Daniele Buono
---
cfi-blacklist.txt | 27 +++
configure | 177 ++
2 files changed, 204 insertions(+)
create mode 100644 cfi-blacklist.txt
diff --git a/cfi-blacklist.txt b/cfi-blacklist.txt
new file
iotests
with a set of known-to-be-safe -fsanitize option. Then mark SafeStack
and the new options used for cfi-icall safe for iotests
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/check-block.sh b
- QEMU Case Study
[2] Nelson Elhage. Virtunoid: Breaking out of KVM
[3] Marco Grassi and Kira. Vulnerability Discovery and Exploitation
of Virtualization Solutions for Cloud Computing and Desktops
[4] https://github.com/dbuono/QEMU-CFI-Performance
Daniele Buono (2):
check-block: enable io
Ping?
On 5/29/2020 4:51 PM, Daniele Buono wrote:
LLVM supports SafeStack instrumentation to protect against stack buffer
overflows, since version 3.7
From https://clang.llvm.org/docs/SafeStack.html:
"It works by separating the program stack into two distinct regions: the
safe
and we want to make sure
it works correctly.
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/check-block.sh b/tests/check-block.sh
index ad320c21ba..8e29c868e5 100755
--- a/tests/check-block.sh
+++ b
by default.
While SafeStack is supported only on Linux, NetBSD, FreeBSD and macOS,
we are not checking for the O.S. since this is already done by LLVM.
Signed-off-by: Daniele Buono
---
configure | 73 +++
1 file changed, 73 insertions(+)
diff --git
support SafeStack.
The additional stack is then freed in qemu_coroutine_delete.
Signed-off-by: Daniele Buono
---
include/qemu/coroutine_int.h | 5 +
util/coroutine-ucontext.c| 26 ++
2 files changed, 31 insertions(+)
diff --git a/include/qemu/coroutine_int.h b
in coroutine-sigaltstack to throw a
preprocessor #error if SafeStack is enabled and we are trying to
use coroutine-sigaltstack to implement coroutines.
Signed-off-by: Daniele Buono
---
util/coroutine-sigaltstack.c | 4
1 file changed, 4 insertions(+)
diff --git a/util/coroutine-sigaltstack.c b/util
.
The reason is that the code changes will not be enabled without the
configure, making the code fully functional if only Patches #1 or #2 are
applied.
On the other hand, the configure patch will produce incorrect code if we
request SafeStack and the other patches are not applied.
Daniele Buono (4)
, Stefan Hajnoczi wrote:
On Wed, Apr 29, 2020 at 03:44:18PM -0400, Daniele Buono wrote:
s/sigalstack/sigaltstack/ in the commit message.
LLVM's SafeStack instrumentation cannot be used inside signal handlers
that make use of sigaltstack().
Since coroutine-sigaltstack relies on sigaltstack
e two ways to handle the default:
1. enable/disable based on the compilation flags given to configure
2. enable every time the provided compiler supports it
On 5/27/2020 7:12 AM, Stefan Hajnoczi wrote:
On Fri, May 22, 2020 at 11:24:46AM -0400, Daniele Buono wrote:
I would feel more confident by
On 5/21/2020 5:59 AM, Stefan Hajnoczi wrote:
On Wed, Apr 29, 2020 at 03:44:20PM -0400, Daniele Buono wrote:
SafeStack is a stack protection technique implemented in llvm. It is
enabled with a -fsanitize flag.
iotests are currently disabled when any -fsanitize option is used.
Since SafeStack
, 2020 at 03:44:19PM -0400, Daniele Buono wrote:
This patch adds a flag to enable the SafeStack instrumentation provided
by LLVM.
The checks make sure that the compiler supports the flags, and that we
are using the proper coroutine implementation (coroutine-ucontext).
While SafeStack is supported only
Hi Stefan,
thank you so much for reviewing this.
See my answers below:
On 5/21/2020 5:44 AM, Stefan Hajnoczi wrote:
On Wed, Apr 29, 2020 at 03:44:17PM -0400, Daniele Buono wrote:
diff --git a/include/qemu/coroutine_int.h b/include/qemu/coroutine_int.h
index bd6b0468e1..2ffd75ddbe 100644
4 PM, Daniele Buono wrote:
LLVM supports SafeStack instrumentation to protect against stack buffer
overflows, since version 3.7
From https://clang.llvm.org/docs/SafeStack.html:
"It works by separating the program stack into two distinct regions:
the
safe stack and the unsafe stack. The s
, and
keep a code structure more similar to the original.
Daniele Buono (1):
target-ppc: fix rlwimi, rlwinm, rlwnm for Clang-9
target/ppc/translate.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
--
2.26.2
l cases.
This patch restructures the code so that the actual if/else is done on a
local flag variable, that is set accordingly for PPC64, and always
true for PPC32.
Signed-off-by: Daniele Buono
---
target/ppc/translate.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
On 5/5/2020 1:08 AM, David Gibson wrote:
On Fri, May 01, 2020 at 03:09:13PM -0400, Daniele Buono wrote:
Starting with Clang v9, -Wtype-limits is implemented and triggers a
few "result of comparison is always true" errors when compiling PPC32
targets.
The comparisons seem to be nece
.
I tried to keep the changes to a minimum, to make sure to not affect the
semantics of the instructions. However, considering the target
architecture, my testing has been limited. check-acceptance seems to be
able to properly start a few linux kernels succesfully, and make check
didn't complain on both pp
l cases.
This patch restructures the code so that PPC32 does not execute the
check, while PPC64 works like before
Signed-off-by: Daniele Buono
---
target/ppc/translate.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/target/ppc/tran
are not checking for the O.S. since this is already done by LLVM.
Signed-off-by: Daniele Buono
---
configure | 29 +
1 file changed, 29 insertions(+)
diff --git a/configure b/configure
index 23b5e93752..f37e4ae0bd 100755
--- a/configure
+++ b/configure
@@ -302,6 +302,7
undefined behavior at runtime.
To avoid this, we add a check in coroutine-sigaltstack that throws a
preprocessor #error and interrupt the compilation if SafeStack is
enabled.
Signed-off-by: Daniele Buono
---
util/coroutine-sigaltstack.c | 4
1 file changed, 4 insertions(+)
diff --git a/util
is
performed, so that if SafeStack was the only -fsanitize option, iotests
are still performed.
Signed-off-by: Daniele Buono
---
tests/check-block.sh | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/check-block.sh b/tests/check-block.sh
index ad320c21ba
support SafeStack.
The additional stack is then freed in qemu_coroutine_delete.
Signed-off-by: Daniele Buono
---
include/qemu/coroutine_int.h | 6 ++
util/coroutine-ucontext.c| 25 +
2 files changed, 31 insertions(+)
diff --git a/include/qemu/coroutine_int.h b
1 - 100 of 101 matches
Mail list logo
