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 16949C3DA7D for ; Sat, 31 Dec 2022 14:25:34 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBcn0-0007BE-2N; Sat, 31 Dec 2022 09:24:46 -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 1pBcmz-0007B3-0I for qemu-devel@nongnu.org; Sat, 31 Dec 2022 09:24:45 -0500 Received: from mail.skyhub.de ([5.9.137.197]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBcmu-0006uM-7L for qemu-devel@nongnu.org; Sat, 31 Dec 2022 09:24:44 -0500 Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1B2001EC01E0; Sat, 31 Dec 2022 15:24:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1672496676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=XSRYAEgw00hfGYGFyTs9QzvEt1IVj0uy86Sl3MJzWNo=; b=hRYLjF3LQ72BqRPTIm/21vylTA8dAoZkS23G+BhIpgmeca8+mXlaruNqX7NzKxB7Ue9E8H Ly/yPURcM1ogoeJQM/ZkNXuXmQNE9EyIeh1wePILlzj0LhoNAo0JXOncEtPNgLhaBe7d6v qSSdKsP5bHFSQW0D5LGdCC/FVLHAdls= Date: Sat, 31 Dec 2022 15:24:32 +0100 From: Borislav Petkov To: "Jason A. Donenfeld" , "H. Peter Anvin" Cc: pbonzini@redhat.com, ebiggers@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, ardb@kernel.org, kraxel@redhat.com, philmd@linaro.org Subject: Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data Message-ID: References: <46466e54-25c3-3194-8546-a57cd4a80d9d@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=5.9.137.197; envelope-from=bp@alien8.de; helo=mail.skyhub.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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 Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote: > That failure is unrelated to the ident mapping issue Peter and > I discussed. The original failure is described in the commit message: > decompression clobbers the data, so sd->next points to garbage. Right, and the fact that the kernel overwrites it still feels kinda wrong: the kernel knows where setup_data is - the address is in the setup header so *actually*, it should take care of not to clobber it. But hpa would correct me if I'm missing an aspect about whose responsibility it is to do what here... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette