lkml.org 
[lkml]   [2006]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] paravirt.h
From
Date
On Tue, 2006-08-22 at 07:59 -0700, Jeremy Fitzhardinge wrote:
> Alan Cox wrote:
> > It would be nice not to export it at all or to protect it, paravirt_ops
> > is a rootkit authors dream ticket. I'm opposed to paravirt_ops until it
> > is properly protected, its an unpleasantly large security target if not.
> >
>
> Do you have an example of an attack which would become significantly
> easier with pv_ops in use? I agree it might make a juicy target, but
> surely it is just a matter of degree given that any attacker who can get
> to pv_ops can do pretty much anything else.

it makes for a "clean" and robust rootkit rather than a fragile one

>
> > It would be a lot safer if we could have the struct paravirt_ops in
> > protected read-only const memory space, set it up in the core kernel
> > early on in boot when we play "guess todays hypervisor" and then make
> > sure it stays in read only (even to kernel) space.
> >
>
> Yes, I'd thought about doing something like that, but as Arjan pointed
> out, nothing is actually read-only in the kernel when using a 2M

that's why there is a config option :) THe 2Mb advantage is a bit
overrated btw; there are very few such tlbs in current processors so the
kernel gets tlb misses anyway. And since most of the code is in the
first 2Mb (which isn't broken up) of the kernel text it's not that bad
tlb wise either

(and it was Andi that pointed that out, not me)

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

\
 
 \ /
  Last update: 2006-08-22 17:15    [W:0.095 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site