linux-kernel - Re: vsyscall=emulate regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVCzErebXrVk8Bi+k1TjigD3XvJsmZFVZb=ksmSCOTVLg@mail.gmail.com>
Date:	Tue, 14 Feb 2012 08:26:22 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Amit Shah <amit.shah@...hat.com>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: vsyscall=emulate regression

On Tue, Feb 14, 2012 at 4:22 AM, Amit Shah <amit.shah@...hat.com> wrote:
> On (Fri) 03 Feb 2012 [13:57:48], Amit Shah wrote:
>> Hello,
>>
>> I'm booting some latest kernels on a Fedora 11 (released June 2009)
>> guest.  After the recent change of default to vsyscall=emulate, the
>> guest fails to boot (init segfaults).
>>
>> I also tried vsyscall=none, as suggested by hpa, and that fails as
>> well.  Only vsyscall=native works fine.
>>
>> The commit that introduced the kernel parameter,
>>
>> 3ae36655b97a03fa1decf72f04078ef945647c1a
>>
>> is bad too.
>
> I suggest we revert 2e57ae0515124af45dd889bfbd4840fd40fcc07d till we
> track down and fix the vsyscal=emulate case.

Hi-

Sorry, I lost track of this one.  I can't reproduce it, although I
doubt I've set up the right test environment.  But this is fishy:

init[1]: segfault at ffffffffff600400 ip ffffffffff600400 sp
00007fff9c8ba098 error 5

Error 5, if I'm decoding it correctly, is a userspace read (i.e. not
execute) fault.  The vsyscall emulation changes shouldn't have had any
effect on reads there.

Can you try booting the initramfs here:
http://web.mit.edu/luto/www/linux/vsyscall_initramfs.img
with your kernel image (i.e. qemu-kvm -kernel <whatever> -initrd
vsyscall_initramfs.img -whatever_else) and seeing what happens?  It
works for me.  That image is just a modern static build (i.e. built on
F16) of this code:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <time.h>

typedef time_t (*vsys_time_t)(time_t *);

int main()
{
  vsys_time_t vsys_time = (vsys_time_t)(0xffffffffff600400);
  unsigned char *p = (char*)0xffffffffff600400;
  int i;

  printf("The time is %ld\n", (long)( vsys_time(0) ));

  printf("The first few bytes are:\n");
  for (i = 0; i < 16; i++) {
    unsigned char c = p[i];
    printf("%02x ", (int)c);
  }
  printf("\n");

  printf("All done\n");
  while(1)
    pause();
}

I'm also curious what happens if you run without kvm (i.e. straight
qemu) and what your .config on the guest kernel is.  It sounds like
something's wrong with your fixmap, which makes me wonder if your
qemu/kernel combo is capable of booting even a modern distro
(up-to-date F16, say) -- the vvar page uses identical fixmap flags as
the vsyscall page in vsyscall=emulate and vsyscall=none mode.

What host cpu are you on and what qemu flags do you use?  Maybe
something is wrong with your emulator.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/