Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp10725920rwl; Mon, 2 Jan 2023 07:15:34 -0800 (PST) X-Google-Smtp-Source: AMrXdXsAJynDnSRxjp6wbkRjH3iHiIbKpyZfc+SN6WIAbfiV/TCy+MW2rwzem5jXAwuS2DfYDkEv X-Received: by 2002:a17:90b:4cc2:b0:225:f095:a3dc with SMTP id nd2-20020a17090b4cc200b00225f095a3dcmr27613120pjb.14.1672672534311; Mon, 02 Jan 2023 07:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672672534; cv=none; d=google.com; s=arc-20160816; b=HCVUXz6GVh1EZvAZLPuv6bdr+tD4v0b41ev1ok3wF1Qe8UEEtzY9os/kyjnRyuDDWZ qdWO31GbF2IEexfFcYPcfb81P5V0qU/4FGw839KN2oDcjjT/HqaHHFp17AcP/JVcje5c v5atQjR1vOiOWkQhGuVOzkQyGm5FcIuz4tCvbgfwb0SBzbXrHQDjAm8CTeMCSXp1CpT5 /YjTV8O/k7g8PRGCO4fV0pRmsNRpIQq2/xg91E2O3K3PwSadmlIvUQyqlxdA7Tshw6n/ RVFgc5HwBSoRhLDFl0GmkpmSebIww/7dZxULxR0bPKFKer+P1ZcPyTbkZY3mx2Wbn4UN QGxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IG1cdiy1CkS1pPFordbJMkK1hhJGEd8r4QDsZMxFoG8=; b=1Du87OLWpC2fuMib2tY0kLkYGxZO+xsMaw0Accb5Zw458kazcK4xyMgOdhDt17BUGr mdCyieLGJ6PPyyjyprlm07XPF1Z1IZdx6i5zJ2WHLlY+d9FODwocI88MnXOLxqNsCYTi jZDr+FdEPnxVdH+2QF1D8zpVCf10IUORjdIEgb6IAuOQKrvXx8mU9CPP9NtsT3Wxpu9R x9SyOFiRbwxobyrZeeVM2tmksh+sp3XGMaz90Jt+uI0TEwDCm8Xr+okFW2YiBMOV4XQn iQ0zV4pARP7FkT7Z9j9fIpdt5Jgp4D1TNk908gTeQVYJ67fWOjjuNqe0O/5ikZf6MNlg MsHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=g5JhoYBC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 133-20020a63028b000000b00478a7e7a635si30204432pgc.639.2023.01.02.07.15.26; Mon, 02 Jan 2023 07:15:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=g5JhoYBC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236081AbjABPES (ORCPT + 62 others); Mon, 2 Jan 2023 10:04:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235976AbjABPEG (ORCPT ); Mon, 2 Jan 2023 10:04:06 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8737065F7 for ; Mon, 2 Jan 2023 07:04:05 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 39787B80D35 for ; Mon, 2 Jan 2023 15:04:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E30F6C43396 for ; Mon, 2 Jan 2023 15:04:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672671842; bh=IG1cdiy1CkS1pPFordbJMkK1hhJGEd8r4QDsZMxFoG8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=g5JhoYBCKO0AQ39xgQU5vDJzDvfaoBJj2MtmB8jks02J8FJM19Z+mpO8OjzpNwdFj Bavo56S9AYVExdjFjkpPOZXzuNGsfEPlHQLpK7+5ZO1HbT5YQ3uQJrIpmRKgRTG096 k9dYw+5Lg0+YSB/KYRO4Vs4NUkvpu3WZKcqRpn0oo6gMX9ut62288Nz8BM9p50vKpR 4KR5ADLzRcueX5dU1YV/cwo4lUQO3Fvuto1VZHfn38ZHAolJcCE1gga3K/bBlmDh+N h9Ap+cgELDJYoe2obgZDoOxUyUsQwpRYLF9xmBRL+PZH9Xb9iXAqWrAqfiHNG8+EMj cHH9xrCFB3ebA== Received: by mail-lj1-f173.google.com with SMTP id bn6so19356321ljb.13 for ; Mon, 02 Jan 2023 07:04:02 -0800 (PST) X-Gm-Message-State: AFqh2kpV1/UarIvzzuYHPXVqRTYnycdhDSBIut1tDFK2n10P0BE+swJ2 MdG8fgD7YGPVMMG4RJUMs1VIR0uW6upYebG6rOU= X-Received: by 2002:a2e:bd0c:0:b0:27f:bc58:3924 with SMTP id n12-20020a2ebd0c000000b0027fbc583924mr2090552ljq.352.1672671840869; Mon, 02 Jan 2023 07:04:00 -0800 (PST) MIME-Version: 1.0 References: <60566f8b-c90f-12e7-c13e-94e9829eee2d@zytor.com> <8f072588-7d66-0932-7486-ed9159ae93ae@zytor.com> In-Reply-To: From: Ard Biesheuvel Date: Mon, 2 Jan 2023 16:03:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data To: Borislav Petkov Cc: "H. Peter Anvin" , "Jason A. Donenfeld" , pbonzini@redhat.com, ebiggers@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, kraxel@redhat.com, philmd@linaro.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2 Jan 2023 at 14:37, Borislav Petkov wrote: > > On Mon, Jan 02, 2023 at 10:32:03AM +0100, Ard Biesheuvel wrote: > > So instead of appending data to the compressed image and assuming that > > it will stay in place, create or extend a memory reservation > > elsewhere, and refer to its absolute address in setup_data. > > From my limited experience with all those boot protocols, I'd say hardcoding > stuff is always a bad idea. But, we already more or less hardcode, or rather > codify through the setup header contract how stuff needs to get accessed. > > And yeah, maybe specifying an absolute address and size for a blob of data and > putting that address and size in the setup header so that all the parties > involved are where what is, is probably better. > Exactly. In the EFI case, this was problematic because we would need to introduce a new way to pass memory reservations between QEMU and the firmware. But I don't think that issue should affect legacy BIOS boot, and we could just reserve the memory in the E820 table AFAIK.