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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4B755C05027 for ; Thu, 2 Feb 2023 19:03:03 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNer3-0007Fn-2U; Thu, 02 Feb 2023 14:02:41 -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 1pNer1-0007Fe-JT for qemu-devel@nongnu.org; Thu, 02 Feb 2023 14:02:39 -0500 Received: from [2607:7c80:54:3::138] (helo=mail.zytor.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNeqy-0004C1-Tv for qemu-devel@nongnu.org; Thu, 02 Feb 2023 14:02:39 -0500 Received: from [127.0.0.1] ([73.223.250.219]) (authenticated bits=0) by mail.zytor.com (8.17.1/8.17.1) with ESMTPSA id 312J2Uv02096822 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 2 Feb 2023 11:02:31 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 312J2Uv02096822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2023010601; t=1675364551; bh=doXZ3orLBvUZdkC2mrIQ4cMwe1b5DKKpciUdKr0NWes=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=OsVBecGDi4R5VD5ZYSyy/WcpQhDlU6cyiZdbkotA7dCk1Sv4+Q11vGO9gkPSK31CF F04CuHEHELfUa/tKMYGi4k9o9j4jQFeGRdd8ZZzN2ae7QQCbyVmelzDtPk+cQl3Jl4 RvBqe9MgM05xrLXbsscHnMDI2KwAzCnsNio7ZJobKDgInQVMKQMWNU1X/pufZj//wo Dy1SNkHEc7fjoK7tVxfI8uHcrcfZ0btnf40sHKcawC1tYBfsgBlqtPdG9Ro+tbL7NF 3KUIjzHyIf7ALTfyrw9wwJqL28DAFPoL0ArO3ROTbw26musovX94VM4/BAcWSnKst9 7VIgnTX6DpA/A== Date: Thu, 02 Feb 2023 11:02:30 -0800 From: "H. Peter Anvin" To: jejb@linux.ibm.com, James Bottomley , "Jason A. Donenfeld" CC: QEMU Developers , Gerd Hoffmann , DOV MURIK Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_x86=3A_fix_q35_kernel_mea?= =?US-ASCII?Q?surements_broken_due_to_rng_seeding?= User-Agent: K-9 Mail for Android In-Reply-To: <352eb28a1d913db62421064fe50ec9c8f8afd050.camel@linux.ibm.com> References: <2b8fc552e1dc3a14de404eeaff0819ec8da7de54.camel@linux.ibm.com> <4396778A-6520-4FB5-9227-1E8850753036@zytor.com> <352eb28a1d913db62421064fe50ec9c8f8afd050.camel@linux.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:7c80:54:3::138 (failed) Received-SPF: pass client-ip=2607:7c80:54:3::138; envelope-from=hpa@zytor.com; helo=mail.zytor.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On February 2, 2023 7:17:01 AM PST, James Bottomley wrote: >On Thu, 2023-02-02 at 07:03 -0800, H=2E Peter Anvin wrote: >[=2E=2E=2E] >> NAK=2E We need to fix the actual problem of the kernel stomping on >> memory it shouldn't, not paper around it=2E > >This is a first boot situation, not kexec (I just updated kexec because >it should use any new mechanism we propose)=2E Unlike kexec, for first >boot we're very constrained by the amount of extra space QEMU has to do >this=2E The boot_params are the first page of the kernel load, but the >kernel proper begins directly after it, so we can't expand it=2E The two >schemes tried: loading after the kernel and loading after the command >line both tamper with integrity protected files, so we shouldn't use >this mechanism=2E This is the essence of the problem: If we add this >area at boot, it has to go in an existing memory location; we can't >steal random guest areas=2E All current config parameters are passed >through as fw_config files, so we can only use that mechanism *if* we >know where the area ends up in the loaded kernel *and* the file isn't >integrity protected (this latter is expanding over time)=2E > >If we could wind back time, I'd have added the 32 byte random seed to >boot_params properly not coded it as a setup_data addition, but now >we're stuck with coping with existing behaviour, which is why I thought >the retro fit to boot_params would be the better path forward, but if >you have any alternatives, I'm sure we could look at them=2E > >James > Somewhat aside=2E=2E=2E There are other issues with passing the entropy seed in memory, of course;= in order to avoid accidental or malicious reuse it would be far better if = the entropy was actively pulled at use time via virtual I/O, a hypercall, o= r RDRAND/RDSEED emulation, but I do realize that that is not always an opti= on=2E