[PATCH v2 0/7] makedumpfile security key filtering with eppic

[Atsushi Kumagai]

Hello,

On Fri, 16 Nov 2012 09:36:49 -0500
Vivek Goyal <vgoyal at redhat.com> wrote:

> On Fri, Nov 16, 2012 at 03:22:50PM +0530, Aravinda Prasad wrote:
> > 
> > 
> > On 2012-11-15 21:25, Vivek Goyal wrote:
> > 
> > > On Thu, Nov 15, 2012 at 09:27:45AM -0500, Dave Anderson wrote:
> > > 
> > > [..]
> > >>> Yes, makedumpfile needs to be linked against eppic library for filtering
> > >>> data and this will increase makedumpfile size and initramfs size too.
> > >>
> > >> Just to clarify -- your example indicates that the vmlinux file is required
> > >> for this facility to work, correct?
> > >>  
> > >>> makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore
> > >>
> > >> Clearly distros won't be putting the vmlinux file in the initramfs -- that's
> > >> the whole reasoning behind vmcoreinfo.  So the 99% of users that aren't
> > >> interested in scrubbing will have to pay the penalty of the larger makedumpfile
> > >> binary.
> > > 
> > > That's a good point Dave. We will never put debug compiled vmlinux in 
> > > initramfs. Following two alternatives come to my mind.
> > 
> > 
> > As I mentioned, we don't need vmlinux in initramfs as filtering is done
> > during post processing only.
> 
> You are missing the point. The point is that despite the fact that
> scrubbing will never be done from initramfs, all the users will pay
> penalty for increased makedumpfile size.
> 
> So why not write a separate tool (scrub-vmcore) so that makedumpfile
> users don't pay the bloated size penatly.

As Vivek said, I think it's difficult to persuade almost all distributor
to specify EPPIC=on.

So, it seems that separate tool is better way for both user and distributor.
If you will make it, I will drop eppic support from v1.5.1 and export core
functions from makedumpfile as library for such tools in the future.

Does this meet your purpose, Aravinda ?


Thanks
Atsushi Kumagai