Re: [PATCH] [PATCH] linux-user/aarch64: Reset target data on MADV_DONTNEED

2022-08-10 Thread Vitaly Buka 
Sorry, I only noticed today that it's not submitted.
Version is not critical for us, as we build from masters anyway.
Richard, do you know a reason to consider this critical?

On Wed, 10 Aug 2022 at 13:04, Peter Maydell 
wrote:

> On Wed, 10 Aug 2022 at 21:00, Vitaly Buka  wrote:
> >
> > How can we land this one?
>
> Pinging it a week ago rather than now would have been a good start :-(
> I think it got missed because you didn't cc the linux-user maintainer.
>
> Is this a critical fix for 7.1 or can we let it slip to 7.2 ?
>
> thanks
> -- PMM
>

Re: [PATCH] [PATCH] linux-user/aarch64: Reset target data on MADV_DONTNEED

2022-08-10 Thread Vitaly Buka 
How can we land this one?

[PATCH] [PATCH] linux-user/aarch64: Reset target data on MADV_DONTNEED

2022-07-11 Thread Vitaly Buka 
aarch64 stores MTE tags in target_date, and they should be reset by
MADV_DONTNEED.

Signed-off-by: Vitaly Buka 
---
 accel/tcg/translate-all.c | 24 
 include/exec/cpu-all.h|  1 +
 linux-user/mmap.c |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index ef62a199c7..d6f2f1a40a 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -2314,6 +2314,30 @@ void page_set_flags(target_ulong start, target_ulong 
end, int flags)
 }
 }
 
+void page_reset_target_data(target_ulong start, target_ulong end)
+{
+target_ulong addr, len;
+
+/* This function should never be called with addresses outside the
+   guest address space.  If this assert fires, it probably indicates
+   a missing call to h2g_valid.  */
+assert(end - 1 <= GUEST_ADDR_MAX);
+assert(start < end);
+assert_memory_lock();
+
+start = start & TARGET_PAGE_MASK;
+end = TARGET_PAGE_ALIGN(end);
+
+for (addr = start, len = end - start;
+ len != 0;
+ len -= TARGET_PAGE_SIZE, addr += TARGET_PAGE_SIZE) {
+PageDesc *p = page_find_alloc(addr >> TARGET_PAGE_BITS, 1);
+
+g_free(p->target_data);
+p->target_data = NULL;
+}
+}
+
 void *page_get_target_data(target_ulong address)
 {
 PageDesc *p = page_find(address >> TARGET_PAGE_BITS);
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index f5bda2c3ca..491629b9ba 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -271,6 +271,7 @@ int walk_memory_regions(void *, walk_memory_regions_fn);
 
 int page_get_flags(target_ulong address);
 void page_set_flags(target_ulong start, target_ulong end, int flags);
+void page_reset_target_data(target_ulong start, target_ulong end);
 int page_check_range(target_ulong start, target_ulong len, int flags);
 
 /**
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 4e7a6be6ee..c535dfdc7c 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -894,6 +894,8 @@ abi_long target_madvise(abi_ulong start, abi_ulong len_in, 
int advice)
 if ((advice & MADV_DONTNEED) &&
 can_passthrough_madv_dontneed(start, end)) {
 ret = get_errno(madvise(g2h_untagged(start), len, MADV_DONTNEED));
+if (ret == 0)
+page_reset_target_data(start, start + len);
 }
 mmap_unlock();
 
-- 
2.37.0.144.g8ac04bfd2-goog

[Bug 1921948] Re: MTE tags not checked properly for unaligned accesses at EL1

2021-05-26 Thread Vitaly Buka 
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.
https://bugs.launchpad.net/bugs/1921948

Title:
  MTE tags not checked properly for unaligned accesses at EL1

Status in QEMU:
  Confirmed

Bug description:
  For kernel memory accesses that span across two memory granules,
  QEMU's MTE implementation only checks the tag of the first granule but
  not of the second one.

  To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS
  enabled, apply the patch below, and boot the kernel:

  diff --git a/sound/last.c b/sound/last.c
  index f0bb98780e70..04745cb30b74 100644
  --- a/sound/last.c
  +++ b/sound/last.c
  @@ -5,12 +5,18 @@
*/
   
   #include 
  +#include 
   #include 
   
   static int __init alsa_sound_last_init(void)
   {
  struct snd_card *card;
  int idx, ok = 0;
  +
  +   char *ptr = kmalloc(128, GFP_KERNEL);
  +   pr_err("KASAN report should follow:\n");
  +   *(volatile unsigned long *)(ptr + 124);
  +   kfree(ptr);
  
  printk(KERN_INFO "ALSA device list:\n");
  for (idx = 0; idx < SNDRV_CARDS; idx++) {

  KASAN tags the 128 allocated bytes with the same tag as the returned
  pointer. The memory granule that follows the 128 allocated bytes has a
  different tag (with 1/15 probability).

  Expected result: a tag fault is detected and a KASAN report is printed when 
accessing bytes [124, 130).
  Observed result: no tag fault is detected and no KASAN report is printed.

  Here are the flags that I use to run QEMU if they matter:

  qemu-system-aarch64 -s -machine virt,mte=on -cpu max -m 2G -smp 2 -net
  user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic
  -nographic -kernel ./Image -append "console=ttyAMA0 root=/dev/vda
  earlyprintk=serial" -drive file=./fs.img,format=raw,if=virtio -no-
  shutdown -no-reboot

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1921948/+subscriptions

[Bug 1926521] Re: QEMU-user ignores MADV_DONTNEED

2021-05-15 Thread Vitaly Buka 
New issue on GitLab https://gitlab.com/qemu-project/qemu/-/issues/326

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #326
   https://gitlab.com/qemu-project/qemu/-/issues/326

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926521

Title:
  QEMU-user ignores MADV_DONTNEED

Status in QEMU:
  Incomplete

Bug description:
  There is comment int the code "This is a hint, so ignoring and returning 
success is ok"
  
https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941

  But it seems incorrect with the current state of Linux

  "man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html
  says the following:
  >>  These advice values do not influence the semantics
  >>   of the application (except in the case of MADV_DONTNEED)

  >> After a successful MADV_DONTNEED operation, the semantics
  >> of memory access in the specified region are changed:
  >> subsequent accesses of pages in the range will succeed,
  >> but will result in either repopulating the memory contents
  >> from the up-to-date contents of the underlying mapped file
  >> (for shared file mappings, shared anonymous mappings, and
  >> shmem-based techniques such as System V shared memory
  >> segments) or zero-fill-on-demand pages for anonymous
  >> private mappings.

  Some applications use this behavior clear memory and it
  would be nice to be able to run them on QEMU without
  workarounds.

  Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host.

  
  ```
  #include "assert.h"
  #include "stdio.h"
  #include 
  #include 

  int main() {
char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
assert(P);
*P = 'A';
while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) {
}
assert(*P == 0);

printf("OK\n");
  }

  /*
  gcc /tmp/madvice.c -o /tmp/madvice

  qemu-x86_64 /tmp/madvice
  madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted

  /tmp/madvice
  OK

  
  */

  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926521/+subscriptions

[Bug 1926521] [NEW] QEMU-user ignores MADV_DONTNEED

2021-04-28 Thread Vitaly Buka 
Public bug reported:

There is comment int the code "This is a hint, so ignoring and returning 
success is ok"
https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941

But it seems incorrect with the current state of Linux

"man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html
says the following:
>>  These advice values do not influence the semantics
>>   of the application (except in the case of MADV_DONTNEED)

>> After a successful MADV_DONTNEED operation, the semantics
>> of memory access in the specified region are changed:
>> subsequent accesses of pages in the range will succeed,
>> but will result in either repopulating the memory contents
>> from the up-to-date contents of the underlying mapped file
>> (for shared file mappings, shared anonymous mappings, and
>> shmem-based techniques such as System V shared memory
>> segments) or zero-fill-on-demand pages for anonymous
>> private mappings.

Some applications use this behavior clear memory and it
would be nice to be able to run them on QEMU without
workarounds.

Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host.


```
#include "assert.h"
#include "stdio.h"
#include 
#include 

int main() {
  char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE,
 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  assert(P);
  *P = 'A';
  while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) {
  }
  assert(*P == 0);

  printf("OK\n");
}

/*
gcc /tmp/madvice.c -o /tmp/madvice

qemu-x86_64 /tmp/madvice
madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

/tmp/madvice
OK


*/

```

** Affects: qemu
 Importance: Undecided
 Status: New

** Summary changed:

- QEMU-user does no respect MADV_DONTNEED
+ QEMU-user ignores MADV_DONTNEED

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926521

Title:
  QEMU-user ignores MADV_DONTNEED

Status in QEMU:
  New

Bug description:
  There is comment int the code "This is a hint, so ignoring and returning 
success is ok"
  
https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941

  But it seems incorrect with the current state of Linux

  "man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html
  says the following:
  >>  These advice values do not influence the semantics
  >>   of the application (except in the case of MADV_DONTNEED)

  >> After a successful MADV_DONTNEED operation, the semantics
  >> of memory access in the specified region are changed:
  >> subsequent accesses of pages in the range will succeed,
  >> but will result in either repopulating the memory contents
  >> from the up-to-date contents of the underlying mapped file
  >> (for shared file mappings, shared anonymous mappings, and
  >> shmem-based techniques such as System V shared memory
  >> segments) or zero-fill-on-demand pages for anonymous
  >> private mappings.

  Some applications use this behavior clear memory and it
  would be nice to be able to run them on QEMU without
  workarounds.

  Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host.

  
  ```
  #include "assert.h"
  #include "stdio.h"
  #include 
  #include 

  int main() {
char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
assert(P);
*P = 'A';
while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) {
}
assert(*P == 0);

printf("OK\n");
  }

  /*
  gcc /tmp/madvice.c -o /tmp/madvice

  qemu-x86_64 /tmp/madvice
  madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted

  /tmp/madvice
  OK

  
  */

  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926521/+subscriptions

Re: [Bug 1926044] Re: QEMU-user doesn't report HWCAP2_MTE

2021-04-27 Thread Vitaly Buka 
Thanks for the quick fix!

On Tue, Apr 27, 2021 at 2:55 PM Richard Henderson <
1926...@bugs.launchpad.net> wrote:

>
> https://patchew.org/QEMU/20210427214108.88503-1-richard.hender...@linaro.org/
>
> This has missed 6.0, but should be acceptable to roll into 6.0.1.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1926044
>
> Title:
>   QEMU-user doesn't report HWCAP2_MTE
>
> Status in QEMU:
>   In Progress
>
> Bug description:
>   Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a
>
>   Host Debian 5.10.24 x86_64 GNU
>
>   Configured with "configure --disable-system --enable-linux-user
>   --static"
>
>   This one works and prints "OK" as expected:
>   clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu
> -fsanitize=memtag -march=armv8+memtag
>   qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK
>
>
>   This one fails and print "0":
>   cat mytest.c
>   #include 
>   #include 
>
>   #ifndef HWCAP2_MTE
>   #define HWCAP2_MTE (1 << 18)
>   #endif
>
>   int main(int ac, char **av)
>   {
>   printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
>   }
>
>
>   clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag
> -march=armv8+memtag
>   qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926044

Title:
  QEMU-user doesn't report HWCAP2_MTE

Status in QEMU:
  In Progress

Bug description:
  Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a

  Host Debian 5.10.24 x86_64 GNU

  Configured with "configure --disable-system --enable-linux-user
  --static"

  This one works and prints "OK" as expected:
  clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK

  
  This one fails and print "0":
  cat mytest.c
  #include 
  #include 

  #ifndef HWCAP2_MTE
  #define HWCAP2_MTE (1 << 18)
  #endif

  int main(int ac, char **av)
  {
  printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
  }

  
  clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions

[Bug 1926044] Re: QEMU-user doesn't report HWCAP2_MTE

2021-04-24 Thread Vitaly Buka 
Sorry, 0 7 8 should be "HWCAP2_DCPODP HWCAP2_FLAGM2 HWCAP2_FRINT"

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926044

Title:
  QEMU-user doesn't report HWCAP2_MTE

Status in QEMU:
  New

Bug description:
  Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a

  Host Debian 5.10.24 x86_64 GNU

  Configured with "configure --disable-system --enable-linux-user
  --static"

  This one works and prints "OK" as expected:
  clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK

  
  This one fails and print "0":
  cat mytest.c
  #include 
  #include 

  #ifndef HWCAP2_MTE
  #define HWCAP2_MTE (1 << 18)
  #endif

  int main(int ac, char **av)
  {
  printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
  }

  
  clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions

[Bug 1926044] Re: QEMU-user doesn't report HWCAP2_MTE

2021-04-24 Thread Vitaly Buka 
Actually if we make it like this:

#include 
#include 

int main(int ac, char **av)
{
for (int i = 0; i < 32; ++i)
if ((int)(getauxval(AT_HWCAP2) & (1 << i)))
printf("%d\n", i);
}


clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag
qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

I see only: HWCAP_FP HWCAP_CRC32 HWCAP_ATOMICS
So no HWCAP2_BTI as well.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926044

Title:
  QEMU-user doesn't report HWCAP2_MTE

Status in QEMU:
  New

Bug description:
  Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a

  Host Debian 5.10.24 x86_64 GNU

  Configured with "configure --disable-system --enable-linux-user
  --static"

  This one works and prints "OK" as expected:
  clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK

  
  This one fails and print "0":
  cat mytest.c
  #include 
  #include 

  #ifndef HWCAP2_MTE
  #define HWCAP2_MTE (1 << 18)
  #endif

  int main(int ac, char **av)
  {
  printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
  }

  
  clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions

[Bug 1926044] [NEW] QEMU-user doesn't report HWCAP2_MTE

2021-04-24 Thread Vitaly Buka 
Public bug reported:

Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a

Host Debian 5.10.24 x86_64 GNU

Configured with "configure --disable-system --enable-linux-user
--static"

This one works and prints "OK" as expected:
clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK


This one fails and print "0":
cat mytest.c
#include 
#include 

#ifndef HWCAP2_MTE
#define HWCAP2_MTE (1 << 18)
#endif

int main(int ac, char **av)
{
printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
}


clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag -march=armv8+memtag
qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: aarch64 mte user

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926044

Title:
  QEMU-user doesn't report HWCAP2_MTE

Status in QEMU:
  New

Bug description:
  Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a

  Host Debian 5.10.24 x86_64 GNU

  Configured with "configure --disable-system --enable-linux-user
  --static"

  This one works and prints "OK" as expected:
  clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK

  
  This one fails and print "0":
  cat mytest.c
  #include 
  #include 

  #ifndef HWCAP2_MTE
  #define HWCAP2_MTE (1 << 18)
  #endif

  int main(int ac, char **av)
  {
  printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE));
  }

  
  clang mytest.c -target aarch64-linux-gnu  -fsanitize=memtag 
-march=armv8+memtag
  qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions