From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0081DC433F5 for ; Mon, 3 Jan 2022 07:30:15 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 46A6A82EBB; Mon, 3 Jan 2022 08:30:13 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="aqWMrywc"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0533683420; Mon, 3 Jan 2022 08:30:12 +0100 (CET) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D3808805F9 for ; Mon, 3 Jan 2022 08:30:08 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-ed1-x532.google.com with SMTP id z9so62743650edm.10 for ; Sun, 02 Jan 2022 23:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TOx5spAr0tQdzXGJCWDdLDsd0mXRIKekdk1itXdu+IQ=; b=aqWMrywcOG3cmCBERXupLA9RgbM/ab+Q0iTttnxvQ6DcdJb49sKhcxGccsQ4GE82aX Jw1re0/V3zESN86TstgxbPE/liiiBrkPPlT9PRCg7W1GIOG8kyHDero0u5Bon320nKkV x3y83bIEbyoFVGHPzQSyciL/W5UN7f1fBMxqH59bG4RqvZ4NbVKJCjs2eOwOQCy2oib9 ZM0HCP7GlqGnJpnk/6ZXVaFwBlwVSJfB8lU91635PntRNX67/3RiookIBjFc+928MVVK V797pG29iaKYoHNiolLATyBKTtEKqce8Yj/30X/m+mh/MMs0z3xx8q1bkRPfYGxjJxgh wo4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TOx5spAr0tQdzXGJCWDdLDsd0mXRIKekdk1itXdu+IQ=; b=pyXkOEMTrhBqGD33owtjWvWc0b/r5AHmoXGXmswtHFZ2c0d9LTbY2XZ85wlqGAYiPk gJMRO+XQpI0EIw9GbbK+1F5XaoMO/llmTj3agCx+RL2gG5VzS1g5U6iozZFc1RNClTRq 4cWMRPfg+sOi7otCkyjQ6yDpx9G78pTDydemQN26ATf+u+MUfc2bB9VTdrltQGnH9z2/ Qxpdmvrr3N9hgnxIVLD36rw0D/cqrH2P8PNVz/nqlEWKlFUYLmNieXiwquUpGhiCom4h y0RJEbd3TTAJqjTyntO8Wz433SGuTyoylMC3MD+aZ+GySI4bWCcXbIktooGs0Uy7CCbx JJxg== X-Gm-Message-State: AOAM5319y1k0rhr+bnaRsQj2DegmFrjBXFNLvWlKaTNb/j+xCjDptb65 Z/5vjSPgM92JZ1d+Zp/1XdcdENPPmHXyHQ== X-Google-Smtp-Source: ABdhPJzRIqMcpdKm9NB0fbTYHkr99EenapCBnJ6Fgo8pNFEdrs3yacWgd2QpKHwfDwfWszVnsRz9rw== X-Received: by 2002:aa7:cd12:: with SMTP id b18mr43492013edw.355.1641195008506; Sun, 02 Jan 2022 23:30:08 -0800 (PST) Received: from hades (athedsl-4461669.home.otenet.gr. [94.71.4.85]) by smtp.gmail.com with ESMTPSA id 18sm1603769ejw.187.2022.01.02.23.30.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 23:30:08 -0800 (PST) Date: Mon, 3 Jan 2022 09:30:05 +0200 From: Ilias Apalodimas To: Mark Kettenis Cc: Heinrich Schuchardt , ardb@kernel.org, agraf@csgraf.de, u-boot@lists.denx.de Subject: Re: [PATCH v2] efi_loader: Get rid of kaslr-seed Message-ID: References: <20211217070644.2458603-1-ilias.apalodimas@linaro.org> <16F01EF8-EE64-4B2D-B48E-D91E1E3DF4A7@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hi Mark, On Sun, Jan 02, 2022 at 10:27:50PM +0100, Mark Kettenis wrote: > > Date: Sun, 02 Jan 2022 22:06:11 +0100 > > From: Heinrich Schuchardt > > > > Am 2. Januar 2022 21:50:35 MEZ schrieb Ilias Apalodimas : > > >Hi Heinrich, > > > > > >> > > > > > > > > > >[...] > > > > > >> > > > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > > >> > > > > index d77d3b6e943d..57f13ce701ec 100644 > > >> > > > > --- a/cmd/bootefi.c > > >> > > > > +++ b/cmd/bootefi.c > > >> > > > > @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt) > > >> > > > > /* Create memory reservations as indicated by the device tree */ > > >> > > > > efi_carve_out_dt_rsv(fdt); > > >> > > > > > > >> > > > > + efi_try_purge_kaslr_seed(fdt); > > >> > > >> This function should only be invoked for CONFIG_EFI_TCG2_PROTOCOL=y. > > > > > >Why? As we discussed the kernel ignores the kaslr-seed for the > > >physical randomization. The only reason we would like to keep it is > > >for the randomization of the virtual address. But if the EFI > > >RNG protocol is installed the EFI stub is already doing the right thing. > > >So I really think purging it if EFI RNG is installed is the best option > > >here (regardless of TPM measurements) > > > > > > > The only reason to delete kaslr-seed is that it conflicts with > > measured boot. If an OS prefers the RNG protocol over kaslr-seed is > > the decision of the OS and nothing U-Boot has to care about. > > But it is also up to the OS to decide whether it cares about measured > boot or not. > > > You will have to delete kaslr-seed no matter if you have a RNG > > protocol or not if and only if you want to use measured boot. > > So you shouldn't just unconditionally delete kaslr-seed if the > CONFIG_EFI_TCG2_PROTOCOL has been enabled, but only if it is actually > used... But is that even possible? I can't think of any (sane) way to figure this out. > > So maybe you should just specify the certain properties (such as > kaslr-seed) should be skipped when calculating the hash of the device > tree. > We could, but I'd like to avoid that unless we don't have a better alternative. Thanks /Ilias