public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Cc: kernel-hardening@lists.openwall.com, linux-doc@vger.kernel.org,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <keescook@chromium.org>,
	Laura Abbott <labbott@redhat.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v2] kconfig: add hardened defconfig helpers
Date: Sun, 9 Sep 2018 21:19:03 +0200	[thread overview]
Message-ID: <20180909191903.GA2344@ravnborg.org> (raw)
In-Reply-To: <1536516257-30871-1-git-send-email-s.mesoraca16@gmail.com>

Hi Salvatore.

On Sun, Sep 09, 2018 at 08:04:17PM +0200, Salvatore Mesoraca wrote:
> Adds 4 new defconfig helpers (hardenedlowconfig, hardenedmediumconfig,
> hardenedhighconfig, hardenedextremeconfig) to enable various hardening
> features.
> The list of config options to enable is based on KSPP's Recommended
> Settings and on kconfig-hardened-check, with some modifications.
> These options are divided into 4 levels (low, medium, high, extreme)
> based on their negative side effects, not on their usefulness.
> 'Low' level collects all those protections that have (almost) no
> negative side effects.
> 'Extreme' level collects those protections that may have so many
> negative side effects that most people wouldn't want to enable them.
> Every feature in each level is briefly documented in
> Documentation/security/hardenedconfig.rst, this file also contain a
> better explanation of what every level means.
> To prevent this file from drifting from what the various defconfigs
> actually do, it is used to dynamically generate the config fragments.

In the above you nicely describes what is done.
But there is nothing about the target group for this feature.
Who will benefit from this?

With respect to the actual implmentation we now
have two ways to handle config fragments.
Current solution is to save the config fragments in kernel/configs.
And the new solution is to parse the config fragments from an rst file.
The changelog fails to mentions why we need a new way to handle
the config fragments.

If we want to go the "parse from rst file" way - can it then
be abstracted in a way so this is the only way to handle
these in-kernel config fragments?
And then move the current config fragment to the new way.

It most be possible with a little careful design to make this
a general solution and not a hardening thing only.

	Sam

  reply	other threads:[~2018-09-10  0:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-09 18:04 [PATCH v2] kconfig: add hardened defconfig helpers Salvatore Mesoraca
2018-09-09 19:19 ` Sam Ravnborg [this message]
2018-09-10  1:21   ` Masahiro Yamada
2018-09-16 17:44     ` Salvatore Mesoraca
2018-09-16 17:14   ` Salvatore Mesoraca
2018-09-09 20:27 ` Jonathan Corbet
2018-09-16 17:38   ` Salvatore Mesoraca

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=20180909191903.GA2344@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=corbet@lwn.net \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=s.mesoraca16@gmail.com \
    --cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox