Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2223325imm; Sun, 9 Sep 2018 19:25:42 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbJN3I55xMxE5Kvb2fvUdYob/pBCZgocgyQU0M6WsL2nYK2SwUoaT039HhaGRsL7gytnmG/ X-Received: by 2002:a62:ca0d:: with SMTP id n13-v6mr21157836pfg.69.1536546342545; Sun, 09 Sep 2018 19:25:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536546342; cv=none; d=google.com; s=arc-20160816; b=xeSYDONLbAA7F4wxhOVeZ0jV8BDhXGqpxgk77sVgsW1vRyaiC7PJmX5w5gGmxrllVb Y55k2ub08Zw4LNqau7jOouJfzhYsRifULt7q0ItjrmzK3vLmEvwsS+NTrwafyEkMHKbz Xf73I2Z5S+GmSRkA4hT3GY4Dym3BWqNB2w7nV2HJaMgEk/jQRBzGO8YsqUNyR+bzVnVD 90wdeSs+BIdpzyJ7XJ81AdY7jZIF5xjdBR5eJ+x8aDP7aemQN3TmcwbjuTrUsfrGgQ3e 2tNoTw0KN1PjkKf200YxZX46TqQl9o6LN8oN3bsTgUTu+gL5MH+qNX+84XSbJX+Jf/V5 /tbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-filter; bh=vcBNZMjqeXYNvcFuq4WI6tvwMsZLpSuzVBjtFRwU22g=; b=UlnalXtSAkqKBLIJH1YccVcY6J4QplKwtzhP5/hGcFM/3Kiw9CWHeos31rpD5gc3Np dnphOa37sW0kUpKxQ0uYDMmNh6Ak/qOQig+PrDheL9uKWQJ3p5TTZL0P/77z6WUmP5++ wYfKRJxu6zyZylF6C58fmTc72aDrYkR+Kf3x7V17zXIbzvS1sHDJMDKcYgXuJTKB71ZK 7/N+J1jm3xV/uLI6fKwvSbXW2jN97HQSnRldrhqOvRbEBXxDdC33qJ+844Ens8m/YWeq EWXiys5PjOpKcfznAgDle2mnsONKKGDSebICOcSUCMps9ZQ418RZLXYtJpdA5X4XlFh2 16uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=PjiVXpco; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l30-v6si15751567pgn.238.2018.09.09.19.25.27; Sun, 09 Sep 2018 19:25:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=PjiVXpco; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726547AbeIJHPu (ORCPT + 99 others); Mon, 10 Sep 2018 03:15:50 -0400 Received: from condef-05.nifty.com ([202.248.20.70]:30428 "EHLO condef-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725889AbeIJHPt (ORCPT ); Mon, 10 Sep 2018 03:15:49 -0400 X-Greylist: delayed 491 seconds by postgrey-1.27 at vger.kernel.org; Mon, 10 Sep 2018 03:15:47 EDT Received: from conssluserg-01.nifty.com ([10.126.8.80])by condef-05.nifty.com with ESMTP id w8A1MhDD012837; Mon, 10 Sep 2018 10:22:43 +0900 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (authenticated) by conssluserg-01.nifty.com with ESMTP id w8A1MNuB015036; Mon, 10 Sep 2018 10:22:24 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com w8A1MNuB015036 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1536542544; bh=vcBNZMjqeXYNvcFuq4WI6tvwMsZLpSuzVBjtFRwU22g=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=PjiVXpco51aPoeJYx1NdVQc7zdkSnmudOMjTTfScg6Qsm1J9vT2ycaTJKRax/fJ7X w+Ll8MZKsKjFGscx0JsI1qhrx5PMwpRFw1MpjyneFRoehpFoLGXQHOQtKux9aJ4rl+ criabO+/Y3rCEKpgZkECn+M8GVfbJ6pEl62iNyaPzJ/mkb5pO+fSXPvk5EcYG4qzwK Z+IRSDinbwJkfmEcj1Sn9/+jeYmeaQVFUE5jF8N6spChL1HEi/BOrsGPJTEJQjQolD ZCB6oED6kO1T0Lsd6YNWgZs3CociPkdGDEdUtuexMjqNT+1fDHXL+t6hXVso9hXM9S UYk9TbMg7iB9g== X-Nifty-SrcIP: [209.85.221.171] Received: by mail-vk1-f171.google.com with SMTP id l143-v6so2758480vke.1; Sun, 09 Sep 2018 18:22:24 -0700 (PDT) X-Gm-Message-State: APzg51CjuPnC7EFF3EPQLkeQDn4r/4E4e1gET8c+uq8DakBbvTFCiUdU 3TCop5e8nOifJRTruMpBbgyBCZTXZP7m2NrCTrU= X-Received: by 2002:a1f:9004:: with SMTP id s4-v6mr5719595vkd.10.1536542543316; Sun, 09 Sep 2018 18:22:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:7111:0:0:0:0:0 with HTTP; Sun, 9 Sep 2018 18:21:42 -0700 (PDT) In-Reply-To: <20180909191903.GA2344@ravnborg.org> References: <1536516257-30871-1-git-send-email-s.mesoraca16@gmail.com> <20180909191903.GA2344@ravnborg.org> From: Masahiro Yamada Date: Mon, 10 Sep 2018 10:21:42 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] kconfig: add hardened defconfig helpers To: Sam Ravnborg Cc: Salvatore Mesoraca , Kernel Hardening , "open list:DOCUMENTATION" , Linux Kbuild mailing list , Linux Kernel Mailing List , Jann Horn , Jonathan Corbet , Kees Cook , Laura Abbott , Michal Marek , "Eric W. Biederman" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-09-10 4:19 GMT+09:00 Sam Ravnborg : > 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. I agree. Another new way this patch added is, CONFIG options are now described in the ReST document, but our current way is to describe the detailed information in the 'help' section in Kconfig files. > 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 Indeed. The file format is too specific for his purpose; 'Negative side effect level' is a key word that must be placed 3 lines below the CONFIG entry. -- Best Regards Masahiro Yamada