Message-Id: <1369342863.25917.140661234919793.65D0DC1F@webmail.messagingengine.com>
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: Alpine <alpine-devel@lists.alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Subject: [alpine-devel] kernel config diffs made easy!
Date: Thu, 23 May 2013 17:01:03 -0400

...or at least merely tedious, not mind-numbingly stupefying.

I was following up on this exchange:

On Fri, May 17, 2013, at 02:04 PM, Natanael Copa wrote:
> > I've got Alpine installed as a Xen guest on a Linode instance. To do
> > this, I built my own stripped-down Xen-guest-only kernels. (The x86_64
> > linux-grsec also worked, but the x86 one doesn't have Xen stuff turned
> > on. I didn't try Alpine's linux-xen package, which is intended for Xen
> > hosting, and so enables stuff I didn't need/want on my guest instances).
> >
> > If anyone else is interested in these stripped-down kernel configs,
> > perhaps we could make an additional kernel package. 
>
> Yes, I am interested, but I'd like a kernel for a generic virtual guest
> that works for xen, kvm, virtualbox, vmware and hyper-v. We have the
> linux-virt-grsec kernel for this purpose
> http://git.alpinelinux.org/cgit/aports/tree/testing/linux-virt-grsec
>
> Unfortunally, it is lagging behind. If you use it and plan to maintain
> it anyways... maybe you could help us maintain it?
>
> I would be ok to start over with your config and then add other virtual
> drivers on request.

and I figured there were likely to be some scripts or libraries out
there to make dealing with Kconfig files easier. I found this nice
Python library:<https://github.com/ulfalizer/Kconfiglib>. I've created a
wrapper around that library that takes several kernel config files and
lets you manipulate representations of them in an interactive python
session. Here's the wrapper:
<https://gist.github.com/dubiousjim/5638961/raw/kconfig-diff.py>.

I've run it on our own linux-grsec kernel config, x86, for kernel 3.9.2.
This differs from the default kernel settings at 2946 modifiable
symbols, and 25 modifiable choices. (One might also consider comparing
it to "allno" and "allyes" kernel configs, or to configs from, e.g.,
Gentoo hardened.)

But my present aim was to compare the xenguest kernel config I had made,
and described above, and also the linux-virt-grsec config, to our main,
linux-grsec kernel config.

My xenguest config differs from the "main" linux-grsec config at: 331
modifiable symbols and 6 modifiable choices.

An "updated" version of the linux-virt-grsec config differs from either
xenguest or linux-grsec at: 1469 modifiable symbols and 10 modifiable
choices.

What I mean by "updated" is I just took the old config (for
3.4.something) and installed it in the 3.9.2 kernel source tree, then
did 'make silentoldconfig' and selected all the default choices.
Probably the xenguest config is closer to what we want, though I think
not in every respect.

A page listing all of the linux-virt-grsec differences, together with
help text and so on for each symbol or choice, is posted here:
https://gist.github.com/dubiousjim/5638961/raw/kernel_comparisons

That's a large file (1.3M), but perhaps when some of you are bored you
could help look through some of the things listed there and weigh in on
a few of them: I think this setting should be blah, this other setting
should be foo, and so on.

I'd recommend reading the doc text at the start of the "wrapper" I
linked to above, to understand the listings better.

When I first read this exchange with Natanael, I thought bringing the
linux-virt-grsec into synch with 3.9.x kernel releases would give me
what I wanted for a Xen guest-only kernel config. Now I'm no longer so
sure. I disabled all the hardware drivers on my xenguest config, because
the xen host should deal with them. I also disabled some things like
acpi, and even the xen frontends for sound and framebuffer video,
because this machine is running in some remote datacenter. Some of these
choices I made might be incorrect, even for my intended uses. Some of
them may be correct, but idiosyncratic to my intended uses, and not
generally applicable to a Xen-guest-only kernel. Let's ignore all of
those things, and assume we're aiming at creating a kernel config
suitable for general use but only as a Xen guest. The question then is:
how much would that differ from the somewhat more general uses Natanael
describes linux-virt-grsec as targeting? Can kvm, virtualbox, vmware and
hyper-v also turn off all direct hardware drivers and so on? (From a
casual lookover, it seems that currently, linux-virt-grsec doesn't do
so.)



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---