RE: [Xen-users] Anti-virus for use in para-virtualized Xen

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Mark Greenbank
> Sent: 04 April 2007 17:42
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Anti-virus for use in para-virtualized Xen
> 
> 
> On 4/4/07, Petersson, Mats <Mats.Petersson@xxxxxxx> wrote:
> 
> 
> 
>       > -----Original Message-----
>       > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
>       > [mailto: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> <mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx> ] On Behalf Of
>       > Nico Kadel-Garcia
>       > Sent: 04 April 2007 16:42
>       > To: xen-users@xxxxxxxxxxxxxxxxxxx
>       > Subject: [Xen-users] Anti-virus for use in 
> para-virtualized Xen 
>       >
>       >
>       > I've been looking at anti-virus software for Xen use on Linux
>       > systems,
>       > on both Dom0 and DomU, in industrial environments. Reviewing
>       > documentation on various packages seems to show that all the 
>       > commercial
>       > ones insist on sticking kernel modules into a limited 
> set of standard
>       > known kernels. This of course creates some serious 
> risks until the
>       > anti-virus packages are developed in and tested in 
> Xen environments, 
>       > especially for para-virtualized environments.
>       
>       I presume the reason they have a standard set of 
> kernels is that they
>       "meddle" with the kernel and don't supply source-code, 
> which means that
>       a Xenified kernel doesn't match the expected kernel 
> layout, and thus
>       can't use the module? [And it's understandable from 
> some aspects that
>       the AV guys don't really want the V-guys to see the 
> source-code...] 
> 
> 
> This is a serious limitation with the way the kernel is 
> architected -- a defined kernel interface (e.g., DDI/DKI for 
> both function calls and structures) and loadable 
> modules/drivers are not encouraged, which means that there is 
> a proliferation of customized kernels out there. This really 
> limits the utility of the Linux kernel in a production 
> envronment. I myself am stuck at Core 5 for my (production) 
> laptop since I'm worried that upgrading to the 
> latest+greatest disto will break my VMWare installation and 
> various other components that depend on interfacing with the 
> kernel. I'd love to move to Core 6 but I don't have enough 
> pain to live with having to hack the VMWare modules. With 
> Core 7 around the corner, I suspect that my motivation to 
> hack will increase :) 

I can't say that I disagree. 

There is a problem with this in many OS's tho', not just Linux. Windows
certainly have problems with the interface for AV-software in the sense
that AV-software wants to hook into things that don't have official
hooks. This is not so bad when you only have one hooker(sic), as the
software can "just" modify the system-call table. But what happens when
it's already been modified by someone software that got loaded first...
:-(

The real problem here is that AV-software (and other software that
interfaces with what you are allowed to do and what you aren't) can
sometimes need to use things that the publicly available interface
doesn't supply. Changing the interface for future versions is great, but
there are big problems with changing EXISTING installations such that
it's both backwards compatible and support the new API at the same time.


[I'm not an EXPERT on AV-software, but I know a little bit about how it
works and what they (try to) do in it - and there's of course MANY
different varieties available]. 

--
Mats
> 
> Mark
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users