no longer
needed.
Thanks to Serge Guelton 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 +
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?
Th
rsion as the minimum supported one, enabling CFI will be
possible even with system slirp.
You can open a slirp merge request at
https://gitlab.freedesktop.org/slirp/libslirp.
Hi Paolo,
sounds like a good plan!
I'll start working on this.
Regards,
Daniele
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 combine
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 h
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
s 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/.g
-/pipelines/264484574
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 compilat
.
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 availabl
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 comp
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
test them all when deemed necessary. I'm thinking for
example full testing when code in target/ or linux-user/ is considered,
or for testing pre-release code. Would be nice to have this automated
but I am not sure that's possible.
Regards,
Daniele
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 a
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
om/dbuono/qemu/-/pipelines/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
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 pla
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
ake to ninja, 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
-/pipelines/259931154
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
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_
, if 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
*status;
uint32_t length;
QTAILQ_ENTRY(UASStatus) next;
};
And discuss it at that point.
Thanks,
Daniele
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:
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06086.htm
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
https://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 su
uzz. Is there 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 sam
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
;t
be able to enable it anyway. (Alex can chip in to confirm this)
On the other hand, if someone is looking for temporary support in-house,
they can just add -Wno-[...] as extra-cflags until the additional
patches land. (Assuming CFI lands before the clang11+ patches).
Regards,
Daniele
On 11/6/202
status;
^
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/de
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
ce this is used for
tracing, we should try to print 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
---
I
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
or,-Wvoid-pointer-to-enum-cast]
S390FeatGroup group = (S390FeatGroup) opaque;
^~
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 deleti
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
arrays into arrays
of size 0. This avoids the compiler error 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
Ip
ith both linkers.
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/qt
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&#
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 too.
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 fo
:17 AM, Daniel P. Berrangé wrote:
On Tue, Oct 27, 2020 at 10:57:14AM -0400, 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 mentione
be used
anywhere now.
I could either keep it as it was before (with the variable-size array)
or remove it entirely.
I guess this is more a question for the maintainers, what is your
preference here?
Daniele
On 10/27/2020 7:38 AM, Cornelia Huck wrote:
On Tue, 27 Oct 2020 12:26:21 +0100
Thomas
ases. If I 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 wr
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
ameterBlock iplb_pv;
My understanding is that each 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, Paol
= (S390Feat)(uintptr_t) opaque;
It's a little bit ugly, but still better than to disable the warning
globally, I think.
Thomas
Hi Thomas,
I did a quick check and casting to a uintptr_t seem to be a working
solution to the issue. I will fix this in v3
Thanks,
Daniele
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 the
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
ter on the long term, but for now will
fix this adding
-Wno-void-pointer-to-enum-cast
Signed-off-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,
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
nd Paul Fariello. VM escape - 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
*** BLURB HERE **
ith both linkers.
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/qt
Sorry, this is invalid, not related to qemu, the root of the issue is
with OVMF_CODE.fd and OVMF_VARS.fd from v. 202005 or v. 202008 stable.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
Public bug reported:
Hi,
I have a macOS 10.15.7 vm with GPU passthrough (NVIDIA GTX Titan Black),
libvirt xml has path to vbios too.
Qemu 5.1.0-1 with libvirt 6.5.0-2 are installed in manjaro architect 20.1.1
(two kernels tried: 5.4.67 LTS and 5.8.11 stable, no difference).
I have two monitors,
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 (so
(which is
probably also dependent on the bfd/os version). So I'm thinking of
adding a check in configure. If gold is the linker, automatically create
(somehow, still working on it) the full link script by obtaining the
default bfd script and add the required parts. Would that work for you?
Chee
Setting 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
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
her with ASan, UBSan and the likes.
Unfortunately, since it works only with clang, I don't think this can
ever be a hard requirement.
Daniele
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 qu
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
and Paul Fariello. VM escape - 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
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 stack an
inary 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
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 a
perly
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_in
ol 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
#3.
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 Buon
20 5:49 AM, 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 sigaltsta
I have 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 confid
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
pr 29, 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
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
--- a
0 9:44 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.
, 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
the code so that PPC32 always runs the "true"
branch.
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 fe
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
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
ucing
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
1 - 100 of 103 matches
Mail list logo
