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

RE: [Xen-devel] grsecurity +XEN w/o HVM

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "John Anderson" <johnha@xxxxxxxxxx>
  • Date: Tue, 27 Jun 2006 11:29:02 -0700
  • Delivery-date: Tue, 27 Jun 2006 11:29:27 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcaZyFPnSs7DRVtfR0+M/OnuIIw03wATwolg
  • Thread-topic: [Xen-devel] grsecurity +XEN w/o HVM

Thanks very much,

It appears to have done the trick, at least on x86_64.  I wish I could get the 
i386 grsec kernel too boot so I could test it there too! :-).

John A.

-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
Sent: Tuesday, June 27, 2006 2:02 AM
To: John Anderson
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] grsecurity +XEN w/o HVM

> I surrounded the tss_struct declaration and the 
> tss->esp0/current->thread.esp0 assignments with #ifdef 
> CONFIG_X86_NO_TSS lines to get the kernel to compile.  That completely 
> defeats the purpose of this function which is to randomize the kernel 
> stack.  What is available in Xen that is comparable to the capacity 
> that struct tss_struct is used in if CONFIG_X86_NO_TSS is defined?
> Any ideas would be greatly appreciated.

Only the declaration and uses of the 'tss' local variable should be 
CONFIG_X86_NO_TSS. You'll still need to modify current->thread.esp0, 
and then execute HYPERVISOR_stack_switch(KERNEL_DS, 

  -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.