linux-kernel - Re: [PATCH] paravirt.h

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: <1156296940.12015.25.camel@localhost.localdomain>
Date:	Wed, 23 Aug 2006 11:35:40 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>, Andi Kleen <ak@....de>,
	Andrew Morton <akpm@...l.org>,
	virtualization <virtualization@...ts.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH] paravirt.h

On Tue, 2006-08-22 at 14:56 +0100, Alan Cox wrote:
> Ar Iau, 2006-08-10 am 11:06 -0700, ysgrifennodd Jeremy Fitzhardinge:
> > Rusty Russell wrote:
> > > +EXPORT_SYMBOL_GPL(paravirt_ops);
> > >   
> > This should probably be EXPORT_SYMBOL(), otherwise pretty much every 
> > driver module will need to be GPL...
> 
> 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.
> 
> 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.
> 
> Once you can't patch it then the worries about rootkits and patching it
> that might make people want it particularly to be _GPL should mostly go
> away too.

I am writing a test hypervisor interface in a module, so this is a
feature not a bug.

We can certainly move it to some read-protected page, but then the
module will simply unprotect it and alter it.

Now, discarding the patching information makes life harder, but you can
simply scan the text segments to find them again, or just trap when they
happen and patch dynamically (but this won't work for pushf and popf, if
you care about them).

I realize that the virtualizing-root-kit is a sexy idea, I'm just not
sure that paravirt_ops an effective place to be looking for a solution.

Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law

-
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/