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 96DBDC433F5 for ; Thu, 16 Dec 2021 15:56:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8A9F182A65; Thu, 16 Dec 2021 16:56:12 +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="TbUNEAXD"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 246B882EBB; Thu, 16 Dec 2021 16:56:10 +0100 (CET) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 12A8781423 for ; Thu, 16 Dec 2021 16:56:07 +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-wm1-x335.google.com with SMTP id i12so19222188wmq.4 for ; Thu, 16 Dec 2021 07:56:07 -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=xSaEoTbafJcATz+oS+UWtRI6slAaPfqCFd4/SNAvuVk=; b=TbUNEAXDHQUFklE2ohySsr7FT7Ig82TSd68y/ppaqd0e63CRs0MIGylUhUU7+c5Idj xx+QKvTdEhKzqClWrOFtew/z9m3KQCSIXB86B7TKzJBbUl4jwE+ojMscakgYehAwTbbQ YyJdb0MfSjsJJ2Q+3sWZMZJT6jpEQmvl6BcGZrpJIWFqQpLvvescxZWPpMa3nHKSE0vi 1RnAdsLWbQcDKXL8XwBPXDfXBcC4JZaW+DJdoibP+XBsZns/8B939wlBkdBTuTGcjxcC jSvy6em3Wgkc3RvGarC4vqe0csKPwJXTnp/f9bnjEw+dxam4hCLhCWN5V4U3P7C+zMwe zwCQ== 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=xSaEoTbafJcATz+oS+UWtRI6slAaPfqCFd4/SNAvuVk=; b=yRtLBoj0E99l4LkNkyernLqt2E/gndqmEsu+mt3oQgg5AZB82k1UeCPtdFhprC7Goj B3dHRzb1mXsKUFr+0avi0YTvVbhzO48ndlCjWjWmIWB02XxsuOw5M+n/RPxFeWhaJrK/ nVlPYvATb9fomMKA078QfiZxyVD+aiPg91yUpPjicjmMYdFr4NBWcLubz73WnpLtexJO lLCQ1tWbJ6x2XXiWxLFzZ241ld2HVOmsJ40HwKzgP7A4I83ixRM9XdHhqWz0gKIFmkU4 wtI7eOxyMFaVviCjTcWMn9Q/3w7Rke8y96uGGaG9dEXs+NrhdBpsKEayb0gpTPT00wOf m6Yw== X-Gm-Message-State: AOAM533kwE8FWY3i55if+kMAyLAjKbBsSGhNFclLH9Wt46ftoUcRYf+C artVugifHJF69wx2LZ3jV5CGiA== X-Google-Smtp-Source: ABdhPJwQbt2y8Km/LX+j+VthpfJmqIP8CPJYjZGe0vfvNnfkjVhSBq4UWKB/ASWBoWjZAUT5QdWlzw== X-Received: by 2002:a05:600c:2159:: with SMTP id v25mr5488511wml.131.1639670166566; Thu, 16 Dec 2021 07:56:06 -0800 (PST) Received: from hades (athedsl-4461669.home.otenet.gr. [94.71.4.85]) by smtp.gmail.com with ESMTPSA id l6sm5390891wmg.3.2021.12.16.07.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Dec 2021 07:56:06 -0800 (PST) Date: Thu, 16 Dec 2021 17:56:03 +0200 From: Ilias Apalodimas To: Mark Kettenis Cc: Ard Biesheuvel , xypron.glpk@gmx.de, agraf@csgraf.de, u-boot@lists.denx.de Subject: Re: [PATCH] efi_loader: Get rid of kaslr-seed Message-ID: References: <20211216145209.2426137-1-ilias.apalodimas@linaro.org> 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 Thu, Dec 16, 2021 at 04:48:04PM +0100, Mark Kettenis wrote: > > From: Ard Biesheuvel > > Date: Thu, 16 Dec 2021 16:28:06 +0100 > > > > On Thu, 16 Dec 2021 at 16:25, Mark Kettenis wrote: > > > > > > > From: Ilias Apalodimas > > > > Date: Thu, 16 Dec 2021 16:52:08 +0200 > > > > > > > > Right now we unconditionally pass a 'kaslr-seed' property to the kernel > > > > if the DTB we ended up in EFI includes the entry. However the kernel > > > > EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL. > > > > So let's get rid of it unconditionally since it would mess up the > > > > (upcoming) DTB TPM measuring as well. > > > > > > NAK I don't understand why though. I can simply send a V2 and have a Kconfig e.g CONFIG_MEASURE_DTB, which would control stripping the property -- or we could save- > strip -> measure -> re-inject (which is a horrible idea but that's the current reality). > > > > > > OpenBSD uses the kaslr-seed property in the bootloader to mix in some > > > additional entropy. (It will also use EFI_RNG_PROTOCOL if it is > > > avilable, but most U-Boot boards don't provide that, or at least not > > > yet). > > > > > > > What is the point of using both the DT property and the protocol if > > both are available? > > Unless kaslr-seed is coming from a different entropy source, there > probably isn't a point. But it doesn't hurt and it made the > bootloader code simpler. It does hurt the measurements though. The current situation is a bit weird. Ideally the firmware would provide the DTB and I would be be able to measure prior to any fixups. However that's not the reality today. So we do have to measure just before we install the config table. Which means that all entries that can change across reboots needs to be ignored. > > It does mean there is some room for compromise though. If U-Boot > would only remove kaslr-seed if it implements EFI_RNG_PROTOCOL it > wouldn't be a problem. > > > > Even on Linux the EFI stub isn't the only way to load a Linux kernel. > > > You can use a conventional EFI bootloader like grub. > > > > > > > No, you cannot, at least not on architectures other than x86. GRUB on > > ARM always boots via the EFI stub. > > Ok. It isn't immediately clear from the documentation that this is > the case. It would still be possible to write such a bootloader, but > if it isn't a thing, it isn't a thing. But not all the world is > Linux. Yea but measuring is a reality (and a spec for all it matters). So we need to find some way of fixing this. Regards /Ilias