From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11B10C2BA83 for ; Wed, 12 Feb 2020 16:01:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DA63520873 for ; Wed, 12 Feb 2020 16:01:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="e5py13qa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727054AbgBLQBZ (ORCPT ); Wed, 12 Feb 2020 11:01:25 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:38766 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727007AbgBLQBZ (ORCPT ); Wed, 12 Feb 2020 11:01:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581523284; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HnKDCKwyuda4gW5Ivrg+jIsW4pfOis6x+0ZhUg+C7PU=; b=e5py13qafc6hLEQYCtMztywYXdF2jHL6DqC4nCKggYOEhzDn4/J8Bz9fAiEHhNNMvLEfJo Jmdx/xIby1zLzH8T37st5k5NqQQESrYmBXbZ5qj+37trIGD2UepRP04cvHCPa8WThyh1JP cZUJ0TEydrIdTbWxHqb0xhF/E1fBkB4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-208-c5nkZBysMaus_cy780aHZQ-1; Wed, 12 Feb 2020 11:01:20 -0500 X-MC-Unique: c5nkZBysMaus_cy780aHZQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2F23CDBA3; Wed, 12 Feb 2020 16:01:19 +0000 (UTC) Received: from redhat.com (dhcp-10-20-1-15.bss.redhat.com [10.20.1.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C8E195C1B0; Wed, 12 Feb 2020 16:01:17 +0000 (UTC) Date: Wed, 12 Feb 2020 11:01:16 -0500 From: Peter Jones To: Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, lersek@redhat.com, leif@nuviainc.com, mjg59@google.com, agraf@csgraf.de, ilias.apalodimas@linaro.org, xypron.glpk@gmx.de, daniel.kiper@oracle.com Subject: Re: [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Message-ID: <20200212160116.3xypcgmtafj7fm47@redhat.com> References: <20200206140352.6300-1-ardb@kernel.org> <20200206140352.6300-3-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200206140352.6300-3-ardb@kernel.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, Feb 06, 2020 at 02:03:52PM +0000, Ard Biesheuvel wrote: > One of the advantages of using what basically amounts to a callback > interface into the bootloader for loading the initrd is that it provides > a natural place for the bootloader or firmware to measure the initrd > contents while they are being passed to the kernel. > > Unfortunately, this is not a guarantee that the initrd will in fact be > loaded and its /init invoked by the kernel, since the command line may > contain the 'noinitrd' option, in which case the initrd is ignored, but > this will not be reflected in the PCR that covers the initrd measurement. > > This could be addressed by measuring the command line as well, and > including that PCR in the attestation policy, but this locks down the > command line completely, which may be too restrictive. In practice I think we need to be measuring the command line anyway. In current existing deployments, we measure kernel and initramfs into PCR9, and measure the kernel command line into PCR8 (both are reserved in the TIS for OS use). This allows users farther down the stack to choose whether which things they seal against, based on their requirements. > So let's take the noinitrd argument into account in the stub, too. This > forces the PCR that covers the initrd to assume a different value when > noinitrd is passed, allowing an attestation policy to disregard the > command line if there is no need to take its measurement into account > for other reasons. I think we also need to log a capping EV_SEPARATOR event with an log entry that says it's for noinitrd into PCR9, in order to prevent any scenarios where an attacker prevents the normal initramfs from loading, and then replays the events from a prior log in order to unseal secrets. -- Peter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 060C9C352A4 for ; Wed, 12 Feb 2020 16:03:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CD73220873 for ; Wed, 12 Feb 2020 16:03:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eUwYrYXI"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SpwPPKoc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD73220873 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U6pH+UJT0DYz18OZVF+FNFs6JgMllB/VDhCsAYjYqAM=; b=eUwYrYXIS+gd0B yJDUx087hV6oMatcDSnCCn3y2ZRd/ZugFh4gsI5sGIFukdCIHvNsJHglwUH5N8F9mJtqPwN4nGlyS PkxrM5yRRK9c/kRr4tecVfdGa3OULr03ObPRpWVWQKS4M0ZVELN2g9TGBtfgrn5j9YeS2K/YhBG05 qxGNijriwYuhyfdjqq1YULj9J39CZSWYCHa9Lphy2GxxSH7qTqJW6FQg1PydK771HPZ/h6q8jroKZ Ii61ycALbdGTC+mXjxcLkGqxAr5mJTO6Pw0j0I9gWr+FikbAelonCd6rNR5nNZozaMbPzmZ7Dp/Ev mE9MqUStbAia/9uyIcGw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j1uU6-00064c-5r; Wed, 12 Feb 2020 16:03:30 +0000 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120] helo=us-smtp-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j1uU0-00063j-VE for linux-arm-kernel@lists.infradead.org; Wed, 12 Feb 2020 16:03:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581523400; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HnKDCKwyuda4gW5Ivrg+jIsW4pfOis6x+0ZhUg+C7PU=; b=SpwPPKocXy3IaMyQ9w2Zgy24qOnJ4z8LnalslVUF9ZCyHtvsSLCrItX3kDjSEg+J9OEpYt zStAFZxvoGZ8uOnV3T+gzXPPAya7FUJ6Chs7IFXKkSOOpxmwn+mscgm/owfYJKKmuM21u/ N2mU78u4QZHqWMfuR/JEgIZfvRhktgs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-208-c5nkZBysMaus_cy780aHZQ-1; Wed, 12 Feb 2020 11:01:20 -0500 X-MC-Unique: c5nkZBysMaus_cy780aHZQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2F23CDBA3; Wed, 12 Feb 2020 16:01:19 +0000 (UTC) Received: from redhat.com (dhcp-10-20-1-15.bss.redhat.com [10.20.1.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C8E195C1B0; Wed, 12 Feb 2020 16:01:17 +0000 (UTC) Date: Wed, 12 Feb 2020 11:01:16 -0500 From: Peter Jones To: Ard Biesheuvel Subject: Re: [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Message-ID: <20200212160116.3xypcgmtafj7fm47@redhat.com> References: <20200206140352.6300-1-ardb@kernel.org> <20200206140352.6300-3-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200206140352.6300-3-ardb@kernel.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200212_080325_520407_A2740AC6 X-CRM114-Status: GOOD ( 19.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-efi@vger.kernel.org, xypron.glpk@gmx.de, daniel.kiper@oracle.com, ilias.apalodimas@linaro.org, mjg59@google.com, agraf@csgraf.de, leif@nuviainc.com, lersek@redhat.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 06, 2020 at 02:03:52PM +0000, Ard Biesheuvel wrote: > One of the advantages of using what basically amounts to a callback > interface into the bootloader for loading the initrd is that it provides > a natural place for the bootloader or firmware to measure the initrd > contents while they are being passed to the kernel. > > Unfortunately, this is not a guarantee that the initrd will in fact be > loaded and its /init invoked by the kernel, since the command line may > contain the 'noinitrd' option, in which case the initrd is ignored, but > this will not be reflected in the PCR that covers the initrd measurement. > > This could be addressed by measuring the command line as well, and > including that PCR in the attestation policy, but this locks down the > command line completely, which may be too restrictive. In practice I think we need to be measuring the command line anyway. In current existing deployments, we measure kernel and initramfs into PCR9, and measure the kernel command line into PCR8 (both are reserved in the TIS for OS use). This allows users farther down the stack to choose whether which things they seal against, based on their requirements. > So let's take the noinitrd argument into account in the stub, too. This > forces the PCR that covers the initrd to assume a different value when > noinitrd is passed, allowing an attestation policy to disregard the > command line if there is no need to take its measurement into account > for other reasons. I think we also need to log a capping EV_SEPARATOR event with an log entry that says it's for noinitrd into PCR9, in order to prevent any scenarios where an attacker prevents the normal initramfs from loading, and then replays the events from a prior log in order to unseal secrets. -- Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel