From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36C5D198E91 for ; Thu, 5 Jun 2025 14:56:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749135367; cv=none; b=Y3F1QL0Eev6IbYF+OnUAgFVxWXinIenO0UJFnh3OB9f6WdH2JqzaVvgHipHz1mp9GBmDBpRsi7RbvId392am2QYPyLRSGeb1Of3X2ANEQsko7BnNDKXa2ra3qwtbvaxXekEVxX9peDrubuisDDQUiwuXVD+vbgyFpwGJBDyAPjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749135367; c=relaxed/simple; bh=DHu18rmA0sU7oZNUXhtODTBETFCDhL2OEUU38uuVFxI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LwO5QYm0ebHRnmoy52M8lhHdKibI5QURq4yN1mKNuhUTBoLbqr1RlW7PbnNvjV0yThnhffNUZ5k47oQ7sVXjfYcU9xr3q0WhkGzzJ+uRlReMB4N3s5Hybuqbi+I1mcLXoYzhc4ZqZ9q4OBKoGSc2wz7+dYYZxQqiwStszWzkjyE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-192-8YUaOjpKPpOd6_AuvxEAGQ-1; Thu, 05 Jun 2025 10:56:04 -0400 X-MC-Unique: 8YUaOjpKPpOd6_AuvxEAGQ-1 X-Mimecast-MFC-AGG-ID: 8YUaOjpKPpOd6_AuvxEAGQ_1749135363 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-440667e7f92so7921355e9.3 for ; Thu, 05 Jun 2025 07:56:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749135363; x=1749740163; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HFA6j3WG2u6wCRFKF+JPzUGEfqC8djtrecvjhVi86Lo=; b=BKTDiZdTti4MOpQVrQ9EnCo9nr0UFIq6S6+0SGr6A3aS9idBdVxeKh0ia4uDqSgt6d 2p3kMfuMyl91NVPsS7ipqwb1tVLmwt82NZ4W1/A079nG188XzinoE8X5bt+NC1hy40h+ 8hcgkU2Dys3iIJe/MFr/Abpe22AdQAjPhJ+UZi1qx6s4cHp92nYl+IaR63IBBi6GNZZY xa05ZlWkezoHyzM+8aSu4nkJCZUybwYyjNrQ2csBoogqJ4mKeRETBQxEK2hGHue/ZhX5 tX63FMvFZNVP/nBSXteCGla5oc8DmUMtDI7LA1KlA7eWI63dwJ49/Ijlheh3J03MuNbQ bFZw== X-Forwarded-Encrypted: i=1; AJvYcCXcaHLU2taLxn0B3fc9hk7nUcEzJCtniCf1yPHPnfpl6it48muMuHPW4xsoQpAhXSwT56h5FUBwzqs=@vger.kernel.org X-Gm-Message-State: AOJu0Yx794k75++fSl4x7ol0tjrmc2KM/ThRV6uP/HfafirD2jL3EAIs iz/dV6Yv9qH3bd+GoxEb/f7x3ZNvPIqg6uV5D5WRzcKrYaZqTjMeQhcd/qr2rpVT7fLYZb5vVDE //H8gOCYDF732B2122lfodUw3h0+uWPJYdtCKacJ66xxfGll5626XBUUnSJ6eyA== X-Gm-Gg: ASbGncsyR0itYxT4XMmJuBtka2PbbT4LxhSRVMjS3Em+siIP5Hp2Dxknt/mpQcZU1ai biQOkrB70MmzgUv6lgNVTreyfyqTkvweCORLRCOtzpnESyZAnfo4Gn7oaZ8HQLbirp1OPMydoQ+ SgeG/5D8wciuyMnu+SJpFDGHzCnWb77RIbRfX9q26y0aTTBCW/rcDZM8TDWaaKDxFxlfjRA/u61 jznnstQz/KnkHkemE+x1e0nuAl1GgwzoO5WHs+InHT3vSKzvdbgbKnGNaM4v0Imha45218Ff6dU tYTS7PSjQ45iB52pXw== X-Received: by 2002:adf:e38c:0:b0:3a5:2670:e220 with SMTP id ffacd0b85a97d-3a52670e28dmr3061245f8f.32.1749135362783; Thu, 05 Jun 2025 07:56:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHA81c6wZglVzh0Z3/rZiV4JQo/XmLeKsTiTnUWO5wj0USvJJ+iJpt9siQ/hlalGpRgG5o3Zw== X-Received: by 2002:adf:e38c:0:b0:3a5:2670:e220 with SMTP id ffacd0b85a97d-3a52670e28dmr3061215f8f.32.1749135362368; Thu, 05 Jun 2025 07:56:02 -0700 (PDT) Received: from fedora (g3.ign.cz. [91.219.240.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-451f990cfe3sm27314005e9.23.2025.06.05.07.56.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jun 2025 07:56:02 -0700 (PDT) From: Vitaly Kuznetsov To: Eric Snowberg Cc: James Bottomley , "linux-security-module@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-modules@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "keyrings@vger.kernel.org" , David Howells , David Woodhouse , Jonathan Corbet , Luis Chamberlain , Petr Pavlu , Sami Tolvanen , Daniel Gomez , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Paul Moore , James Morris , "Serge E. Hallyn" , Peter Jones , Robert Holmes , Jeremy Cline , Coiby Xu , Gerd Hoffmann Subject: Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification In-Reply-To: <435F53C6-DC08-49CA-AA36-9747FC1B50DF@oracle.com> References: <20250602132535.897944-1-vkuznets@redhat.com> <0FD18D05-6114-4A25-BD77-C32C1D706CC3@oracle.com> <87zfemoc76.fsf@redhat.com> <435F53C6-DC08-49CA-AA36-9747FC1B50DF@oracle.com> Date: Thu, 05 Jun 2025 16:56:00 +0200 Message-ID: <87qzzynsov.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Snowberg writes: >> On Jun 5, 2025, at 1:54=E2=80=AFAM, Vitaly Kuznetsov wrote: >>=20 >> 'certwrapper' offers _a_ solution which is great. It may, however, not >> be very convenient to use when a user wants to re-use the same OS image >> (e.g. provided by the distro vendor) for various different use-cases as >> proper 'certwrapper' binary needs to be placed on the ESP (and thus >> we'll end up with a bunch of images instead of one). 'db' is different >> because it normally lives outside of the OS disk so it is possible to >> register the exact same OS image with different properties (e.g. with >> and without a custom cert which allows to load third party modules). > > Could you please provide more details? The kernel module is signed with=20 > a specific key. The =E2=80=98db=E2=80=99 key in the cloud image must mat= ch whatever key=20 > was used to sign the kernel module. > > Why can=E2=80=99t the RPM package that contains the kernel module also in= clude=20 > the required =E2=80=98certwrapper=E2=80=99? When the RPM is installed, t= he appropriate=20 > =E2=80=98certwrapper=E2=80=99 is placed on the ESP. There can be any num= ber of 'certwrappers'=20 > in the ESP. Doesn=E2=80=99t this solution address the issue? I think it does but let me elaborate on where I believe some (minor?) inconvenience comes from. We have various actors here: 1) The OS image which is coming from a distro vendor. 2) The user, which takes the OS image and registers it with specific properties (including 'db') with various infrastructures (e.g. different clouds). 3) A third party kmod vendor which produces a module compatible with the OS version. The module may only make sense for certain VMs on certain clouds. The customization of the VM normally happens upon first boot: a generic image from the OS vendor (1) boots and then some provisioning agent (cloud-init, WALA,...) takes over and e.g. installs additional stuff. This additional stuff may include third party kmods from (3). The 'certwrapper' must carry the key which the third party vendor (3) uses and it must be signed by a key which the user (2) put to the 'db'. If we want to have the 'certwrapper' shipped inside the same RPM as the kernel module, it will be signed by the same third party vendor (3). While this looks a bit weird ('self-signed certwrapper'), I don't see why this can't work.=20 Besides the need to teach (3) how to build certwrappers, an inconvenience in this scheme comes from the fact that to activate a 'certwrapper' which we install from a custom rpm, we need a reboot. Cloud instances often back burstable workloads and this can be seen as annoyance. --=20 Vitaly