qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1462640] Re: shmat fails on 32-to-64 setup


From: Ari Sundholm
Subject: [Qemu-devel] [Bug 1462640] Re: shmat fails on 32-to-64 setup
Date: Fri, 05 Jul 2019 18:03:37 -0000

Right. I'd also like to point out that I carried out some additional 
experiments using variations of the program in the issue description, with 
bizarre results, mips64. I changed the value of the pointer to 0x7f7df38c0000 
to increase the alignment a bit and then did the following experiments:
1) shmat(id, 0x7f7df38c0000, 0) fails, returning 0xffffffffffffffff, errno == 
22 (EINVAL)
2) shmat(id, 0x7f7df38c0000, SHM_REMAP) fails, returning 0xffffffffffffffff, 
errno == 22 (EINVAL)
3) shmat(id, 0x7f7df38c0000, SHM_RND) succeeds. Additionally, the return value 
is exactly the pointer value passed to the host shmat(), that is, 
0x7f7df38c0000.

The following thing bothers me:
With flags set to 0, the address 0x7f7df38c0000 is rejected. This could have 
been an alignment problem, but the call actually succeeds when the flags are 
set to SHM_RND (to align the returned address properly), with the pointer value 
remaining the same.

This looks bizarre to me, no matter the way you look at it.

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

Title:
  shmat fails on 32-to-64 setup

Status in QEMU:
  Confirmed

Bug description:
  
  I am trying to run a guest mips32 program (user mode) on a x86_64 host. The 
program fails on a call to shmat() reproducibly. when digging into this 
problem, I could make a small guest POC that fails when compiled as i386 (-m32) 
running on a x86_64 host, but pass when compiled as 64bit. The problem has to 
do with mmap flags.

  From what I can understand, when running 32bits guests programs, qemu
  reserve the whole guest virtual space with an mmap call. That mmap
  call specifys MAP:PRIVATE flag. When shmat is called, it tries to make
  part of that region MAP_SHARED and that fails.

  As a possible fix, it looks like it is possible to first unmap the shm
  region before calling shmat.

  steps to reproduce: 
  1 - create a file shm.c with content below
  2 - compile with: gcc -m32 shm.c -o shm32
  3 - run on a x86_64 host: qemu-i386 ./shm32 
  4 - observe shmat fails, by returning ptr -1

  5- compile without -m32: : gcc shm.c -o shm64
  6 - observe it pass: qemu-x84_64 ./shm64


  #include <sys/ipc.h>
  #include <sys/shm.h>
  #include <sys/mman.h>
  #include <stdio.h>

  int main()
  {
      struct shmid_ds shm_desc;
      int err = 0;
      int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666);
      err = shmctl(id, IPC_STAT, &shm_desc);
      const void *at = 0x7f7df38ea000;
      void* ptr = shmat(id, at, 0);
      printf( "got err %d, ptr %p\n", err, ptr );
  }

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]