From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id +DdeKzrRAGP2NgAAbAwnHQ (envelope-from ) for ; Sat, 20 Aug 2022 14:19:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YHEhKzrRAGMmfAAAauVa8A (envelope-from ) for ; Sat, 20 Aug 2022 14:19:06 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 721BD2CECD for ; Sat, 20 Aug 2022 14:19:06 +0200 (CEST) Received: from localhost ([::1]:42156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPNRR-0006pX-Kw for larch@yhetil.org; Sat, 20 Aug 2022 08:19:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPNRG-0006pO-GI for guix-devel@gnu.org; Sat, 20 Aug 2022 08:18:54 -0400 Received: from mailout3.hostsharing.net ([176.9.242.54]:34889) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPNRE-0002qa-HN for guix-devel@gnu.org; Sat, 20 Aug 2022 08:18:54 -0400 Received: from h20.hostsharing.net (h20.hostsharing.net [IPv6:2a01:37:1000::53df:5fec:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mailout3.hostsharing.net (Postfix) with ESMTPS id DFC6A1009FD4B for ; Sat, 20 Aug 2022 14:18:46 +0200 (CEST) Received: from anna.fritz.box (55d42380.access.ecotel.net [85.212.35.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by h20.hostsharing.net (Postfix) with ESMTPSA id AC32E13126 for ; Sat, 20 Aug 2022 14:18:46 +0200 (CEST) Message-ID: <58af78b0b22f6a4bf2ab0e09637be4c13a547247.camel@platen-software.de> Subject: Re: secure boot From: Tobias Platen To: guix-devel@gnu.org Date: Sat, 20 Aug 2022 14:18:46 +0200 In-Reply-To: <87h727tazd.fsf@yahoo.com.br> References: <87h727tazd.fsf.ref@yahoo.com.br> <87h727tazd.fsf@yahoo.com.br> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=176.9.242.54; envelope-from=guix@platen-software.de; helo=mailout3.hostsharing.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660997946; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=F/zvZ9n0qJcnqjRrR34KX8i1uhxVT+oQ6RlqQVEUx8c=; b=cudTzXFSCLlWBOOVJdkM/bpZVQ754ojpa4iEILYefSp8+8S8sAE5FPzsiAMglM3RtQcqfT ggBvfMM1bYx2+yXDcHpBwVau3xHBf7lh6/Xu+Gr6ZBSeHHl93aYlqwZjs7eGk7RRyJPbW6 PvO8TLJLn/ZOXf5Cfzd/tEYgw3ixxDeTiywf9CwwrawsGDoUYeID8l1AmqqhopTaSqWp6Q 5eEH8GGD8ZiuUhWp4zzS+NQcZ+9SbMpBw9MnauxOeaBbDPNChO0yNbmkGVxxHF7CfjYeFh 2rly3SzNnxkKhttomzUeu6lC/hzI0kb9Pmxe4cWb9ASp7ceTGOpgoPg+ERnVwA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660997946; a=rsa-sha256; cv=none; b=gXVfqm9xgDV1upV9Veec9jQ223hzkU6KWAFGYmgqJmXl2EKjBl8fY0XwGf0JyOpwFEfPWv ZVtvfr/BAIyAv38+B1XOuOeFPc8eObiZ3Oc9vK7NTAa0iXRP4Djl73w5z3JTBAUbnp4CUe YON+Myd4P22Zq+p4e4CVW+Qu8M7OGui5Ahmdy2lqeB3Xy9VvYAedge4UpC2ayu+Fh70w9c LTo/J8bl8ZSNvLdOwAly0Guw9DK2W+lZwvvXnUFaBlURav3geW1yfEl3ux/WF7+/H0J/sS fcrYxnqpXAf2XmPX9M6FxE/3q124nNNcPlu4qS3WCjac2RjRQIH7wLMGsjR3Ig== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.95 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 721BD2CECD X-Spam-Score: -3.95 X-Migadu-Scanner: scn0.migadu.com X-TUID: B2kTFNeYdlp4 That would be interesting, even on a Talos II, which has owner controlled secure boot. There will be no need to sign with a Microsoft key as most UEFI implementations do. There are two Microsoft keys, one for Windows and one for all other OSes. On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote: > Hello, > > I hope my question makes sense. It concerns Guix grub UEFI > bootloaders. > > I would like to understand in which extent Guix functional approach > helps to secure the computer with regards to an early boot malicious > code/malware infection. > > As far as I understand, Guix doesn't provide means to automatically > sign > bootloaders and kernels in order to use UEFI secure boot after each > system > reconfigure (assuming a PKI is properly implemented).  Hence, using > secure boot with Guix is currently not viable (am i correct?). > > In this context, can I assume that the risk of not having secure boot > is > minimized by the fact that in each system reconfiguration, the early > boot chain is overwritten is such a way that, if a malicious is > introduced somehow, it will be also overwritten? Am I correct? > > In addition, how much more difficult it is to introduce such > malicious > code in a Guix system giving its functional approach and store > system? > (in comparison with others Linux distributions). > > I know that Guix provides an amazing approach to secure software > supply > chain, but I as wondering if not having secure boot can be considered > a major drawback for Guix. > > Best regards