Received: by 10.192.165.148 with SMTP id m20csp163856imm; Thu, 3 May 2018 17:12:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr7e2QCLBVDC/lmcM2LZvjRvZSmry1rVuwK5GEfjfQEJPFGUSq2IZEZBHRfSujmVrsBh/Cn X-Received: by 2002:a17:902:6686:: with SMTP id e6-v6mr25788290plk.35.1525392724728; Thu, 03 May 2018 17:12:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525392724; cv=none; d=google.com; s=arc-20160816; b=bK5n7SgTZbkrVhLZvC3/zyZ4Kjr8/V5Ag5vowDK9oz+tj07XD9ZxKdq0NqNwZE+xPO /bPKbz6LBEfPx5ne8DSi2gI068J3YPnDIDvzhWq3fkpPFvCfw38FiEekQzWPf/vRfZFr cdDhlovPjqQBLeEn4MRvT6Ubz/kQZBGG+bLLMc1qEdjbTKgkmswDRYbfQr12zFvbButC 3Y/ZSjZLAaG6GqZ/SpSJVuJgz+dd3ZXGxXLvNtiT0Db5/71RtNKsSts3WgEWMaP+jcJj gakJN5H8xGN6oT83jijusrKUbfwU85jmCCwcjCGcQpFEI4HruEaWvV6zvUPuqPNszYJ3 j8CA== 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:message-id:subject:cc :to:from:date:arc-authentication-results; bh=sdpurVk8vRre6BIeOY5EeYFCz1dIH1qwUXdRJMN0VEs=; b=gUdp65aiy20O3GlpUoxQQ5FDhwmqwAhg3xB9+1SXU1fNsJ44KtcB5lXryD6u0AKtyg lS4Eo+E5fC32clRIr+LBuO+1QZp7bnLEndiFPiIr/pHHZtlyNSj4Da9yrcsO5m1tnGn8 hSqd554Y8Q+vf8YhhvV5Cx/NAc1rnoJH/cKeow3M4MVMoCi1PzbfRqNf5dlBsOx7h+x/ y4GtOSOEdSD7TgVOlYBG2sSknfliB5aFY/2hUXXXA5TplEMFRDVJUnPjQpA1p+gMOeOK RBzI39xsrEQPxLy7fPtyC4+8ffy3ovkosh8e7k7XyPA+fFxhCA/EmOxdqKwjW9fuaH/K qzjQ== 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 q124-v6si12256445pgq.215.2018.05.03.17.11.50; Thu, 03 May 2018 17:12: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 S1751479AbeEDAKW (ORCPT + 99 others); Thu, 3 May 2018 20:10:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:33502 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbeEDAKU (ORCPT ); Thu, 3 May 2018 20:10:20 -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 1041AAFB3; Fri, 4 May 2018 00:10:19 +0000 (UTC) Date: Fri, 4 May 2018 00:10:18 +0000 From: "Luis R. Rodriguez" To: Mimi Zohar Cc: linux-integrity@vger.kernel.org, Hans de Goede , Ard Biesheuvel , Peter Jones , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , Kees Cook , "Serge E . Hallyn" , Stephen Boyd Subject: Re: [RFC PATCH 6/6] ima: prevent loading firmware into a pre-allocated buffer Message-ID: <20180504001018.GS27853@wotan.suse.de> References: <1525182503-13849-1-git-send-email-zohar@linux.vnet.ibm.com> <1525182503-13849-7-git-send-email-zohar@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525182503-13849-7-git-send-email-zohar@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 Tue, May 01, 2018 at 09:48:23AM -0400, Mimi Zohar wrote: > Question: can the device access the pre-allocated buffer at any time? > > By allowing devices to request firmware be loaded directly into a > pre-allocated buffer, will this allow the device access to the firmware > before the kernel has verified the firmware signature? > > Is it dependent on the type of buffer allocated (eg. DMA)? For example, > qcom_mdt_load() -> qcom_scm_pas_init_image() -> dma_alloc_coherent(). > > With an IMA policy requiring signed firmware, this patch would prevent > loading firmware into a pre-allocated buffer. Android folks went silent on the other thread .. Best poke them there? Luis > > Signed-off-by: Mimi Zohar > Cc: Luis R. Rodriguez > Cc: David Howells > Cc: Kees Cook > Cc: Serge E. Hallyn > Cc: Stephen Boyd > --- > security/integrity/ima/ima_main.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c > index eb9c273ab81d..3098131f77c4 100644 > --- a/security/integrity/ima/ima_main.c > +++ b/security/integrity/ima/ima_main.c > @@ -454,6 +454,15 @@ int ima_read_file(struct file *file, enum kernel_read_file_id read_id) > return 0; > } > > + if (read_id == READING_FIRMWARE_PREALLOC_BUFFER) { > + if ((ima_appraise & IMA_APPRAISE_FIRMWARE) && > + (ima_appraise & IMA_APPRAISE_ENFORCE)) { > + pr_err("Prevent device from accessing firmware prior to verifying the firmware signature.\n"); > + return -EACCES; > + } > + return 0; > + } > + > if (read_id == READING_FIRMWARE_FALLBACK) { > if ((ima_appraise & IMA_APPRAISE_FIRMWARE) && > (ima_appraise & IMA_APPRAISE_ENFORCE)) { > -- > 2.7.5 > > -- Do not panic