From patchwork Tue May 10 09:36:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ivan Hu X-Patchwork-Id: 1629039 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=PNmnEAem; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KyCbk64KQz9sFw for ; Tue, 10 May 2022 19:36:33 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1noMI5-0004oi-Ts; Tue, 10 May 2022 09:36:25 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1noMI4-0004oH-Bm for kernel-team@lists.ubuntu.com; Tue, 10 May 2022 09:36:24 +0000 Received: from canonical.com (118-163-61-247.hinet-ip.hinet.net [118.163.61.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id D25A63FF92 for ; Tue, 10 May 2022 09:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1652175383; bh=7a9vHa4N8OvD35JVBCMCqRgxgong2vcdemgq6iRqSk8=; h=From:To:Subject:Date:Message-Id; b=PNmnEAem65pac/dtDJQNCYfQrd9xKZw8xEtqaftP+ERhyysTVo1K5Xqiq5a0ONpCg GLfeSGIt77bqGXw8n36Y2XEAkQZmwtCA8OvUi+Ejj5IV3yGTU8vnwcQ+t2I5g21Zzp 8zkzty40hFI+gFlpE5P0SslHUH8yEJrQaOiqazucz1YDlbeGOwqqw4kuut9EM1Z6To r+0+y7PdduEpze5hDcWl4YTp1SRPyceb6lxHOw1nqPAj+b26ViIzlK8wx8WrvRAyRe i6czwWDThdapRE6Faxzc9jqmQ2G7Ci2cAPG886TBt5mv0aiiWD228BmUVmjI6q/nB2 HNSgXWmsg8LWg== From: Ivan Hu To: kernel-team@lists.ubuntu.com Subject: [SRU][OEM-5.17][PATCH 0/1] enable Mok key support for v5.17 Date: Tue, 10 May 2022 17:36:18 +0800 Message-Id: <20220510093619.17147-1-ivan.hu@canonical.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" BugLink: https://bugs.launchpad.net/bugs/1972802 [Impact] Mok keys is not trusted after kernel 5.17 [Fix] Enable the CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT and CONFIG_IMA_ARCH_POLICY for fixing the patch "[patch] integrity: Do not load MOK and MOKx when secure boot be disabled" was added to check if secureboot enabled for trusting the MOK key. [Test] Enroll Mok key and use it to sign kernel modules, make sure secure boot is on and load the kernel module by either modprobe or insmod. [Where problems could occur] Low. only affect the checking secureboot enable function. Ivan Hu (1): UBUNTU: [Config] enable configs for fixing 5.17 kernel won't load mok debian.oem/config/config.common.ubuntu | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)