Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp3299340pxb; Mon, 18 Apr 2022 22:16:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHBBgVVb3xg1m+wGOzE0aHTwZt5lTI8w5tnRWq1FX0I/r3zf20IVIu/WBPWHTij27PpbMf X-Received: by 2002:a05:6402:40c6:b0:424:13e:a9ff with SMTP id z6-20020a05640240c600b00424013ea9ffmr1054806edb.7.1650345397872; Mon, 18 Apr 2022 22:16:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650345397; cv=none; d=google.com; s=arc-20160816; b=kZuLt1GCGITR904i7qnFUW+ip9d+y6KD9KTwILWR7mZkjIRUPHvJ1V1DgR1u/hq/mb j/30CWSgVCH0rpCiK6Fv2vUAxbyiooqE9clHEDqUqgxTYWds9+wf4hU1+mA6UFWy6/Dh aNlZ48mXmLXEPbftaUFQHdkS1O1FKLrAxRc46k8NRZzzfs9OSQZkxhdZUZf4ld7B0Ln6 eH9pj/Wf2whP8ztA4XgLS2FTOTTfuR9HchebGgRikxmYU7jQuOQq6GjX3VgBRcb87B1U PgCVZz8CRAg/iIJn5XcikdiIUfD/0jaPRcZIloPmYtVDuYxWtdw7fPuJVqBNpXDR8qzu s8sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=MWGw+I8Rgl/opd43ebHHMAj95ulAD46oHN9fU4DvNpo=; b=b36MRn2QOwjvW4vnYxsrRrzVsz8RZ7Cc5cZ23E4ll1kmbKDQK9S9K7ITGKRNNjQU8P S/bz+bDpNFnnPG5K5syYOUIDviBn+MUGO6luQA45rVI3IaDFZRDkE/Yfz0bALNb/hwVy mJyF8USymFWD3gSLUhH3dCkF9+jou2WO8c0RSWD06IUEouLG66jorCDSISydggA1sbXD zrGA40Ob/3E+LkMBR0qPwLG2cNo3HOxp8QqywsFf8INpQdp9JjqGUWmn5DbZ9IThCRG7 NYrVDU0GMnOjFr4ZiCHgvb+uraSpHhKpYoyvOBL+K3h7WpgIXmLu4UoptG2qXVhMT80r DKCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RJB5VJlf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j26-20020a170906279a00b006e840554fdfsi7142576ejc.947.2022.04.18.22.16.12; Mon, 18 Apr 2022 22:16:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RJB5VJlf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232278AbiDRWqP (ORCPT + 99 others); Mon, 18 Apr 2022 18:46:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232199AbiDRWqK (ORCPT ); Mon, 18 Apr 2022 18:46:10 -0400 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C80072AC78 for ; Mon, 18 Apr 2022 15:43:29 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id j71so7941627pge.11 for ; Mon, 18 Apr 2022 15:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MWGw+I8Rgl/opd43ebHHMAj95ulAD46oHN9fU4DvNpo=; b=RJB5VJlfpWuoUefGZyScMaomY4DRb6B11jXnHXlNxpMYTpsSmgHEIex9Xu8XXZRhMQ KocBLzvItOgf2xNj9jTpA7/rQGDXuV0EG8bmfCAGh7Oy/K3ULN6eF6t+GDCYkML5TWax Ql+z6+pHnoM0e70w8R488SFOiSeaO77l0jXhI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MWGw+I8Rgl/opd43ebHHMAj95ulAD46oHN9fU4DvNpo=; b=ML93bT1qqNQZipDMoAcJ3CoTW6zOCbrWWCTL9x4pGsOl8LPCcWGY2B3fcpl11RLmfd S5GIgqee96YZwc9736qMu1/K4pqUOu8iRzVUhfo574M5bCTKgqwmoDkvBi1K93f4qf3r Wtc3h7z9QVz2Jue0D58NcHAXv+NTicUrPts5LiITNnNWbTHdiy0xj+nRgdqovlJr1ECo MgltzEd3FkAvWF9ibYzQfV2xZbOGLUmZwVt8MKlFrqKAxg2IuPOWTOxKB1rQ/2wCnjx8 O//8z7t72IpxLPcqblEfrmkEp7/xg25yw9rMg81wxZMVXr0fg0u6VZmW883wLcbIOHMI piKg== X-Gm-Message-State: AOAM5308hkHF1cUlZFy0I50qRnckfo+r90fYJLf3pH6CgM7VFTgD5C8d 9qwSDDfb+GaH2/qjP9kCS/Hkuw== X-Received: by 2002:a63:5013:0:b0:399:5816:fd0d with SMTP id e19-20020a635013000000b003995816fd0dmr11795301pgb.68.1650321809394; Mon, 18 Apr 2022 15:43:29 -0700 (PDT) Received: from localhost ([2620:15c:202:201:6b32:a0a5:ec32:c287]) by smtp.gmail.com with UTF8SMTPSA id e13-20020a63370d000000b003810782e0cdsm14078821pga.56.2022.04.18.15.43.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Apr 2022 15:43:28 -0700 (PDT) Date: Mon, 18 Apr 2022 15:43:27 -0700 From: Matthias Kaehlcke To: Kees Cook Cc: Alasdair Kergon , Mike Snitzer , James Morris , "Serge E . Hallyn" , linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, Song Liu , linux-security-module@vger.kernel.org, Douglas Anderson , dm-devel@redhat.com Subject: Re: [PATCH 0/3] LoadPin: Enable loading from trusted dm-verity devices Message-ID: References: <20220418211559.3832724-1-mka@chromium.org> <202204181512.DA0C0C6EBD@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202204181512.DA0C0C6EBD@keescook> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kees, On Mon, Apr 18, 2022 at 03:14:14PM -0700, Kees Cook wrote: > [oops, resending to actual CC list] > > On Mon, Apr 18, 2022 at 02:15:56PM -0700, Matthias Kaehlcke wrote: > > This series extends LoadPin to allow loading of kernel files > > from trusted dm-verity devices. It adds the concept of > > trusted verity devices to LoadPin. Userspace can use the > > new systl file 'loadpin/trusted_verity_root_digests' to > > provide LoadPin with a list of root digests from dm-verity > > devices that LoadPin should consider as trusted. When a > > kernel file is read LoadPin first checks (as usual) whether > > the file is located on the pinned root, if so the file can > > be loaded. Otherwise, if the verity extension is enabled, > > LoadPin determines whether the file is located on a verity > > backed device and whether the root digest of that device > > is in the list of trusted digests. The file can be loaded > > if the verity device has a trusted root digest. > > > > The list of trusted root digests can only be written once > > (typically at boot time), to limit the possiblity of > > attackers setting up rogue verity devices and marking them > > as trusted. > Thanks for working all this out! Where does the list of trusted > roothashes come from? I assume some chain of trust exists. Is the list > maybe already stored on the rootfs? Yes, at least the content of the list comes from the rootfs. The userspace part is still TBD (also pending on the evolution of this patchset), having the list pre-formatted in a single file on the rootfs should be fine. > It'd be nice if there was some way to pass the trust chain to LoadPin > more directly. I imagine you envision LoadPin reading the file itself, instead of just processing the content. That should be doable. One option would be to pass the path of the file with the hashes through the sysctl file and use kernel_read_file_from_path() to read it if the path is in the pinned root (or maybe even in any trusted file system ;-)