Thanks for opening the new ticket. I'm closing this one here on
Launchpad now so that we don't accidentally migrate it later
automatically.
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
I happened to notice that you're moving your bug tracker to gitlab so I
refiled this issue over there: https://gitlab.com/qemu-
project/qemu/-/issues/403
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #403
https://gitlab.com/qemu-project/qemu/-/issues/403
--
You received this bug
I see something similar in memset
It SEGV on
sturq0, [x4, #-16]
for x4 set to 0xd55214fe008
and near tags are 0xd55214fdff0 and 0xd55214fe000
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
(s/PR_MTE_TCF_ASYNC/PR_MTE_TCF_SYNC/g in the above program -- but the
actual constant is correct)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
MTE tags not checked properly for
It looks like there's still a bug here: I'm seeing false positive MTE
faults for unaligned accesses that touch multiple pages. This userspace
assembly program demonstrates the problem, but for some reason it only
reproduces some of the time for me:
.arch_extension memtag
.globl _start
_start:
** Changed in: qemu
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
MTE tags not checked properly for unaligned accesses at EL1
Status in
Ah, there's v4 now.
Tested with KASAN tests + a custom test to check unaligned accesses that
span across two granules, everything works.
Thank you!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Alex Bennée writes:
> Andrey Konovalov <1921...@bugs.launchpad.net> writes:
>
>> Is this with QEMU master without the patches mentioned in this bug?
>
> This is with Richard's latest series.
>
>>
>> Which kernel version do you use?
>
> v5.11
>
>> Could you share your kernel config?
>
> We are
Andrey Konovalov <1921...@bugs.launchpad.net> writes:
> Is this with QEMU master without the patches mentioned in this bug?
This is with Richard's latest series.
>
> Which kernel version do you use?
v5.11
> Could you share your kernel config?
We are just testing with Richard's config and
Re comments #8 and #10, I don't replicate that.
I get full pass on KASAN_UNIT_TEST with
and without virtualization enabled.
Re comment #9, if there are bugs suspected in qemu, they
need to be reported, or we'll never hear about them.
--
You received this bug notification because you are a
Is this with QEMU master without the patches mentioned in this bug?
Which kernel version do you use?
Could you share your kernel config?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
It gets further without but still spams a lot of failure messages:
The buggy address belongs to the object at ff80036a2200
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 11 bytes to the right of
128-byte region [ff80036a2200, ff80036a2280)
The buggy
This warning is caused by "virtualization=on" QEMU option. This is
another QEMU bug AFAIU, see [1] and [2].
[1]
https://lore.kernel.org/lkml/CAAeHK+wDz8aSLyjq1b=q3+hg9ajxxwyr6+gn_ftttmn5osm...@mail.gmail.com/
[2] https://lore.kernel.org/lkml/20210311123315.GF37303@C02TD0UTHF1T.local/T/
--
You
With v2, a lot of KASAN tests start failing. This likely means that MTE
tag faults stop being generated in certain cases.
With v3 [1], no MTE faults are generated at all.
[1]
https://patchew.org/QEMU/20210402214217.422585-1-richard.hender...@linaro.org/
--
You received this bug notification
Yeah, I saw an error right after posting. Please try v2:
https://patchew.org/QEMU/20210402161835.286665-1-richard.hender...@linaro.org/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
Hi Richard,
I tried your patch, but QEMU crashes with:
ERROR:../target/arm/mte_helper.c:588:mte_check_fail: code should not be reached
Bail out! ERROR:../target/arm/mte_helper.c:588:mte_check_fail: code should not
be reached
when running KASAN tests.
Thanks!
--
You received this bug
https://patchew.org/QEMU/20210402053728.265173-1-richard.hender...@linaro.org/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
MTE tags not checked properly for unaligned accesses at
Ah, perfect, I was missing dram_metadata.is_enabled.
And my userland unaligned test case demonstrates that
the second granule is tested, as reported.
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu
Status: Confirmed => In Progress
--
You received this bug
The flags that you need to pass to FVP to enable MTE are listed near the
end of the README here:
https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/README.md
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
I believe that you're correct, and that I mis-read the MTE
specification.
I believed that exactly one mte tag check was made for any single memory
access. But I missed that unaligned accesses are as-if a sequence of byte
accesses -- in the Arm ARM, see aarch64/functions/memory/Mem[].
I'm still
20 matches
Mail list logo
