From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yHiIGAiIBGMxXgAAbAwnHQ (envelope-from ) for ; Tue, 23 Aug 2022 09:55:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KM2nFwiIBGPVgQEAG6o9tA (envelope-from ) for ; Tue, 23 Aug 2022 09:55:52 +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 F0FD711E50 for ; Tue, 23 Aug 2022 09:55:51 +0200 (CEST) Received: from localhost ([::1]:39802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQOlJ-0005FV-E0 for larch@yhetil.org; Tue, 23 Aug 2022 03:55:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQOYh-0002R0-4j for guix-devel@gnu.org; Tue, 23 Aug 2022 03:42:48 -0400 Received: from jpoiret.xyz ([206.189.101.64]:38614) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQOYd-0006f4-HO for guix-devel@gnu.org; Tue, 23 Aug 2022 03:42:46 -0400 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 6D24D18530C; Tue, 23 Aug 2022 07:42:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1661240556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dsYCkv0mEYpHkqTvpW2g6XlFydtlaRoBdDxEpXITsMk=; b=T/hAa0/E0znILgYP91koshEFIEfpMQpmqN2r4l/dyhAFatvj/npyOWh8lqKdB2cT3PTU25 VOJgnJuJ1k8xMePs/AftdJ8+CwZqY8cBF29mobx0yUEvTb/NVHjiyNOCB/+ggm+KWCNAUK EySwnL66VShoIUIvJqh/T7BNt0VXl3G30X5vyOqDAvHHie7hPi1Owh8PiIckIsAbFSs0A8 vsmd4aVqS72gxJEhmpigFaDz4O3oNBFirUxZkHcWbzoRRI0Tpwr7dZuK3oAzIWuh2d+tD1 UaPmctyd/n8IN5LRKZOKwrStiIscLUK1mxCYsavZ4woGXqN98D4iHN5Qle11mw== From: Josselin Poiret To: Antonio Carlos Padoan Junior , guix-devel Subject: Re: secure boot In-Reply-To: <87a67wrq81.fsf@yahoo.com.br> References: <87h727tazd.fsf.ref@yahoo.com.br> <87h727tazd.fsf@yahoo.com.br> <87pmguugp0.fsf@jpoiret.xyz> <87a67wrq81.fsf@yahoo.com.br> Date: Tue, 23 Aug 2022 09:42:35 +0200 Message-ID: <87h723v21g.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / Received-SPF: pass client-ip=206.189.101.64; envelope-from=dev@jpoiret.xyz; helo=jpoiret.xyz X-Spam_score_int: 0 X-Spam_score: -0.1 X-Spam_bar: / X-Spam_report: (-0.1 / 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, FROM_SUSPICIOUS_NTLD=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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=1661241352; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=dsYCkv0mEYpHkqTvpW2g6XlFydtlaRoBdDxEpXITsMk=; b=MhTGeT7AgtWmi2vRhkukgGQjAB55bxFGB74Bf9X4dw4sE4k14ECo9Tvb++NiF9TP7acNcA XQobv59Nq0/ZJ1jfAlVatuPEcyOEUFoczQGMTKBViC4RGYDDd1q4xDAyYt47qDi9Kx9mx1 h2KpC8wWXSqUi2kAz49JYnvRnTAl/MrUAzpiv092rK11yLP6rkDURLIXpXKDX5Rf8wOrh2 2bkc3aEvhRoy5OztK3qBQSswniHCrLKDtw9OAJ+xv6vvuMcF21rJV0oBCVZCTdA3o4nvkE K6fkFXmIzfI1vg1PujG2uzvfHuBSaYtVkTIGx4kBhxeXgaGG/3LvHhK1Fy+qKA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661241352; a=rsa-sha256; cv=none; b=F6AgB5syrfGdwnLeyd8gccNq3QARBZhO3BZlcBPVXxMt5ymC5K051zO9W8X9DhBi+hVz1L 00OCSPF/w3RodwOYHK2jqvoYUXza4GS4a/XDTJJEWPnQACab6sVBBJuwZNz1XwnaVqlEDC Z4P8BvcCROJBKKdIlZTX4x7Xe8ZUENg1OzJyiU6TcBe4tyJjg76Lv3n11o14LmbQUXkmST THq0ksVFTDnS8KglKQN5AO2IBUJGjOLsFeLBUAKKsdydhKa9TXoo/fwKIyEyieX63UxL4V Yg7946RDbHCze93tQOcg+hAcLs/pLXsdunqPpG/gx21nHbmyZd5UVlfpROKj4g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=jpoiret.xyz header.s=dkim header.b="T/hAa0/E"; dmarc=pass (policy=reject) header.from=jpoiret.xyz; 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: -5.80 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=jpoiret.xyz header.s=dkim header.b="T/hAa0/E"; dmarc=pass (policy=reject) header.from=jpoiret.xyz; 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: F0FD711E50 X-Spam-Score: -5.80 X-Migadu-Scanner: scn0.migadu.com X-TUID: 1yIPohMX/HGK Hi Antonio, Antonio Carlos Padoan Junior writes: > Can we imagine signing the kernel outside the guix layer, I mean, > directly into the store without using guix commands? I understand this > would break conceptually the Guix functional characterization, and it is > not very "clean". But despite these points, any other side effects expected? This subject has been discussed a bit in the past. My opinion on what you're suggesting is that: * We should not modify the store in place. This is bound to create problems for the user, because we'd be breaking the Guix guarantees. * You could sign it out of the store. Basically, something like `sign /gnu/store/xxxxxx-bzImage > /boot/bzImage_signed`. However, this poses problems with generations, since either we prohibit loading older generations, which is a huge step backwards, or we sign all of the older generations as well, which will take a non-negligible amount of space. In that case, we'd also need to keep track of the different signed kernels that are sitting in /boot to be able to clean them up when the generations are deleted. It's not an easy problem unfortunately, and the number of people whose threat model requires such a thing is slim, hence the lack of work in that direction. Best, -- Josselin Poiret