From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AIpwx49j9Vd9lSfYZoBadt9LUw/vi1FQaJWcS/U0XZzpNsLtOPXzO6rGcm+OUGvxRsWSY34sgnKG ARC-Seal: i=1; a=rsa-sha256; t=1523173485; cv=none; d=google.com; s=arc-20160816; b=RnLDWfaqwHRF2WELZQcyShnLqkEg7KU4uLvRcCR9hxUB2zHle3pS0LOF2Bg38mD0EQ PVK75NiDnIsho3I/ssgnDUVim8PbRPAGzdzt4QW7aE3uoj9x3QJDBE/QFvs+O6vKcwuU MUybbNnGdj2WpSTYLV33H/TtjWYjw0OqNmWtvGqRnEpcdOQRSo2fzLEc2dDbIo+H/kn7 tLTtZK3tr4dqTeDxvZKnuGPsgOrX+DkYg5uMLSeqm9UHEtfjluwajXPaFXVsI7mW0Ra4 WWuDF5JY8XXkRFf6KJa/S8Ak/SdjEPdDx4vmIPzFIMCzxFkEntMX5IxG1jnSN7bvXdyj utKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=nGoFMcTrcd2g77s680GoA0wKMU5vdzuWHC07S72uY2E=; b=fwfCVDLbzFV3sn4pRsfBLakuQ2NxM4IptHVKtS06EiaG/ekG5xMB3+eXqSFUs+l4TM r92/aiNTwj9pNvoqkvMHCXUoqFSeYSeoNhAbYrHJS3BjtlVpvtKpy4VcvrYv/+qz6Pij 6emMUILYcVe2PcsmzEXJvPpMc1Wk18Snb+yPljWvgQIHMlKwDOe+3mKYwTW3KNxbSNLj sYsmFuCdT9iC39CCbhrjf77z1zMHPVwEkwenKdo2gVYLkJHRwKcD2FI5/QF6dH/IhJxq COeFLvmN2vBMw1eURTMvMZO6FicXx05Igbz6DHWRVst8MJCx5GghHaiSQsFQNrEmVlgt EMtw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jlee@suse.com designates 195.135.221.5 as permitted sender) smtp.mailfrom=jlee@suse.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of jlee@suse.com designates 195.135.221.5 as permitted sender) smtp.mailfrom=jlee@suse.com Date: Sun, 8 Apr 2018 15:44:09 +0800 From: joeyli To: Matthew Garrett Cc: alexei.starovoitov@gmail.com, luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Linus Torvalds , Greg Kroah-Hartman , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi Subject: Re: [GIT PULL] Kernel lockdown for secure boot Message-ID: <20180408074409.GD7362@linux-l9pv.suse> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcSW1wb3J0YW50Ig==?= X-GMAIL-THRID: =?utf-8?q?1596848216178927191?= X-GMAIL-MSGID: =?utf-8?q?1597163159921311633?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, Apr 04, 2018 at 04:31:46AM +0000, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov < > alexei.starovoitov@gmail.com> wrote: > > If the only thing that folks are paranoid about is reading > > arbitrary kernel memory with bpf_probe_read() helper > > then preferred patch would be to disable it during verification > > when in lockdown mode. > > No run-time overhead and android folks will be happy > > that lockdown doesn't break their work. > > They converted out-of-tree networking accounting > > module and corresponding user daemon to use bpf: > > https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf > > An alternative would be to only disable kernel reads if the kernel contains > secrets that aren't supposed to be readable by root. If the keyring is > configured such that root can read everything, it seems like less of a > concern? Currently the KMK (kernel master key) can be a trusted key (TPM sealed) or a user key (plaintext). The EVM keeps a key (plaintext) in memory that it is decrypted from a KMK encrypted key. Those kernel reads functions should be disabled when the KMK be loaded to keyring. You idea is good that kernel can keep those reads functions enabled until KMK be loaded. Which means those functions are still available before user enables KMK and EVM. There have another idea is using a tree to register all sensitive data then blanking them when reading. Here is a very early developing version: https://github.com/joeyli/linux-sensitive_data/commits/sensitive-data-tree-v0.1-v4.15 But this approach causes runtime overhead and all sensitive data address must be found and registered (e.g. plaintext in encryption module) Thanks a lot! Joey Lee