Received: by 10.213.65.68 with SMTP id h4csp744439imn; Wed, 4 Apr 2018 06:36:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx4++nWy0ammUPV+PsA/r5YADoPtcza9ZivpDWGdHnTWKXxcUQkeSr8wMDnAKzRyWAobmhQMb X-Received: by 10.99.106.67 with SMTP id f64mr7445703pgc.218.1522848976756; Wed, 04 Apr 2018 06:36:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522848976; cv=none; d=google.com; s=arc-20160816; b=NhShGWVTIedFH/30EQcSQY0ARKghpgkCb3zR2mZVuO+nNELCkesr77SzzXxqpQeo/C xO9sw4SyOlmPC/ZpUAIDr44dswZTaAdWt9LXTUeHkWSKTVinNSlaAk+ldJeJS0wsO7Ru 9iZD4rFuHfB7wCX3a7FXgfoS6TVRHRCOcqbMTvqIvD2vodOjtkbym0OHDgOTnmu1wxcq XJHh8zzEGjRCk5DPgCBQS5Yjx+ptOxul6EPnP+5uqBPWREcb3lNQDwtEmniwdj09ME2L nPhsxxG50m0JaSkGpDrEKfF4KoczoR2vO9JQOvnMLso4I6KqCXABAbHcgXDaAnS4eMX5 oQjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=+G3vDT7aRTfvLgrf8OLYuXziACTlVNLwwigqmu4xbgQ=; b=pOsaaPJmlurnOE1+FVaOilJ0dFH33NsmfJ8jAIxv4Ptb9UQ3qNCchSwlzS3j4loLbx 9v+OQpJSusHLVu4NygAz+K6Zc7gfJphSULJG3WADpVQM6wDpuD2PT0LG9t6R77MDuwY7 EhUoz8oppjMfthxw1XGNpI/J+uxl3UXd7Hlf0dECn9nGpMvFfXyqFGuR2LSbbs5QSwR4 4MkSv18K74CzB851AsZE/ZJxR1WL4j5ODKtTOkv0GHRzRQ1MqJ3SAdYUMd/7/+Nz5QVx S3COGAmGABFRlTWSTc0vSnTHDPNtHpGCLYUMNGd30fo/vfK3js4caVmcyak5kMgrl4ka 6zbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=l1ETzRQT; 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 s15-v6si3529075plj.701.2018.04.04.06.36.02; Wed, 04 Apr 2018 06:36:16 -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=fail header.i=@thunk.org header.s=ef5046eb header.b=l1ETzRQT; 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 S1751404AbeDDNeU (ORCPT + 99 others); Wed, 4 Apr 2018 09:34:20 -0400 Received: from imap.thunk.org ([74.207.234.97]:60442 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbeDDNeS (ORCPT ); Wed, 4 Apr 2018 09:34:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+G3vDT7aRTfvLgrf8OLYuXziACTlVNLwwigqmu4xbgQ=; b=l1ETzRQTsATyKLC40O4ujZcxaM 2qua59Dho0n1IC56B3U7/lJQPuCWB8XnuL0bFvK9YzTHs+R0o4n1wXsS0BG4NLV0SmeLkPO1Da6Hs cq5uOatgaxQVamBXFUjj++3xE7B4jF4dR9HCh+yts3zjrgd1uq8P3EXV7lHR54JnGb18=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1f3iYG-0003Fy-9V; Wed, 04 Apr 2018 13:34:12 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8FDAD7A2DEC; Wed, 4 Apr 2018 09:34:11 -0400 (EDT) Date: Wed, 4 Apr 2018 09:34:11 -0400 From: "Theodore Y. Ts'o" To: Greg Kroah-Hartman Cc: Matthew Garrett , Linus Torvalds , luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi Subject: Re: [GIT PULL] Kernel lockdown for secure boot Message-ID: <20180404133411.GC16242@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Greg Kroah-Hartman , Matthew Garrett , Linus Torvalds , luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi References: <20180404125743.GB16242@thunk.org> <20180404130233.GA24008@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404130233.GA24008@kroah.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > > What I'm afraid of is this turning into a "security" feature that ends up > > > being circumvented in most scenarios where it's currently deployed - eg, > > > module signatures are mostly worthless in the non-lockdown case because you > > > can just grab the sig_enforce symbol address and then kexec a preamble that > > > flips it back to N regardless of the kernel config. > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > isn't this a problem for people who are fearful that Linux could be > > used as part of a Windows boot virus in a Secure UEFI context? > > Because no one is afraid of that :) Well, this is the excuse used by Windows. Some more cynical people believe it's really an anti-competitvie thing, but we should acknowledge this is what is causing the fear that some distros have that their UEFI secure boot certs will be revoked by Microsoft if they don't have this crazy lockdown enforcement for UEFI Secure Boot. So how about this as a compromise. We can have a config option for the behavior that those distros (and Matthew) want, and we can have separate config options that turn things on in what others would say is a more rational way. And I would all be for having the Kconfig description says, "This config option is only needed by distros who are fearful of Microsoft revoking their UEFI secure boot certificate." - Ted