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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 16 Jul 2012 09:43:03 -0700 (PDT)
From:	david@...g.hm
To:	Borislav Petkov <bp@...64.org>
cc:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Pekka Enberg <penberg@...nel.org>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
	Debian Kernel Team <debian-kernel@...ts.debian.org>,
	OpenSUSE Kernel Team <opensuse-kernel@...nsuse.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Sasha Levin <levinsasha928@...il.com>,
	Asias He <asias.hejun@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration
 for distro issues

On Mon, 16 Jul 2012, Borislav Petkov wrote:

> On Sun, Jul 15, 2012 at 03:09:12PM -0700, david@...g.hm wrote:
>> On Mon, 16 Jul 2012, Cyrill Gorcunov wrote:
>>
>>> Replying to David's message (sorry for delay) I fear having a bunch of
>>> miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since
>>> I've no time at moment to read kconfig code and I'm not sure if this
>>> is right direction at all) it would worth to add some new keyword to
>>> kconfig language, say "profile", which would tag symbol to a category
>>> if needed, and these categories included into profiles automatically.
>>> On the other hands this might end up in a mess as well.
>>
>> I have a couple problems with the approach of modifying the existing
>> kconfig files
>>
>> 1. how does it handle the case when a profile wants something one
>> way and the admin wants it another way
>
> Select the profile and then fixup the config the normal way.
>
> If what the admin wants is incompatible with the profile, admin doesn't
> select the profile.
>
>>   the example is the fedora default wanting SELINUX and I want some
>> other LSM
>
> Currently, if you run fedora and want something that's not enabled, you
> recompile your kernel too, right?

The problem is that you can't select the Fedora profile and then unselect 
SELINUX, so the profile will do you no good.

It's not a matter of needing to recompile or not, it's a mattter that when 
you want to recompile, you want to be able to easily select the 
infrastructure pieces that the distro needs to operate, without also 
getting their huge selection of 'other' things.

>> 2. since it requires making changes in the upstream kernel source, the
>> number of people who can make these changes is small.
>
> I think that's moot since you either select the profile or you don't.
>
>> 3. since all these changes go into the upstream kernel source, changes
>> to these profiles are going to be visible churn (think of the issues
>> with the defconfigs for ARM a couple of years ago)
>
> AFAICT, those changes will be needed only for a new distro release and
> that happens twice a year, tops.
>
>> 4. the complexity of tagging all possible profiles is very high.
>
> That's why we start simple.
>
>> Even if you limit the profiles to "Linux Distros", how many different
>> distros are there? Do you really want to have to start arguing over
>> which distros are large enough to get their profile added to the
>> upstream kernel source?
>
> That's a valid question; its answer could be defined arbitrarily.
>
> <joshing>
> Let's say all distros which make money - more than a certain large
> amount - are allowed. :-)
> </joshing>

So that would eliminate all linux distros except for Red Hat Enterprise 
and Suse (including eliminating opensuse and fedora), somehow I don't 
think that would produce the benefit that Linus was looking for.

>> If instead we go with something along the lines of the miniconf
>> approach, the picture looks very different
>>
>> 1. this approach only sets things one time, after that the person
>> doing the compile is free to change anything.
>
> ...
>
> Sorry, I don't see the simplification: you need to rebuild your kernel
> anyway and before you rebuild it, you can do all the changes you want.
> So either you select a profile or you load a miniconfig, it doesn't
> really matter how you do it?

Yes, you have to recompile in any case.

The difference is that with a profile, the profile must be in the kernel 
source, and you will have problems if you want to start with the profile 
and then tweak something.

with miniconfig, you can have locally defined configs, you can combine 
multiple configs, and the configs define a starting point, but you can 
then override them if you want to.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ