Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp38635imm; Mon, 14 May 2018 20:29:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrJRciijX1hKoyb7H7y/nkDzQr+1E82cJrE9N8UA+aaclAMr9OtA5OITOT8jaECnUCBBB3b X-Received: by 2002:a17:902:7582:: with SMTP id j2-v6mr12515226pll.65.1526354944565; Mon, 14 May 2018 20:29:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526354944; cv=none; d=google.com; s=arc-20160816; b=B2LBhf7ymz8GPBHFx2O9BphyQPY1g3Hr5rRDg/9zEPZ6CkQA6CRWIfXoRSzxFOvrw7 VIAL2lvGgXbiUEHNhbz0QkAdCeb6+N86PjERCmNTGGfJ18Kj3Um9vIVvi55vyIh4pCSu 1bPWdRxXwm7DijtfMngUABXv2E7+l+ctKkhwv2zNGxvKEBJtPegqmfhtT3jh+K8OC34W otlU82+eFKx0DEtKk69OJYc9qmiiZsgSzMBrikKZorbDG6gQQa9Sjx6sNKsgKOv/NP9D QuGvrAwJ2rl182em+OLa0H26nbshHamkWwjdNPGUbgjrsIuHqqjPZWZR2KEVPdMO27zJ f6qg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=yj2KK8XXvY4Lcu+vbgA5M8fTDTJnFCUUlTW3oF/8olU=; b=exyNmBYaVzw/XR9MdTmj9RsBfhrh76U+vzcazPUjwHwPa/WT+8ZfUCDkOWa+HoNZEY F4vHKIG3YTWOIzT942IAZmPwIicnvnnkqvr8KWnHJ7pYMs+dRhZ0rhX/H4oRlYSHfgNX lwHoNJMXMho4zlpLdsMwFVYKGVEQb3PHeRDMSy2oGmEc6jUQ+JqHODbCg7+ykLkvyMQn HaMS1hSYBfI6Ev3O8xCAh08qoV2iUW/j5gjXyp5+e7WTWzQ8dvqipJsZsE2kWHGJLwN+ ZDfJ81Ic1iPeC/O0Ld2ca71zOQfT6Ug7K0cPF/pM7G4UJ5+FEXV/miqtZas7M2BE5tZD EPSg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9-v6si11117857pfg.247.2018.05.14.20.28.26; Mon, 14 May 2018 20:29:04 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752226AbeEOD1D (ORCPT + 99 others); Mon, 14 May 2018 23:27:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:54674 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009AbeEOD1A (ORCPT ); Mon, 14 May 2018 23:27:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 556EAAE24; Tue, 15 May 2018 03:26:58 +0000 (UTC) Date: Tue, 15 May 2018 03:26:56 +0000 From: "Luis R. Rodriguez" To: Mimi Zohar , Josh Boyer Cc: "Luis R. Rodriguez" , Harald Hoyer , Hannes Reinecke , Johannes Thumshirn , "Eric W. Biederman" , Casey Schaufler , Alexei Starovoitov , David Miller , Jessica Yu , Al Viro , One Thousand Gnomes , Matthew Garrett , Peter Jones , "AKASHI, Takahiro" , David Howells , linux-wireless , Kalle Valo , Seth Forshee , Johannes Berg , linux-integrity@vger.kernel.org, Hans de Goede , Ard Biesheuvel , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , Greg Kroah-Hartman , Andres Rodriguez , Linus Torvalds , Andy Lutomirski Subject: Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware Message-ID: <20180515032656.GR27853@wotan.suse.de> References: <20180509212212.GX27853@wotan.suse.de> <1525903617.3551.281.camel@linux.vnet.ibm.com> <20180509234814.GY27853@wotan.suse.de> <1525917658.3551.322.camel@linux.vnet.ibm.com> <20180510232639.GF27853@wotan.suse.de> <1526014826.3414.46.camel@linux.vnet.ibm.com> <20180511215250.GJ27853@wotan.suse.de> <1526302692.3898.145.camel@linux.vnet.ibm.com> <20180514192853.GM27853@wotan.suse.de> <1526349751.3937.78.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1526349751.3937.78.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 10:02:31PM -0400, Mimi Zohar wrote: > On Mon, 2018-05-14 at 19:28 +0000, Luis R. Rodriguez wrote: > > > - CONFIG_IMA_APPRAISE is not fine enough grained. > > > > > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. ?Similar > > > Kconfig options will require kernel modules, kexec'ed image, and the > > > IMA policy to be signed. > > > > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be > > doing firmware verification in userspace or in the kernel. > > The kernel is verifying signatures. > > > > There are a number of reasons that the kernel should be verifying > > > firmware signatures (eg. requiring a specific version of the firmware, > > > that was locally signed). > > > > Oh I agree, Linux enterprise distributions also have a strong reason to > > have this, so that for instance we only trust and run vendor-approved > > signed firmware. Otherwise the driver should reject the firmware. Every > > now and then enterprise distros may run into cases were certain customers > > may run oddball firmwares, and its unclear if we expect proper functionality > > with that firmware. Having some form of firmware signing would help with > > this pipeline, but this is currently dealt with at the packaging, and > > noting other than logs ensures the driver is using an intended firmware. > > But these needs *IMHO* have not been enough to push to generalize a kernel > > firmware signing facility. > > In order for IMA-appraisal to verify firmware signatures, the > signatures need to be distributed with the firmware. ?Perhaps this > will be enough of an incentive for distros to start including firmware > signatures in the packages. Best to poke the maintainers about that... We have been sending mixed messages about firmware signing over years now. Josh, heads up the new one is we can do firmware signing through IMA future CONFIG_IMA_APPRAISE_FIRMWARE. I'll bounce you a few emails related to this. > > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow > > I'm happy to hear it. > > The functionality has been there since commit 5a9196d ("ima: add > support for measuring and appraising firmware"). ?The > security_kernel_fw_from_file() hook was later replaced with the > generic security_kernel_read_file() hook. Groovy, its unclear from the code on that commit how this is done, so I suppose I need to study this a bit more. Josh, do you grok it? Luis