From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p8Mh9-0003xp-8a for mharc-grub-devel@gnu.org; Thu, 22 Dec 2022 09:37:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8Mh3-0003tX-Va for grub-devel@gnu.org; Thu, 22 Dec 2022 09:37:13 -0500 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p8Mh1-0008Jv-5b for grub-devel@gnu.org; Thu, 22 Dec 2022 09:37:09 -0500 Received: by mail-pf1-x42e.google.com with SMTP id n3so1341694pfq.10 for ; Thu, 22 Dec 2022 06:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:cc:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/GiQa0Ia/JEggBwYX2tF6b8QLMtEHsVOTunMd8EN/s4=; b=dJYnElXKc4kDD9FDQNvZgwsyTje1VqctcV7foS5tN/UrKAKprqvNo3uakE7eAmr+LT VXzHBg6fOstQW7VyB6Z+AxHykCVwOFaP0YvWFuSSBtlDjPrdFicu/ELdyTaa40NJKP8H 7xGdQNZeB7N8jiZSMK4gxrR6FAtdhA++Z2mXicUU6R4XFHbqqVV2tgqLsfD/OWTmkK9V RN8d3+cLAbcEU83OsOm5B/9XbU7Rh2PlplVqtA1ShIZA924PCQGdC9YNyBttvLMcA70M QjfTNt72Lp0bLrYHZx5QuJNp4e3ACyYvRVwq/SBkSuiXZyu8j8/rfcsXtKACk/u7RjzN K0eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:cc:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/GiQa0Ia/JEggBwYX2tF6b8QLMtEHsVOTunMd8EN/s4=; b=NH6uYBGc9O/27G7pTJbXSUq03LDXDhVJXzBSkLmlVNbFXJgsz36f8qI/M5fDxqJ/K8 vQ+4YhFC3HwWFw3iJLmBLIjDwHbS2bOCix9BdpZ9WwR3zmdJ4KbR4gUTd2TkGGxILIXz tLmwgfS0sGjtAXE/IrE3vj2HiwtXXZ2yvB6qwhaAXbsZ5VTGxgFnjzuiWgS5a+GqXJAy zdI/iEi/jIGqeuFDNywtH3l/gJxL9j5QXMKCrLaNJKH8+N+UndyDYi+3xEIziCAEdAdo 7tB8cPDf28gH9Iokfq1qJcPTBDbjLDNe5cpQ84Pr2yUJhh+ybhsSGwbWZ8CA6ZFWzQQf nN3g== X-Gm-Message-State: AFqh2kqqLMWsW3OzNjDlodYIuL/N3aDboAZM615AV6+bWZN6v7fRgrO/ 7O8WXLq9JvW5F8+p3bGoaFYrY1tQ04Q= X-Google-Smtp-Source: AMrXdXvW0c+SSzHbkkx7BKDaC/xCkThY6I82pEW6I56dnzxwW5Hy1nNt8VUzyeBfXkSPx0urDyst+A== X-Received: by 2002:aa7:9adb:0:b0:56c:2049:f55b with SMTP id x27-20020aa79adb000000b0056c2049f55bmr8386001pfp.26.1671719825612; Thu, 22 Dec 2022 06:37:05 -0800 (PST) Received: from [0.0.0.0] (ec2-13-113-80-70.ap-northeast-1.compute.amazonaws.com. [13.113.80.70]) by smtp.gmail.com with ESMTPSA id h133-20020a62838b000000b0056e8eb09d58sm804854pfe.170.2022.12.22.06.37.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Dec 2022 06:37:05 -0800 (PST) Message-ID: <78bbedae-e96a-4467-5906-571d07c22cc7@gmail.com> Date: Thu, 22 Dec 2022 22:37:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] verifiers: Don't return error for deferred image Content-Language: en-US To: The development of GNU GRUB , Leo Yan References: <20221222111439.2653118-1-leo.yan@linaro.org> <824a569a-70db-b5ca-dd8b-b6c1cef0dc67@gmail.com> From: Zhang Boyang Cc: dkiper@net-space.pl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=zhangboyang.id@gmail.com; helo=mail-pf1-x42e.google.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2022 14:37:14 -0000 Hi, On 2022/12/22 20:22, Leo Yan wrote: > Hi Boyang, > > On Thu, Dec 22, 2022 at 07:25:13PM +0800, Zhang Boyang wrote: >> Hi, >> >> On 2022/12/22 19:14, Leo Yan wrote: >>> When boot from menu and the flag GRUB_VERIFY_FLAGS_DEFER_AUTH is set, >>> grub returns error: >>> >>> Booting a command list >>> >>> error: verification requested but nobody cares: (hd0,gpt1)/Image. >>> >>> Press any key to continue... >>> >>> In this case, the image should be deferred for authentication, grub >>> should return the file handle and pass down to later firmware (e.g. >>> U-Boot, etc) for authentication. >> >> This is probably not what verification framework designed to be. It seems to >> be designed to verify files during GRUB is executing (e.g. check file >> signature if UEFI Secure Boot is enabled). > > Good point. We expect the solution is grub can defer authentication for > an image and invokes EFI LoadImage service, then EFI loader can load > and verify the image. > Since you mentioned "authentication" and "verify", I guess you are using/implementing some kind of secure boot mechanism. Is it an standard UEFI Secure Boot implementation? The standard UEFI Secure Boot for Linux works like this (at least on x86): 1) Firmware verifies and loads shim (shimx64.efi), which is signed by Microsoft. (https://github.com/rhboot/shim ) 2) shim registers an EFI protocol, to provide an API for verifying files. 3) shim verifies and loads GRUB (grubx64.efi), using certificate embedded in itself. The certificate is generated by vendor (e.g. Debian). 4) GRUB opens kernel image file and loads and executes that file. The key point is, during grub_file_open() of the kernel image, the verifier framework will call shim lock verifier, which calls the API provided by shim, to verify the signature of kernel file. (grub-core/kern/efi/sb.c) In the above example, the kernel is loaded by GRUB, not shim, not EFI firmware. GRUB calls the API provided by shim to verify the kernel. Another example is GRUB can also chainload Windows: 1) 2) 3) is same 4) GRUB invokes EFI firmware's LoadFile() and StartImage(). The verification is completely delegated to EFI firmware. shim is not envolved. In this example, the verification is done by EFI firmware, and GRUB/shim has no control of it. You can't even chainload GRUB itself because it's not signed by Microsoft. > For more specific, now I am debugging U-boot EFI with grub, since U-boot > EFI provides functionality for loading and authentication image (see > efi_load_image() in [1]), this is my purpose to use U-boot EFI to > authenticate kernel image (and even for initrd image). > It seems efi_load_image() is just a wrapper of EFI firmware's LoadFile() and there is no implementation of verification in U-boot? I'd like to ask what kind of image you are trying to boot/execute? If it is an EFI application, I think you can "chainloader" it and forget U-boot (if U-boot have no verification in it self). Let me guess: You are using standard Secure Boot, and want to boot linux kernel image directly signed by keys in EFI firmware, and your GRUB is installed with --disable-shim-lock. If this is what you are doing, you might run into the following situation: 1) During GRUB init, grub_efi_init() detects Secure Boot is enabled, so it calls grub_lockdown(). [grub-core/kern/efi/init.c] 2) grub_lockdown() registers lockdown verifier. [grub-core/kern/lockdown.c] 3) grub_efi_init() also calls grub_shim_lock_verifier_setup(). However, grub_shim_lock_verifier_setup() does nothing because of "--disable-shim-lock" [grub-core/kern/efi/sb.c] 4) During GRUB load linux kernel, the lockdown verifier sets a flag (GRUB_VERIFY_FLAGS_DEFER_AUTH) for kernel file, and expect shim lock verifier to do the verification. 5) However, there is no shim lock verifier. As a security measure, it reports the error "verification requested but nobody cares". So the root cause seems like --disable-shim-lock is broken? As a workaround, you can use shim: build shim for you platform and install GRUB with shim support. You can also submit a fix to --disable-shim-lock (recommended). However it should be done very carefully. I'm afraid you can't remove the security measure (i.e. the "verification requested but nobody cares") directly. I think it is a good idea to add an EFI verifier (like shim verifier), which use LoadImage() to do verification, and enable it if (and only if) --disable-shim-lock is specified. You can talk to GRUB maintainers about your proposal before coding. The above is what I guess about what's happening. It might be wrong. Please point out if there is something wrong. >> By the way, I didn't understand what does "return the file handle and pass >> down to later firmware" means. If you means you want GRUB call into >> firmware's function, you can write a verifier to do that and register your >> verifier with grub_verifier_register(). > > To be clear, I am not experienced for EFI and grub, I try my best to > give info :) Me too :) Best Regards, Zhang Boyang > > As explained above, we don't want to introduce any new verifier in > grub, it's about we want to verify image in U-boot EFT rather than in > grub. So this is why I wrote this patch to dimiss the failure in grub > and pass image info to U-boot EFI service. (and sorry my commit log > introduced confusion). > > Thanks, > Leo > > [1] https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_boottime.c#L2021 > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel