From: Kees Cook <keescook@chromium.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: ksummit-discuss@lists.linuxfoundation.org,
Michal Hocko <mhocko@kernel.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?
Date: Tue, 27 Jun 2017 13:41:14 -0700 [thread overview]
Message-ID: <CAGXu5jJWH2cUnr5yiYS90SzROa3coZcgeRKEYOYYwhLUK8aPtw@mail.gmail.com> (raw)
In-Reply-To: <20170627135839.GB1886@jagdpanzerIV.localdomain>
On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> Hello,
>
> am I the only one who struggle with the Kconfig sometimes? can there
> be a way to make it more general/simpler, in some parts at least? e.g.
> the hardening effort? (just an example. *ABSOLUTELY NOT* blaming Kess
> or anyone else who is involved, that's not the point, they are doing
> great job, no doubt. it's just the most recent thing I saw was
> CONFIG_SLAB_MERGE_DEFAULT). do people who really want to harden their
> kernels go all-in anyway (enable all of the options at once)? if so,
> can there be a single Kconfig option then? just curious.
We've removed failed "single Kconfig options" in the past (e.g.
CONFIG_EXPERIMENTAL), so I'm not excited about trying that again. I
agree with Linus, though, Kconfig is still a mess.
As for why I think CONFIG_HARDENED specifically wouldn't work is
because of distro tolerances for security features. Some things are
"too much" for them (e.g. slab sanitization), but they want things
with lower overhead (e.g. hardened usercopy). And if one feature is
going to be under CONFIG_HARDENED, but not the other, then why not? Do
we then need CONFIG_HARDENED_A_LITTLE and CONFIG_HARDENED_PARANOID?
And then that'll get bike-shed too. Ultimately providing granularity
appears to be better than not providing it, but we still end up with
the mess that in Kconfig... :(
(I see mention of "make def..." in other replies, I'll comment there next...)
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2017-06-27 20:41 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-27 13:58 [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes? Sergey Senozhatsky
2017-06-27 17:18 ` Linus Torvalds
2017-06-27 18:44 ` Luis R. Rodriguez
2017-06-27 19:27 ` Linus Torvalds
2017-06-27 20:53 ` Kees Cook
2017-06-27 21:16 ` Olof Johansson
2017-06-27 21:36 ` Linus Torvalds
2017-06-27 23:10 ` Serge E. Hallyn
2017-06-28 0:09 ` Luis R. Rodriguez
2017-06-28 0:14 ` Linus Torvalds
2017-06-28 0:26 ` Luis R. Rodriguez
2017-06-28 3:54 ` Stephen Hemminger
[not found] ` <CAFhKne-o0S8fMo_XD_aUk2Rf7VbDhgO+PT_bjnM-9WpKfnWBvw@mail.gmail.com>
[not found] ` <CAFhKne8FE=17wNdp=Svf2Z2tADok6htfYqTABEiZUrCOyeMaYg@mail.gmail.com>
2017-06-28 13:35 ` Matthew Wilcox
2017-06-28 17:56 ` Geert Uytterhoeven
2017-06-29 10:02 ` Mauro Carvalho Chehab
2017-06-28 0:11 ` Linus Torvalds
2017-06-29 10:23 ` Mauro Carvalho Chehab
2017-06-28 12:58 ` Dan Carpenter
2017-06-30 17:11 ` Steven Rostedt
2017-06-30 17:52 ` Darren Hart
2017-06-30 17:58 ` Darren Hart
2017-07-01 17:24 ` Hannes Reinecke
2017-06-27 20:41 ` Kees Cook [this message]
2017-07-06 14:40 ` Dan Carpenter
2017-07-06 14:41 ` [Ksummit-discuss] [PATCH 1/2] kconfig: add a silent option to conf_write() Dan Carpenter
2017-07-06 15:08 ` Steven Rostedt
2017-07-06 14:42 ` [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool Dan Carpenter
2017-07-07 5:55 ` Krzysztof Kozlowski
2017-07-07 9:02 ` Dan Carpenter
2017-07-09 3:56 ` Linus Walleij
2017-07-09 8:31 ` Geert Uytterhoeven
2017-07-09 17:03 ` Randy Dunlap
2017-07-09 19:43 ` Geert Uytterhoeven
2017-07-09 17:32 ` Frank Rowand
2017-07-10 9:44 ` Geert Uytterhoeven
2017-07-10 11:15 ` Dan Carpenter
2017-07-06 16:41 ` [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes? Linus Torvalds
2017-07-06 17:11 ` Randy Dunlap
2017-07-07 11:36 ` Dan Carpenter
2017-07-10 17:15 ` Luck, Tony
2017-07-10 17:33 ` Alexandre Belloni
2017-07-10 18:28 ` Linus Torvalds
2017-07-10 19:44 ` Randy Dunlap
2017-07-11 6:21 ` Valentin Rothberg
2017-07-06 21:19 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXu5jJWH2cUnr5yiYS90SzROa3coZcgeRKEYOYYwhLUK8aPtw@mail.gmail.com \
--to=keescook@chromium.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mhocko@kernel.org \
--cc=sergey.senozhatsky.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.