Linux virtualization list
 help / color / mirror / Atom feed
* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-07-27 15:43 UTC (permalink / raw)
  To: Andrew Lutomirski
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <CAObL_7GWGx4rYJFLpucEX=ozNpk+5ipyq0=vw16xcGetEXSuGQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

On Wed, Jul 27, 2011 at 11:34:21AM -0400, Andrew Lutomirski wrote:
> On Wed, Jul 27, 2011 at 11:30 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >> > Anyhow, removed the benchmark code and ran it on 64-bit:
> >> >
> >> > sh-4.1# /test_vsyscall  test
> >> > Testing gettimeofday...
> >> > [  109.552261] test_vsyscall[2462] trap invalid opcode ip:400c8d sp:7fff84fab470 error:0 in test_vsyscall[400000+2000]
> >> > Illegal instruction
> >> > sh-4.1# /test_vsyscall  intcc
> >> > About to execute int 0xcc from RIP = 400959
> >> > [  114.137150] test_vsyscall[2463] illegal int 0xcc (exploit attempt?) ip:400959 cs:e033 sp:7fff8b328310 ax:2c si:0 di:7fff8b3280f0
> >> > Caught SIGSEGV: Segmentation fault (Signal sent by the kernel [(nil)])RIP = 400959
> >> >
> >> > [This is on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #testing, which
> >> > has todays linus/master and your patchset]
> >> >
> >>
> >> I'll set up Xen.  Something's clearly still buggy.
> >
> > You sure? This is what I get when I boot baremetal:
> >
> > sh-4.1#
> > sh-4.1# xen-detect
> > Not running on Xen.
> > sh-4.1# /test_vsyscall test
> > Testing gettimeo[   84.442819] test_vsyscall[3175] trap invalid opcode ip:400c8d sp:7fffa8a72dc0 error:0fday...
> >  in test_vsyscall[400000+2000]
> 
> $ test_vsyscall test
> Testing gettimeofday...
>   vDSO offset = 0.000001s
>   vsyscall offset = 0.000001s
> 
> Testing time...
>   vDSO offset = 0
>   vsyscall offset = 0
> Testing getcpu...
>   ok!  cpu=6 node=0
> 
> Can you send me your test_vsyscall binary so I can disassemble it?

Here it is (also including source since I uncommented parts of it).

One extra thing - I've been using AMD machines for this - I hadn't
tried this on an Intel box.

[-- Attachment #2: test_vsyscall --]
[-- Type: application/octet-stream, Size: 27973 bytes --]

[-- Attachment #3: test_vsyscall.cc --]
[-- Type: text/x-c++src, Size: 9658 bytes --]

#define _POSIX_SOURCE

#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <dlfcn.h>
#include <string.h>
#include <inttypes.h>
#include <signal.h>
#include <sys/ucontext.h>
#include <asm/ldt.h>
#include <errno.h>

static inline int modify_ldt(int mode, void *ptr, unsigned long size)
{
  int ret = syscall(__NR_modify_ldt, mode, ptr, size);
  if (ret != 0)
    errno = -ret;
  return (ret == 0 ? 0 : -1);
}

/* vsyscalls and vDSO */
typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz);
const gtod_t vgtod = (gtod_t)0xffffffffff600000;
gtod_t vdso_gtod;

typedef long (*time_func_t)(time_t *t);
const time_func_t vtime = (time_func_t)0xffffffffff600400;
time_func_t vdso_time;

typedef long (*getcpu_t)(unsigned *, unsigned *, struct getcpu_cache*);
const getcpu_t vgetcpu = (getcpu_t)0xffffffffff600800;
getcpu_t vdso_getcpu;

void init_vdso()
{
  void *vdso = dlopen("linux-vdso.so.1", RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD);
  if (!vdso) {
    printf("Warning: failed to find vDSO\n");
    return;
  }

  vdso_gtod = (gtod_t)dlsym(vdso, "gettimeofday");
  if (!vdso_gtod)
    printf("Warning: failed to find gettimeofday in vDSO\n");

  vdso_time = (time_func_t)dlsym(vdso, "time");
  if (!vdso_time)
    printf("Warning: failed to find time in vDSO\n");

  vdso_getcpu = (getcpu_t)dlsym(vdso, "getcpu");
  if (!vdso_getcpu)
    printf("Warning: failed to find getcpu in vDSO\n");
}

/* syscalls */
static inline long sys_gtod(struct timeval *tv, struct timezone *tz)
{
  return syscall(__NR_gettimeofday, tv, tz);
}

static inline long sys_time(time_t *t)
{
  return syscall(__NR_time, t);
}

/* There is no sys_getcpu. */

static void segv(int sig, siginfo_t *info, void *ctx_void)
{
  psiginfo(info, "Caught SIGSEGV");

  ucontext_t *ctx = (ucontext_t*)ctx_void;
  printf("RIP = %lx\n", ctx->uc_mcontext.gregs[REG_RIP]);

  exit(1);
}

#if 0
/* benchmark helper */
template<typename Func> void benchmark(const char *desc, Func f)
{
  struct timespec start, end;
  long loops = 0;

  printf("Benchmarking %s ... ", desc);
  fflush(stdout);

  if (clock_gettime(CLOCK_MONOTONIC, &start)) {
    perror("clock_gettime");
    exit(1);
  }

  while(true)
    {
      long loops_now = 1000;
      for(int i = 0; i < loops_now; i++)
	f();
      loops += loops_now;

      if (clock_gettime(CLOCK_MONOTONIC, &end)) {
	perror("clock_gettime");
	exit(1);
      }

      unsigned long long duration = (end.tv_nsec - start.tv_nsec) +
	1000000000ULL * (end.tv_sec - start.tv_sec);

      if (duration < 500000000ULL)
	continue;

      printf("%9ld loops in %.5fs = %7.2f nsec / loop\n",
	     loops, float(duration) * 1e-9,
	     float(duration) / loops);
      break;
    }
}
#endif
static double tv_diff(const struct timeval &a, const struct timeval &b)
{
  return double(a.tv_sec - b.tv_sec) +
    double((int)a.tv_usec - (int)b.tv_usec) * 1e-6;
}

int test(int argc, char **argv)
{
  printf("Testing gettimeofday...\n");
  struct timeval tv_sys, tv_vdso, tv_vsys;
  struct timezone tz_sys, tz_vdso, tz_vsys;
  int ret_sys = sys_gtod(&tv_sys, &tz_sys);
  int ret_vdso = -1;
  if (vdso_gtod)
    ret_vdso = vdso_gtod(&tv_vdso, &tz_vdso);
  int ret_vsys = vgtod(&tv_vsys, &tz_vsys);

  if (ret_sys) {
    printf("  syscall failed\n");
  } else {
    if (ret_vdso == 0) {
      if (tz_sys.tz_minuteswest != tz_vdso.tz_minuteswest || tz_sys.tz_dsttime != tz_vdso.tz_dsttime)
	printf("  vDSO tz mismatch\n");
      else
	printf("  vDSO offset = %.6fs\n", tv_diff(tv_vdso, tv_sys));
    } else if (vdso_gtod) {
      printf("  vDSO failed\n");
    }
    if (ret_vsys == 0) {
      if (tz_sys.tz_minuteswest != tz_vsys.tz_minuteswest || tz_sys.tz_dsttime != tz_vsys.tz_dsttime)
	printf("  vsyscall tz mismatch\n");
      else
	printf("  vsyscall offset = %.6fs\n", tv_diff(tv_vsys, tv_sys));
    }
  }

  printf("\nTesting time...\n");
  long t_sys, t_vdso = 0, t_vsys; 
  long t2_sys = -1, t2_vdso = -1, t2_vsys = -1;
  t_sys = sys_time(&t2_sys);
  if (vdso_time)
    t_vdso = vdso_time(&t2_vdso);
  t_vsys = vtime(&t2_vsys);
  if (t_sys < 0 || t_sys != t2_sys) {
    printf("  syscall failed (ret:%ld output:%ld)\n", t_sys, t2_sys);
  } else {
    if (vdso_time) {
      if (t_vdso < 0 || t_vdso != t2_vdso)
	printf("  vDSO failed (ret:%ld output:%ld)\n", t_vdso, t2_vdso);
      else
	printf("  vDSO offset = %ld\n", t_vdso - t_sys);
    }

    if (t_vsys < 0 || t_vsys != t2_vsys)
      printf("  vsyscall failed (ret:%ld output:%ld)\n", t_vsys, t2_vsys);
    else
      printf("  vsyscall offset = %ld\n", t_vsys - t_sys);
  }

  printf("Testing getcpu...\n");
  unsigned cpu_vdso, cpu_vsys, node_vdso, node_vsys;
  ret_vdso = vdso_getcpu(&cpu_vdso, &node_vdso, 0);
  ret_vsys = vgetcpu(&cpu_vsys, &node_vsys, 0);
  if (ret_vdso)
    printf("  vDSO failed (ret:%ld)\n", (unsigned long)ret_vdso);
  if (ret_vsys)
    printf("  vsyscall failed (ret:%ld)\n", (unsigned long)ret_vdso);
  if (ret_vdso == 0 && ret_vsys == 0) {
    if (cpu_vdso != cpu_vsys)
      printf("  cpu mismatch (vdso:%u vsyscall:%u)!\n", cpu_vdso, cpu_vsys);
    else if (node_vdso != node_vsys)
      printf("  node mismatch (vdso:%u vsyscall:%u)!\n", node_vdso, node_vsys);
    else
      printf("  ok!  cpu=%u node=%u\n", cpu_vdso, node_vdso);
  }

  return 0;
}

int bench(int argc, char **argv)
{
  struct timeval tv;
  struct timezone tz;
#if 0
  benchmark(" syscall gettimeofday", [&]{sys_gtod(&tv, &tz);});
  benchmark("    vdso gettimeofday", [&]{vdso_gtod(&tv, &tz);});
  benchmark("vsyscall gettimeofday", [&]{vgtod(&tv, &tz);});

  printf("\n");
  time_t t;
  benchmark(" syscall time        ", [&]{sys_time(&t);});
  if (vdso_time)
    benchmark("    vdso time        ", [&]{vdso_time(&t);});
  benchmark("vsyscall time        ", [&]{vtime(&t);});

  printf("\n");
  unsigned cpu, node;
  benchmark("    vdso getcpu      ", [&]{vdso_getcpu(&cpu, &node, 0);});
  benchmark("vsyscall getcpu      ", [&]{vgetcpu(&cpu, &node, 0);});

  printf("\n");
  benchmark("dummy syscall        ", [&]{syscall(0xffffffff);});
#endif
  return 0;
}

int call(int argc, char **argv)
{
  if (argc != 5) {
    printf("Usage: call <addr> <rax> <arg1> <arg2> <arg3>\n");
    return 1;
  }

  unsigned long addr, rax, arg1, arg2, arg3;
  char *end;
  addr = strtoull(argv[0], &end, 0);
  if (*end)
    goto bad;

  rax = strtoull(argv[1], &end, 0);
  if (*end)
    goto bad;

  arg1 = strtoull(argv[2], &end, 0);
  if (*end)
    goto bad;

  arg2 = strtoull(argv[3], &end, 0);
  if (*end)
    goto bad;

  arg3 = strtoull(argv[4], &end, 0);
  if (*end)
    goto bad;

  unsigned long ret;
  asm volatile("call *%[addr]" : "=a" (ret) : [addr] "rm" (addr), "a" (rax),
	       "D" (arg1), "S" (arg2), "d" (arg3));
  printf("Return value = %ld\n", ret);

  return 0;

 bad:
  printf("Bad arg\n");
  return 1;
}

int intcc(int argc, char **argv)
{
  if (argc != 0) {
    printf("Usage: intcc\n");
    return 1;
  }

  extern char intcc_addr;
  printf("About to execute int 0xcc from RIP = %lX\n",
	 (unsigned long)&intcc_addr);

  asm volatile ("intcc_addr: int $0xcc");
  return 0;
}

struct __attribute__((packed)) farptr {
  uint32_t offset;
  uint16_t sel;
};

static bool to_farptr(farptr *out, uint16_t sel, void *offset)
{
  out->sel = sel;
  out->offset = (uint32_t)(unsigned long)offset;
  return out->offset == (unsigned long)offset;
}

int intcc32(int argc, char **argv)
{
  if (argc != 0) {
    printf("Usage: intcc32\n");
    return 1;
  }

  // Install a 32-bit code descriptor
  struct user_desc desc;
  memset(&desc, 0, sizeof(desc));
  desc.entry_number = 0;
  desc.base_addr = 0;
  desc.limit = 0xFFFFF;
  desc.seg_32bit = 1;
  desc.contents = MODIFY_LDT_CONTENTS_CODE;
  desc.limit_in_pages = 1;

  if (modify_ldt(1, &desc, sizeof(desc)) != 0) {
    perror("modify_ldt");
    return 1;
  }

  /* Load the initial CS. */
  uint16_t initial_cs;
  asm ("mov %%cs,%[initial_cs]" : [initial_cs] "=rm" (initial_cs));
  printf("Initial CS = 0x%04X (entry %d)\n",
	 (unsigned)initial_cs, (int)(initial_cs >> 3));

  extern char landing_32, landing_64;

  /* Set up the pointers. */
  static farptr ptr32, ptr64;
  if (!to_farptr(&ptr32, 0x4, &landing_32) || !to_farptr(&ptr64, initial_cs, &landing_64)) {
    printf("Something's mapped too high\n");
    return 1;
  }

  /* Go for it! */
  asm volatile (
		"mov %%rsp,%%rsi\n"		// Save rsp (avoids truncation).
		"ljmpl *(%%eax)\n"		// Switch to 32-bit mode.

		// 32-bit mode!
		// (Well, sort of.  DS and ES are 0, so we can't use them.)
		".code32\n"
		"landing_32:\n"
		"\tint $0xcc\n"			// Try int 0xcc.
		"\tljmpl *%%cs:(%%ecx)\n"	// Switch back.

		// 64-bit mode again!
		".code64\n"
		"landing_64:\n"
		"\tmov %%rsi,%%rsp"
		:
		: "a" (&ptr32), "c" (&ptr64)
		: "rsi", "cc");

  printf("Holy cow!  We survived!\n");

  return 0;
}

int main(int argc, char **argv)
{
  struct sigaction sa_segv;
  memset(&sa_segv, 0, sizeof(sa_segv));
  sa_segv.sa_sigaction = segv;
  sa_segv.sa_flags = SA_SIGINFO;
  sigemptyset(&sa_segv.sa_mask);
  if (sigaction(SIGSEGV, &sa_segv, 0))
    perror("sigaction");

  init_vdso();
  if (argc < 2) {
    printf("Usage: test_vsyscall <command> ...\n"
	   "command := { test, bench, intcc, call }\n");
    return 1;
  }

  if (!strcmp(argv[1], "test"))
    return test(argc - 2, argv + 2);
  if (!strcmp(argv[1], "bench"))
    return bench(argc - 2, argv + 2);
  if (!strcmp(argv[1], "intcc"))
    return intcc(argc - 2, argv + 2);
  if (!strcmp(argv[1], "intcc32"))
    return intcc32(argc - 2, argv + 2);
  if (!strcmp(argv[1], "call"))
    return call(argc - 2, argv + 2);

  printf("Unknown command\n");
  return 1;
}

[-- Attachment #4: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [Xen-devel] [PATCH 5/7] Xen: fix whitespaces, tabs coding style issue in drivers/xen/xenbus/xenbus_client.c
From: Konrad Rzeszutek Wilk @ 2011-07-27 15:36 UTC (permalink / raw)
  To: ruslanpisarev
  Cc: Ruslan Pisarev, jeremy.fitzhardinge, xen-devel, virtualization
In-Reply-To: <1311679009-16659-1-git-send-email-ruslan@rpisarev.org.ua>

On Tue, Jul 26, 2011 at 02:16:49PM +0300, ruslanpisarev@gmail.com wrote:
> From: Ruslan Pisarev <ruslan@rpisarev.org.ua>
> 
> This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools.

Not sure why you resent this patchset, but I am not taking this patch in.
Please address the concerns that were raised the first time you sent this patch.

I've the other six queued up for 3.2.

^ permalink raw reply

* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Andrew Lutomirski @ 2011-07-27 15:34 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <20110727153015.GA16688@dumpdata.com>

On Wed, Jul 27, 2011 at 11:30 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> > Anyhow, removed the benchmark code and ran it on 64-bit:
>> >
>> > sh-4.1# /test_vsyscall  test
>> > Testing gettimeofday...
>> > [  109.552261] test_vsyscall[2462] trap invalid opcode ip:400c8d sp:7fff84fab470 error:0 in test_vsyscall[400000+2000]
>> > Illegal instruction
>> > sh-4.1# /test_vsyscall  intcc
>> > About to execute int 0xcc from RIP = 400959
>> > [  114.137150] test_vsyscall[2463] illegal int 0xcc (exploit attempt?) ip:400959 cs:e033 sp:7fff8b328310 ax:2c si:0 di:7fff8b3280f0
>> > Caught SIGSEGV: Segmentation fault (Signal sent by the kernel [(nil)])RIP = 400959
>> >
>> > [This is on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #testing, which
>> > has todays linus/master and your patchset]
>> >
>>
>> I'll set up Xen.  Something's clearly still buggy.
>
> You sure? This is what I get when I boot baremetal:
>
> sh-4.1#
> sh-4.1# xen-detect
> Not running on Xen.
> sh-4.1# /test_vsyscall test
> Testing gettimeo[   84.442819] test_vsyscall[3175] trap invalid opcode ip:400c8d sp:7fffa8a72dc0 error:0fday...
>  in test_vsyscall[400000+2000]

$ test_vsyscall test
Testing gettimeofday...
  vDSO offset = 0.000001s
  vsyscall offset = 0.000001s

Testing time...
  vDSO offset = 0
  vsyscall offset = 0
Testing getcpu...
  ok!  cpu=6 node=0

Can you send me your test_vsyscall binary so I can disassemble it?

--Andy

^ permalink raw reply

* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-07-27 15:30 UTC (permalink / raw)
  To: Andrew Lutomirski
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <CAObL_7FT8QLg-wihasBahhAtS=pA7+KeU8E=E9x8NPZ0+QJ5iQ@mail.gmail.com>

> > Anyhow, removed the benchmark code and ran it on 64-bit:
> >
> > sh-4.1# /test_vsyscall  test
> > Testing gettimeofday...
> > [  109.552261] test_vsyscall[2462] trap invalid opcode ip:400c8d sp:7fff84fab470 error:0 in test_vsyscall[400000+2000]
> > Illegal instruction
> > sh-4.1# /test_vsyscall  intcc
> > About to execute int 0xcc from RIP = 400959
> > [  114.137150] test_vsyscall[2463] illegal int 0xcc (exploit attempt?) ip:400959 cs:e033 sp:7fff8b328310 ax:2c si:0 di:7fff8b3280f0
> > Caught SIGSEGV: Segmentation fault (Signal sent by the kernel [(nil)])RIP = 400959
> >
> > [This is on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #testing, which
> > has todays linus/master and your patchset]
> >
> 
> I'll set up Xen.  Something's clearly still buggy.

You sure? This is what I get when I boot baremetal:

sh-4.1# 
sh-4.1# xen-detect 
Not running on Xen.
sh-4.1# /test_vsyscall test
Testing gettimeo[   84.442819] test_vsyscall[3175] trap invalid opcode ip:400c8d sp:7fffa8a72dc0 error:0fday...
 in test_vsyscall[400000+2000]
Illegal instruction
sh-4.1# /test_vsyscall intcc
About to execute[   87.549820] test_vsyscall[3176] illegal int 0xcc (exploit attempt?) ip:400959 cs:33 sp:7fff0ccddff0 ax:2c s^G^G^G^G^G^G^Gsh-4.1# 
sh-4.1# /test_vsyscall intcc
About to execute[   90.283817] test_vsyscall[3177] illegal int 0xcc (exploit attempt?) ip:400959 cs:33 sp:7fffae8a8b40 ax:2c son fault (Signal sent by the kernel [(nil)])RIP = 400959

Unless the whole paravirt kernel is buggy. Hadn't tried to boot non-paravirt.

^ permalink raw reply

* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Andrew Lutomirski @ 2011-07-27 15:04 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <20110727145745.GA11872@dumpdata.com>

On Wed, Jul 27, 2011 at 10:57 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jul 26, 2011 at 11:20:34PM -0400, Andy Lutomirski wrote:
>> This fixes various problems that cropped up with the vdso patches.
>>
>>  - Patch 1 fixes an information leak to userspace.
>>  - Patches 2 and 3 fix the kernel build on gold.
>>  - Patches 4 and 5 fix Xen (I hope).
>>
>> Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]?
>
> They boot 64-bit guest succesfully.
>
> But I doesn't compile under 32-bit:
>
> home/konrad/ssd/linux/arch/x86/xen/enlighten.c:953: error: unknown field ‘extra_user_64bit_cs’ specified in initializer
> /home/konrad/ssd/linux/arch/x86/xen/enlighten.c:953: error: ‘FLAT_USER_CS64’ undeclared here (not in a function)
>
> Looks like it needs some #ifdef CONFIG_X86_64 magic.. and after
> applying that magic dust it compiles and it also boots as 32-bit
> (no surprise there).

Whoops!  I thought xen/enlighten.c was 64-bit only.

>
>> I don't have a usable Xen setup.
>
> It is pretty easy to setup. Google for PVops Wiki and you will find wealth
> of information. FYI: I am gone next week so won't be able to test these
> patches.
>
>>
>> Also, I'd appreciate a review of patches 4 and 5 from some Xen/paravirt
>> people.
>>
>> [1] https://gitorious.org/linux-test-utils/linux-clock-tests
>
> Grrrrr..
>
> g++ -o test_vsyscall -std=gnu++0x -lrt -ldl -O2 -Wall -mavx -g test_vsyscall.cc
> test_vsyscall.cc: In function ‘int bench(int, char**)’:
> test_vsyscall.cc:205: error: expected primary-expression before ‘[’ token

[...]

>
> Is there a specific version of GCC I should be using? I seem to be
> using: g++ (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)

Apparently it needs g++ 4.5 for lambdas.

>
> Anyhow, removed the benchmark code and ran it on 64-bit:
>
> sh-4.1# /test_vsyscall  test
> Testing gettimeofday...
> [  109.552261] test_vsyscall[2462] trap invalid opcode ip:400c8d sp:7fff84fab470 error:0 in test_vsyscall[400000+2000]
> Illegal instruction
> sh-4.1# /test_vsyscall  intcc
> About to execute int 0xcc from RIP = 400959
> [  114.137150] test_vsyscall[2463] illegal int 0xcc (exploit attempt?) ip:400959 cs:e033 sp:7fff8b328310 ax:2c si:0 di:7fff8b3280f0
> Caught SIGSEGV: Segmentation fault (Signal sent by the kernel [(nil)])RIP = 400959
>
> [This is on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #testing, which
> has todays linus/master and your patchset]
>

I'll set up Xen.  Something's clearly still buggy.

--Andy

^ permalink raw reply

* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-07-27 14:57 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

On Tue, Jul 26, 2011 at 11:20:34PM -0400, Andy Lutomirski wrote:
> This fixes various problems that cropped up with the vdso patches.
> 
>  - Patch 1 fixes an information leak to userspace.
>  - Patches 2 and 3 fix the kernel build on gold.
>  - Patches 4 and 5 fix Xen (I hope).
> 
> Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]?

They boot 64-bit guest succesfully.

But I doesn't compile under 32-bit:

home/konrad/ssd/linux/arch/x86/xen/enlighten.c:953: error: unknown field ‘extra_user_64bit_cs’ specified in initializer
/home/konrad/ssd/linux/arch/x86/xen/enlighten.c:953: error: ‘FLAT_USER_CS64’ undeclared here (not in a function)

Looks like it needs some #ifdef CONFIG_X86_64 magic.. and after
applying that magic dust it compiles and it also boots as 32-bit
(no surprise there).

> I don't have a usable Xen setup.

It is pretty easy to setup. Google for PVops Wiki and you will find wealth
of information. FYI: I am gone next week so won't be able to test these
patches.

> 
> Also, I'd appreciate a review of patches 4 and 5 from some Xen/paravirt
> people.
> 
> [1] https://gitorious.org/linux-test-utils/linux-clock-tests

Grrrrr..

g++ -o test_vsyscall -std=gnu++0x -lrt -ldl -O2 -Wall -mavx -g test_vsyscall.cc
test_vsyscall.cc: In function ‘int bench(int, char**)’:
test_vsyscall.cc:205: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:205: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:206: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:206: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:207: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:207: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:211: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:211: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:213: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:213: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:214: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:214: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:218: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:218: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:219: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:219: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:222: error: expected primary-expression before ‘[’ token
test_vsyscall.cc:222: error: expected primary-expression before ‘]’ token
test_vsyscall.cc:203: warning: unused variable ‘tv’
test_vsyscall.cc:204: warning: unused variable ‘tz’
test_vsyscall.cc:210: warning: unused variable ‘t’
test_vsyscall.cc:217: warning: unused variable ‘cpu’
test_vsyscall.cc:217: warning: unused variable ‘node’

Is there a specific version of GCC I should be using? I seem to be
using: g++ (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)

Anyhow, removed the benchmark code and ran it on 64-bit:

sh-4.1# /test_vsyscall  test
Testing gettimeofday...
[  109.552261] test_vsyscall[2462] trap invalid opcode ip:400c8d sp:7fff84fab470 error:0 in test_vsyscall[400000+2000]
Illegal instruction
sh-4.1# /test_vsyscall  intcc
About to execute int 0xcc from RIP = 400959
[  114.137150] test_vsyscall[2463] illegal int 0xcc (exploit attempt?) ip:400959 cs:e033 sp:7fff8b328310 ax:2c si:0 di:7fff8b3280f0
Caught SIGSEGV: Segmentation fault (Signal sent by the kernel [(nil)])RIP = 400959

[This is on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #testing, which
has todays linus/master and your patchset]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH 4/5] x86-64/xen: Enable the vvar mapping
From: Andrew Lutomirski @ 2011-07-27 13:48 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <20110727130604.GD6713@dumpdata.com>

On Wed, Jul 27, 2011 at 9:06 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jul 26, 2011 at 11:20:38PM -0400, Andy Lutomirski wrote:
>> Xen needs special treatment for fixmaps.
>
> The description needs a bit more, for example:
>
> "Xen needs to handle the newly introduced VVAR_PAGE introduced by
> git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7
> "x86-64: Give vvars their own page"

Will do.

--Andy

^ permalink raw reply

* Re: [PATCH 4/5] x86-64/xen: Enable the vvar mapping
From: Konrad Rzeszutek Wilk @ 2011-07-27 13:06 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <b6598d164fbe64eeea37c0369b64dd6ceaeeb504.1311736366.git.luto@mit.edu>

On Tue, Jul 26, 2011 at 11:20:38PM -0400, Andy Lutomirski wrote:
> Xen needs special treatment for fixmaps.

The description needs a bit more, for example:

"Xen needs to handle the newly introduced VVAR_PAGE introduced by
git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7
"x86-64: Give vvars their own page"

Otherwise we die during bootup with this:

<and include snippets of the boot message crash>
"

With that included it looks good to me.

> 
> Signed-off-by: Andy Lutomirski <luto@mit.edu>
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/mmu.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index f987bde..8cce339 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1916,6 +1916,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
>  # endif
>  #else
>  	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
> +	case VVAR_PAGE:
>  #endif
>  	case FIX_TEXT_POKE0:
>  	case FIX_TEXT_POKE1:
> @@ -1956,7 +1957,8 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
>  #ifdef CONFIG_X86_64
>  	/* Replicate changes to map the vsyscall page into the user
>  	   pagetable vsyscall mapping. */
> -	if (idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) {
> +	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
> +	    idx == VVAR_PAGE) {
>  		unsigned long vaddr = __fix_to_virt(idx);
>  		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
>  	}
> -- 
> 1.7.6

^ permalink raw reply

* Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-07-27 12:59 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
	keir.xen
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

On Tue, Jul 26, 2011 at 11:20:34PM -0400, Andy Lutomirski wrote:
> This fixes various problems that cropped up with the vdso patches.
> 
>  - Patch 1 fixes an information leak to userspace.
>  - Patches 2 and 3 fix the kernel build on gold.
>  - Patches 4 and 5 fix Xen (I hope).
> 
> Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]?
> I don't have a usable Xen setup.

Sure.

^ permalink raw reply

* (unknown), 
From: Grant McWilliams @ 2011-07-27  8:39 UTC (permalink / raw)
  To: mrsanna1, dhunt78, questions, pdcpopol_vuh, brobannon, nlbeaird,
	lists.xensource.com

http://putige.org/google.php

^ permalink raw reply

* [PATCH 5/5] x86-64: Add user_64bit_mode paravirt op
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

Three places in the kernel assume that the only long mode CPL 3
selector is __USER_CS.  This is not true on Xen -- Xen's sysretq
changes cs to the magic value 0xe033.

Two of the places are corner cases, but as of "x86-64: Improve
vsyscall emulation CS and RIP handling"
(c9712944b2a12373cb6ff8059afcfb7e826a6c54), vsyscalls will segfault
if called with Xen's extra CS selector.  This causes a panic when
older init builds die.

It seems impossible to make Xen use __USER_CS reliably without
taking a performance hit on every system call, so this fixes the
tests instead with a new paravirt op.  It's a little ugly because
ptrace.h can't include paravirt.h.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/desc.h           |    4 ++--
 arch/x86/include/asm/paravirt_types.h |    6 ++++++
 arch/x86/include/asm/ptrace.h         |   19 +++++++++++++++++++
 arch/x86/kernel/paravirt.c            |    4 ++++
 arch/x86/kernel/step.c                |    2 +-
 arch/x86/kernel/vsyscall_64.c         |    6 +-----
 arch/x86/mm/fault.c                   |    2 +-
 arch/x86/xen/enlighten.c              |    1 +
 8 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 7b439d9..41935fa 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -27,8 +27,8 @@ static inline void fill_ldt(struct desc_struct *desc, const struct user_desc *in
 
 	desc->base2		= (info->base_addr & 0xff000000) >> 24;
 	/*
-	 * Don't allow setting of the lm bit. It is useless anyway
-	 * because 64bit system calls require __USER_CS:
+	 * Don't allow setting of the lm bit. It would confuse
+	 * user_64bit_mode and would get overridden by sysret anyway.
 	 */
 	desc->l			= 0;
 }
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 2c76521..8e8b9a4 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -41,6 +41,7 @@
 
 #include <asm/desc_defs.h>
 #include <asm/kmap_types.h>
+#include <asm/pgtable_types.h>
 
 struct page;
 struct thread_struct;
@@ -63,6 +64,11 @@ struct paravirt_callee_save {
 struct pv_info {
 	unsigned int kernel_rpl;
 	int shared_kernel_pmd;
+
+#ifdef CONFIG_X86_64
+	u16 extra_user_64bit_cs;  /* __USER_CS if none */
+#endif
+
 	int paravirt_enabled;
 	const char *name;
 };
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 94e7618..3566454 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -131,6 +131,9 @@ struct pt_regs {
 #ifdef __KERNEL__
 
 #include <linux/init.h>
+#ifdef CONFIG_PARAVIRT
+#include <asm/paravirt_types.h>
+#endif
 
 struct cpuinfo_x86;
 struct task_struct;
@@ -187,6 +190,22 @@ static inline int v8086_mode(struct pt_regs *regs)
 #endif
 }
 
+#ifdef CONFIG_X86_64
+static inline bool user_64bit_mode(struct pt_regs *regs)
+{
+#ifndef CONFIG_PARAVIRT
+	/*
+	 * On non-paravirt systems, this is the only long mode CPL 3
+	 * selector.  We do not allow long mode selectors in the LDT.
+	 */
+	return regs->cs == __USER_CS;
+#else
+	/* Headers are too twisted for this to go in paravirt.h. */
+	return regs->cs == __USER_CS || regs->cs == pv_info.extra_user_64bit_cs;
+#endif
+}
+#endif
+
 /*
  * X86_32 CPUs don't save ss and esp if the CPU is already in kernel mode
  * when it traps.  The previous stack will be directly underneath the saved
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 613a793..d90272e 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -307,6 +307,10 @@ struct pv_info pv_info = {
 	.paravirt_enabled = 0,
 	.kernel_rpl = 0,
 	.shared_kernel_pmd = 1,	/* Only used when CONFIG_X86_PAE is set */
+
+#ifdef CONFIG_X86_64
+	.extra_user_64bit_cs = __USER_CS,
+#endif
 };
 
 struct pv_init_ops pv_init_ops = {
diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c
index 7977f0c..c346d11 100644
--- a/arch/x86/kernel/step.c
+++ b/arch/x86/kernel/step.c
@@ -74,7 +74,7 @@ static int is_setting_trap_flag(struct task_struct *child, struct pt_regs *regs)
 
 #ifdef CONFIG_X86_64
 		case 0x40 ... 0x4f:
-			if (regs->cs != __USER_CS)
+			if (!user_64bit_mode(regs))
 				/* 32-bit mode: register increment */
 				return 0;
 			/* 64-bit mode: REX prefix */
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index dda7dff..1725930 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -127,11 +127,7 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
 
 	local_irq_enable();
 
-	/*
-	 * Real 64-bit user mode code has cs == __USER_CS.  Anything else
-	 * is bogus.
-	 */
-	if (regs->cs != __USER_CS) {
+	if (!user_64bit_mode(regs)) {
 		/*
 		 * If we trapped from kernel mode, we might as well OOPS now
 		 * instead of returning to some random address and OOPSing
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 4d09df0..decd51a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -105,7 +105,7 @@ check_prefetch_opcode(struct pt_regs *regs, unsigned char *instr,
 		 * but for now it's good enough to assume that long
 		 * mode only uses well known segments or kernel.
 		 */
-		return (!user_mode(regs)) || (regs->cs == __USER_CS);
+		return (!user_mode(regs) || user_64bit_mode(regs));
 #endif
 	case 0x60:
 		/* 0x64 thru 0x67 are valid prefixes in all modes. */
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 974a528..a9c710a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -950,6 +950,7 @@ static unsigned xen_patch(u8 type, u16 clobbers, void *insnbuf,
 static const struct pv_info xen_info __initconst = {
 	.paravirt_enabled = 1,
 	.shared_kernel_pmd = 0,
+	.extra_user_64bit_cs = FLAT_USER_CS64,
 
 	.name = "Xen",
 };
-- 
1.7.6

^ permalink raw reply related

* [PATCH 4/5] x86-64/xen: Enable the vvar mapping
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

Xen needs special treatment for fixmaps.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f987bde..8cce339 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1916,6 +1916,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 # endif
 #else
 	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
+	case VVAR_PAGE:
 #endif
 	case FIX_TEXT_POKE0:
 	case FIX_TEXT_POKE1:
@@ -1956,7 +1957,8 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 #ifdef CONFIG_X86_64
 	/* Replicate changes to map the vsyscall page into the user
 	   pagetable vsyscall mapping. */
-	if (idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) {
+	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
+	    idx == VVAR_PAGE) {
 		unsigned long vaddr = __fix_to_virt(idx);
 		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
 	}
-- 
1.7.6

^ permalink raw reply related

* [PATCH 3/5] x86-64: Work around gold bug 13023
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

Gold has trouble assigning numbers to the location counter inside of
an output section description.  The bug was triggered by
9fd67b4ed0714ab718f1f9bd14c344af336a6df7, which consolidated all of
the vsyscall sections into a single section.  The workaround is IMO
still nicer than the old way of doing it.

This produces an apparently valid kernel image and passes my vdso
tests on both GNU ld version 2.21.51.0.6-2.fc15 20110118 and GNU
gold (version 2.21.51.0.6-2.fc15 20110118) 1.10 as distributed by
Fedora 15.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
---
 arch/x86/kernel/vmlinux.lds.S |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index e79fb39..8f3a265 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -158,10 +158,12 @@ SECTIONS
 	__vvar_page = .;
 
 	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
+		/* work around gold bug 13023 */
+		__vvar_beginning_hack = .;
 
-	      /* Place all vvars at the offsets in asm/vvar.h. */
-#define EMIT_VVAR(name, offset) 		\
-		. = offset;		\
+		/* Place all vvars at the offsets in asm/vvar.h. */
+#define EMIT_VVAR(name, offset) 			\
+		. = __vvar_beginning_hack + offset;	\
 		*(.vvar_ ## name)
 #define __VVAR_KERNEL_LDS
 #include <asm/vvar.h>
@@ -184,15 +186,17 @@ SECTIONS
 
 	. = VSYSCALL_ADDR;
 	.vsyscall : AT(VLOAD(.vsyscall)) {
+		/* work around gold bug 13023 */
+		__vsyscall_beginning_hack = .;
 		*(.vsyscall_0)
 
-		. = 1024;
+		. = __vsyscall_beginning_hack + 1024;
 		*(.vsyscall_1)
 
-		. = 2048;
+		. = __vsyscall_beginning_hack + 2048;
 		*(.vsyscall_2)
 
-		. = 4096;  /* Pad the whole page. */
+		. = __vsyscall_beginning_hack + 4096;  /* Pad the whole page. */
 	} :user =0xcc
 	. = ALIGN(__vsyscall_0 + PAGE_SIZE, PAGE_SIZE);
 
-- 
1.7.6

^ permalink raw reply related

* [PATCH 2/5] x86-64: Move the "user" vsyscall segment out of the data segment.
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

The kernel's loader doesn't seem to care, but gold complains.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
---
 arch/x86/kernel/vmlinux.lds.S |   36 ++++++++++++++++++------------------
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 4aa9c54..e79fb39 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -154,6 +154,24 @@ SECTIONS
 
 #ifdef CONFIG_X86_64
 
+	. = ALIGN(PAGE_SIZE);
+	__vvar_page = .;
+
+	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
+
+	      /* Place all vvars at the offsets in asm/vvar.h. */
+#define EMIT_VVAR(name, offset) 		\
+		. = offset;		\
+		*(.vvar_ ## name)
+#define __VVAR_KERNEL_LDS
+#include <asm/vvar.h>
+#undef __VVAR_KERNEL_LDS
+#undef EMIT_VVAR
+
+	} :data
+
+       . = ALIGN(__vvar_page + PAGE_SIZE, PAGE_SIZE);
+
 #define VSYSCALL_ADDR (-10*1024*1024)
 
 #define VLOAD_OFFSET (VSYSCALL_ADDR - __vsyscall_0 + LOAD_OFFSET)
@@ -162,7 +180,6 @@ SECTIONS
 #define VVIRT_OFFSET (VSYSCALL_ADDR - __vsyscall_0)
 #define VVIRT(x) (ADDR(x) - VVIRT_OFFSET)
 
-	. = ALIGN(4096);
 	__vsyscall_0 = .;
 
 	. = VSYSCALL_ADDR;
@@ -185,23 +202,6 @@ SECTIONS
 #undef VVIRT_OFFSET
 #undef VVIRT
 
-	__vvar_page = .;
-
-	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
-
-	      /* Place all vvars at the offsets in asm/vvar.h. */
-#define EMIT_VVAR(name, offset) 		\
-		. = offset;		\
-		*(.vvar_ ## name)
-#define __VVAR_KERNEL_LDS
-#include <asm/vvar.h>
-#undef __VVAR_KERNEL_LDS
-#undef EMIT_VVAR
-
-	} :data
-
-       . = ALIGN(__vvar_page + PAGE_SIZE, PAGE_SIZE);
-
 #endif /* CONFIG_X86_64 */
 
 	/* Init code and data - will be freed after init */
-- 
1.7.6

^ permalink raw reply related

* [PATCH 1/5] x86-64: Pad vDSO to a page boundary
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski
In-Reply-To: <cover.1311736366.git.luto@mit.edu>

This avoids an information leak to userspace.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
---
 arch/x86/vdso/vdso.S |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S
index 1b979c1..01f5e3b 100644
--- a/arch/x86/vdso/vdso.S
+++ b/arch/x86/vdso/vdso.S
@@ -9,6 +9,7 @@ __PAGE_ALIGNED_DATA
 vdso_start:
 	.incbin "arch/x86/vdso/vdso.so"
 vdso_end:
+	.align PAGE_SIZE /* extra data here leaks to userspace. */
 
 .previous
 
-- 
1.7.6

^ permalink raw reply related

* [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Andy Lutomirski @ 2011-07-27  3:20 UTC (permalink / raw)
  To: x86, Konrad Rzeszutek Wilk
  Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
	Andy Lutomirski

This fixes various problems that cropped up with the vdso patches.

 - Patch 1 fixes an information leak to userspace.
 - Patches 2 and 3 fix the kernel build on gold.
 - Patches 4 and 5 fix Xen (I hope).

Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]?
I don't have a usable Xen setup.

Also, I'd appreciate a review of patches 4 and 5 from some Xen/paravirt
people.

[1] https://gitorious.org/linux-test-utils/linux-clock-tests


Andy Lutomirski (5):
  x86-64: Pad vDSO to a page boundary
  x86-64: Move the "user" vsyscall segment out of the data segment.
  x86-64: Work around gold bug 13023
  x86-64/xen: Enable the vvar mapping
  x86-64: Add user_64bit_mode paravirt op

 arch/x86/include/asm/desc.h           |    4 +-
 arch/x86/include/asm/paravirt_types.h |    6 ++++
 arch/x86/include/asm/ptrace.h         |   19 +++++++++++++
 arch/x86/kernel/paravirt.c            |    4 +++
 arch/x86/kernel/step.c                |    2 +-
 arch/x86/kernel/vmlinux.lds.S         |   46 ++++++++++++++++++---------------
 arch/x86/kernel/vsyscall_64.c         |    6 +---
 arch/x86/mm/fault.c                   |    2 +-
 arch/x86/vdso/vdso.S                  |    1 +
 arch/x86/xen/enlighten.c              |    1 +
 arch/x86/xen/mmu.c                    |    4 ++-
 11 files changed, 64 insertions(+), 31 deletions(-)

-- 
1.7.6

^ permalink raw reply

* [PATCH] staging: hv: fix a memory leak in adj_guesttime()
From: Haiyang Zhang @ 2011-07-26 19:15 UTC (permalink / raw)
  To: haiyangz, hjanssen, kys, v-abkane, gregkh, linux-kernel, devel,
	vir

The allocated struct adj_time_work needs to be freed if we
are not using it.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>

---
 drivers/staging/hv/hv_util.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/hv/hv_util.c b/drivers/staging/hv/hv_util.c
index d3fb017..4fc1c98 100644
--- a/drivers/staging/hv/hv_util.c
+++ b/drivers/staging/hv/hv_util.c
@@ -157,7 +157,10 @@ static inline void adj_guesttime(u64 hosttime, u8 flags)
 		scnt--;
 		INIT_WORK(&wrk->work, hv_set_host_time);
 		schedule_work(&wrk->work);
+		return;
 	}
+
+	kfree(wrk);
 }
 
 /*
-- 
1.6.3.2

^ permalink raw reply related

* [PATCH 1/1] Staging: hv: util: kvp: Cleanup kvp_get_domain_name()
From: K. Y. Srinivasan @ 2011-07-26 18:03 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, virtualization
  Cc: K. Y. Srinivasan, Haiyang Zhang

Cleanup kvp_get_domain_name(). If getaddrinfo() fails, deal with it properly
(this can happen if no IP address has been assigned). Also, don't specify
a specific service in the call to getaddrinfo() to make this code as generic
as possible. Lastly, move the call to gethostname() after the local variables.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
 drivers/staging/hv/tools/hv_kvp_daemon.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/hv/tools/hv_kvp_daemon.c b/drivers/staging/hv/tools/hv_kvp_daemon.c
index 6f3e5c2..57789f9 100644
--- a/drivers/staging/hv/tools/hv_kvp_daemon.c
+++ b/drivers/staging/hv/tools/hv_kvp_daemon.c
@@ -274,22 +274,20 @@ static int
 kvp_get_domain_name(char *buffer, int length)
 {
 	struct addrinfo	hints, *info ;
-	gethostname(buffer, length);
 	int error = 0;
 
+	gethostname(buffer, length);
 	memset(&hints, 0, sizeof(hints));
 	hints.ai_family = AF_INET; /*Get only ipv4 addrinfo. */
 	hints.ai_socktype = SOCK_STREAM;
 	hints.ai_flags = AI_CANONNAME;
 
-	error = getaddrinfo(buffer, "http", &hints, &info);
+	error = getaddrinfo(buffer, NULL, &hints, &info);
 	if (error != 0) {
 		strcpy(buffer, "getaddrinfo failed\n");
-		error = 1;
-		goto get_domain_done;
+		return error;
 	}
 	strcpy(buffer, info->ai_canonname);
-get_domain_done:
 	freeaddrinfo(info);
 	return error;
 }
-- 
1.7.4.1

^ permalink raw reply related

* Re: [Xen-devel] Re: [PATCH 5/7] Xen: fix whitespaces, tabs coding style issue in drivers/xen/xenbus/xenbus_client.c
From: Ian Campbell @ 2011-07-26 16:31 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: xen-devel@lists.xensource.com, ruslanpisarev@gmail.com,
	konrad.wilk@oracle.com, Ruslan Pisarev,
	virtualization@lists.linux-foundation.org, Jeremy Fitzhardinge
In-Reply-To: <4E2EE8AC.1090703@goop.org>

On Tue, 2011-07-26 at 12:17 -0400, Jeremy Fitzhardinge wrote:
> On 07/26/2011 04:16 AM, ruslanpisarev@gmail.com wrote:
> > @@ -43,15 +43,15 @@
> >  const char *xenbus_strstate(enum xenbus_state state)
> >  {
> >  	static const char *const name[] = {
> > -		[ XenbusStateUnknown      ] = "Unknown",
> > -		[ XenbusStateInitialising ] = "Initialising",
> > -		[ XenbusStateInitWait     ] = "InitWait",
> > -		[ XenbusStateInitialised  ] = "Initialised",
> > -		[ XenbusStateConnected    ] = "Connected",
> > -		[ XenbusStateClosing      ] = "Closing",
> > -		[ XenbusStateClosed	  ] = "Closed",
> > -		[XenbusStateReconfiguring] = "Reconfiguring",
> > -		[XenbusStateReconfigured] = "Reconfigured",
> > +		[XenbusStateUnknown] =		"Unknown",
> > +		[XenbusStateInitialising] =	"Initialising",
> > +		[XenbusStateInitWait] =		"InitWait",
> > +		[XenbusStateInitialised] =	"Initialised",
> > +		[XenbusStateConnected] =	"Connected",
> > +		[XenbusStateClosing] =		"Closing",
> > +		[XenbusStateClosed] =		"Closed",
> > +		[XenbusStateReconfiguring] =	"Reconfiguring",
> > +		[XenbusStateReconfigured] =	"Reconfigured",
> >  	};
> 
> Eh, I think this looks worse now.

Me too.

If we're going to change this to anything I'd suggest
#define N(x) [XenbusState#x] = ##x
...
         N(Connected),
         N(Closing),
...
#undef N

(modulo my never quite remembering the cpp stringification rules first
time)

Ian.

^ permalink raw reply

* Re: [PATCH 5/7] Xen: fix whitespaces, tabs coding style issue in drivers/xen/xenbus/xenbus_client.c
From: Jeremy Fitzhardinge @ 2011-07-26 16:17 UTC (permalink / raw)
  To: ruslanpisarev
  Cc: Ruslan Pisarev, jeremy.fitzhardinge, xen-devel, konrad.wilk,
	virtualization
In-Reply-To: <1311679009-16659-1-git-send-email-ruslan@rpisarev.org.ua>

On 07/26/2011 04:16 AM, ruslanpisarev@gmail.com wrote:
> From: Ruslan Pisarev <ruslan@rpisarev.org.ua>
>
> This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools.
>
> Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
> ---
>  drivers/xen/xenbus/xenbus_client.c |   18 +++++++++---------
>  1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index cdacf92..ff4f03c 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -43,15 +43,15 @@
>  const char *xenbus_strstate(enum xenbus_state state)
>  {
>  	static const char *const name[] = {
> -		[ XenbusStateUnknown      ] = "Unknown",
> -		[ XenbusStateInitialising ] = "Initialising",
> -		[ XenbusStateInitWait     ] = "InitWait",
> -		[ XenbusStateInitialised  ] = "Initialised",
> -		[ XenbusStateConnected    ] = "Connected",
> -		[ XenbusStateClosing      ] = "Closing",
> -		[ XenbusStateClosed	  ] = "Closed",
> -		[XenbusStateReconfiguring] = "Reconfiguring",
> -		[XenbusStateReconfigured] = "Reconfigured",
> +		[XenbusStateUnknown] =		"Unknown",
> +		[XenbusStateInitialising] =	"Initialising",
> +		[XenbusStateInitWait] =		"InitWait",
> +		[XenbusStateInitialised] =	"Initialised",
> +		[XenbusStateConnected] =	"Connected",
> +		[XenbusStateClosing] =		"Closing",
> +		[XenbusStateClosed] =		"Closed",
> +		[XenbusStateReconfiguring] =	"Reconfiguring",
> +		[XenbusStateReconfigured] =	"Reconfigured",
>  	};

Eh, I think this looks worse now.

    J

^ permalink raw reply

* Re: [PATCH 1/7] Xen: fix whitespaces,tabs coding style issue in drivers/xen/balloon.c
From: Konrad Rzeszutek Wilk @ 2011-07-26 14:09 UTC (permalink / raw)
  To: ruslanpisarev
  Cc: Ruslan Pisarev, jeremy.fitzhardinge, xen-devel, virtualization
In-Reply-To: <1311678959-16470-1-git-send-email-ruslan@rpisarev.org.ua>

On Tue, Jul 26, 2011 at 02:15:59PM +0300, ruslanpisarev@gmail.com wrote:
> From: Ruslan Pisarev <ruslan@rpisarev.org.ua>
> 
> This is a patch to the balloon.c file that fixed up
> whitespaces, tabs errors found by the checkpatch.pl tools.

Ok, queued all of them up for 3.2.

^ permalink raw reply

* Cloudviews2011: Call for Papers
From: Ming Zhao @ 2011-07-26 13:34 UTC (permalink / raw)
  To: virtualization

The deadline is approaching: July 31st!!! Please, check our latest news at http://2011.cloudviews.org

"Cloud Computing & You"
3rd Cloud Computing International Conference (CloudViews 2011)
October 17-18, 2011
Porto, Portugal
EuroCloud Portugal
2011.cloudviews.org


Recognizing the potential of the Cloud Computing paradigm for ICT evolution, the CloudViews.Org project was launched in the end of 2007. Initially created by independent entrepreneurs, researchers and technical staff of the Porto Polytechnic Institute, CloudViews.Org aimed at promoting and discussing technologies related with Cloud Computing. Following the CloudViews.Org spirit, the EuroCloud Portugal Association (www.eurocloud.pt), a non profit organization, was created in January 2010.

The CloudViews project has already organized two international conferences on Cloud Computing. "To Cloud or not to Cloud" was the main theme of the first edition, held in Porto, Portugal, in 2009. "Cloud Ecosystem" was the theme of CloudViews 2010, which was also held in Porto, Portugal with the help of the Eurocloud Association. In that edition, academia, business people and decision makers gathered together to present their views, which motivated a lively debate where all ICT players were challenged to think about how to achieve a true Cloud Ecosystem.

CloudViews 2011, in its third edition, moves a step forward by defying academia, business people and decision makers to think about their relationship with the clouds. "Cloud Computing & You", the main theme of the third edition of CloudViews has as its main goal to raise awareness and analyse the impact of Cloud Computing on small and medium business (SME), as well as on individual users.

Around the theme "Cloud Computing & You", CloudViews 2011 welcomes contributions from several fields related to cloud computing, including, but not limited to, scientific computing applications, performance evaluation and resource management, predictability and provision platforms, storage clouds architectures and implementations, cloud computing security: models and frameworks, cloud interoperability, scheduling mechanisms, elastic platforms, service level agreements, fault tolerant architectures and implementations, human factors in computing systems, cloud usability, and business models in the cloud.

Submissions of full (8 pages maximum) and short papers (4 pages maximum) must conform to 2 columns IEEE style, in PDF format and offer new, unpublished, original contributions. All contributions must be written in English and submitted electronically through the CV2011 Easy Chair conference system at http://www.easychair.org/conferences/?conf=cloudviews2011.

Reviews will be double-blinded. Prepare your paper without any authors names or affiliations and avoid explicit self-references such as "in a previous work, we [ref]...". Give preference to sentences like: "in a previous work, Smith et al [ref]...". Also avoid the inclusion of acknowledgements and references to funding agencies in your submission version.


Program Committee (list not yet closed)

InêDutra, University of Porto, Portugal (general chair)
Alysson Bessani, University of Lisbon, Portugal
Ana Aguiar, University of Porto, Portugal
Antó Costa, Porto Polytechnic, Portugal
Antó Pinto, Porto Polytechnic, Portugal
Benedita Malheiro, Porto Polytechnic, Portugal (co-chair)
Grzegorz Malewicz, Google Research, USA
Ignacio Llorente, Complutense University of Madrid, Spain
Jack Dongarra, University of Tennessee, USA
Joaquim Filipe, Polytechnic Institute of Setú Portugal
Jorge Barbosa, University of Porto, Portugal
Jorge Gomes, LIP Lisbon, Portugal
Joséortes, University of Florida, USA
Joséogado, University Lusóa, Portugal
Jonathan Dudek, Dudek Global Partners, USA
Juan Carlos Burguillo, University of Vigo, Spain
Kate Keahey, University of Chicago & ANL, USA
Kui Ren, Illinois Institute of Technology, USA
Lía Ribeiro, University of Porto, Portugal
Marcel Kunze, Karlsruhe Institute of Technology, Germany
Marcelo Pasin, University of Lisbon, Portugal
Miguel Correia, Technical University of Lisbon, Portugal
Miguel Leitã Porto Polytechnic, Portugal (co-chair)
Paolo Romano, INESC-ID, Portugal
Paulo Calça, University of Porto, Portugal (co-chair)
Pedro Assis, Porto Polytechnic, Portugal (co-chair)
Pedro Medeiros, New University of Lisbon, Portugal
Rajkumar Buyya, University of Melbourne, Australia
Ricardo Costa, Porto Polytechnic, Portugal
Ricardo Machado, University of Minho, Portugal
Sebastian Goasguen, Clemson University, USA
Ulrich Schwickerath, CERN, Switzerland
Yong Zhao, University of Electronic Science and Technology of China, People's Republic of China


Important Dates

Submission deadline 31st July, 2011
Acceptance notification 10th September, 2011
Camera-ready deadline 10th October, 2011
Early registration deadline 15th September, 2011

^ permalink raw reply

* [PATCH 7/7] Xen: fix braces and tabs coding style issue in xenbus_probe.c This is a patch to the xenbus_probe.c file that fixed up braces and tabs errors found by the checkpatch.pl tools.
From: ruslanpisarev @ 2011-07-26 11:17 UTC (permalink / raw)
  To: jeremy.fitzhardinge
  Cc: Ruslan Pisarev, xen-devel, virtualization, konrad.wilk

From: Ruslan Pisarev <ruslan@rpisarev.org.ua>

Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
---
 drivers/xen/xenbus/xenbus_probe.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 7397695..3b53452 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -309,8 +309,7 @@ void xenbus_unregister_driver(struct xenbus_driver *drv)
 }
 EXPORT_SYMBOL_GPL(xenbus_unregister_driver);
 
-struct xb_find_info
-{
+struct xb_find_info {
 	struct xenbus_device *dev;
 	const char *nodename;
 };
@@ -651,7 +650,7 @@ int xenbus_dev_cancel(struct device *dev)
 EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
 
 /* A flag to determine if xenstored is 'ready' (i.e. has started) */
-int xenstored_ready = 0;
+int xenstored_ready;
 
 
 int register_xenstore_notifier(struct notifier_block *nb)
@@ -774,7 +773,7 @@ static int __init xenbus_init(void)
 
 	return 0;
 
-  out_error:
+out_error:
 	if (page != 0)
 		free_page(page);
 
-- 
1.7.4.1

^ permalink raw reply related

* [PATCH 6/7] Xen: fix braces coding style issue in xenbus_probe.h
From: ruslanpisarev @ 2011-07-26 11:17 UTC (permalink / raw)
  To: jeremy.fitzhardinge
  Cc: Ruslan Pisarev, xen-devel, virtualization, konrad.wilk

From: Ruslan Pisarev <ruslan@rpisarev.org.ua>

This is a patch to the xenbus_probe.h file that fixed up braces errors found by the checkpatch.pl tools.

Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
---
 drivers/xen/xenbus/xenbus_probe.h |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus_probe.h
index 888b990..22dfd4e 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus_probe.h
@@ -36,8 +36,7 @@
 
 #define XEN_BUS_ID_SIZE			20
 
-struct xen_bus_type
-{
+struct xen_bus_type {
 	char *root;
 	unsigned int levels;
 	int (*get_bus_id)(char bus_id[XEN_BUS_ID_SIZE], const char *nodename);
-- 
1.7.4.1

^ permalink raw reply related

* [PATCH 5/7] Xen: fix whitespaces, tabs coding style issue in drivers/xen/xenbus/xenbus_client.c
From: ruslanpisarev @ 2011-07-26 11:16 UTC (permalink / raw)
  To: jeremy.fitzhardinge
  Cc: Ruslan Pisarev, xen-devel, virtualization, konrad.wilk

From: Ruslan Pisarev <ruslan@rpisarev.org.ua>

This is a patch to the xenbus_client.c file that fixed up whitespaces, tabs errors found by the checkpatch.pl tools.

Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
---
 drivers/xen/xenbus/xenbus_client.c |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index cdacf92..ff4f03c 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -43,15 +43,15 @@
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
-		[ XenbusStateUnknown      ] = "Unknown",
-		[ XenbusStateInitialising ] = "Initialising",
-		[ XenbusStateInitWait     ] = "InitWait",
-		[ XenbusStateInitialised  ] = "Initialised",
-		[ XenbusStateConnected    ] = "Connected",
-		[ XenbusStateClosing      ] = "Closing",
-		[ XenbusStateClosed	  ] = "Closed",
-		[XenbusStateReconfiguring] = "Reconfiguring",
-		[XenbusStateReconfigured] = "Reconfigured",
+		[XenbusStateUnknown] =		"Unknown",
+		[XenbusStateInitialising] =	"Initialising",
+		[XenbusStateInitWait] =		"InitWait",
+		[XenbusStateInitialised] =	"Initialised",
+		[XenbusStateConnected] =	"Connected",
+		[XenbusStateClosing] =		"Closing",
+		[XenbusStateClosed] =		"Closed",
+		[XenbusStateReconfiguring] =	"Reconfiguring",
+		[XenbusStateReconfigured] =	"Reconfigured",
 	};
 	return (state < ARRAY_SIZE(name)) ? name[state] : "INVALID";
 }
-- 
1.7.4.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox