Re: [Xen-devel] RFC: removing hardcoded "modprobe blktap" in xencommons

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Jul 15, 2013 at 07:06:52AM +0100, Jan Beulich wrote:
> >>> On 12.07.13 at 18:12, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > Back before 4.3 release you complaint about the hardcoded modprobe for
> > blktap / blktap2 in xencommons script. I started to look into it this
> > week and tried to do this modprobe automatically in libxl (that's the
> > idea we discussed before 4.3 IIRC).
> > 
> > Unfortunately I didn't manage to find any canonical documents on how a
> > user space process can trigger a modprobe. I've looked at kernel
> > documentations and couldn't find any. Do you have any reference on how
> > to do that?
> 
> Not sure what you're asking about. system("modprobe <modname>")
> is what I'd start with, or utilizing any process spawning internal
> interface libxl already has.
> 

I'm asking because:

1) removing that specific one-liner requires giantic amount of work --
   around 200 lines of code plumbing into libxl's AO interface
2) not all libxl consumers has the necessary privilege to run modprobe
   AIUI.

> > And, why do you think it is bad to have "modprobe blktap" in xencommons?
> > What about not removing it?
> 
> I think the discussion why this is a bad idea was long settled: It is
> bad practice to load all sorts of stuff regardless of whether it's
> actually used - not only from a resource usage pov, but also from
> a security one (less kernel code running implies less kernel bugs to
> worry about allowing an eventual exploit).
> 

Agreed. This issue should be ideally fixed for all drivers using the
loading methanism mentioned by Konrad. However blktap is unmaintained I
don't know how feasible it is to modify its source code and push this
change to ancient kernels.


Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel