Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp10253927rwl; Sun, 1 Jan 2023 22:11:34 -0800 (PST) X-Google-Smtp-Source: AMrXdXtO9UsgKCgrsAIkod/yQQJk0sSBrW9duBt2FOU2LxoBf5glxQk6XtcOxmDrDqUGx6wOgK07 X-Received: by 2002:a17:90a:9b0b:b0:226:208a:1713 with SMTP id f11-20020a17090a9b0b00b00226208a1713mr16514184pjp.39.1672639894180; Sun, 01 Jan 2023 22:11:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672639894; cv=none; d=google.com; s=arc-20160816; b=uBt9SyL8Jrm/BimI5aB13XrATk8WEIKISuYdIzVUvL1qgkceHORYQFs0ROHaLNvedj D9dreJwbtTITdtr30RTJZtwHokiH4DqGQm7aw4ZYNdySsd8OwPD7E/Is9Nzg9bwxyqFG ygZ/0bL5n/h+DMj31EsXaJBTemNJMFVXvnM3PLlATK1jhpABd9HL5JQwPYKW4Q3IKSkC pRxv/ZkZH9f+GK81wfUblZIBYhJEBO8MiQZIaooWuyBY4+6nBZGiRG1kc9RNExbhP7JE dmqhR0DypfniefhJtpw5uy9IYPkKIiHj2hSa9nXn2uesVFiWJnwHSdBcqgEPuXLk3VWM RIhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KNARFvNRF3/uNoEZNfyHRQ1mNp3FRIAd1Kh6JpigTAU=; b=ycWrO8QX1ZgVIbXZhEvLRMiyHNym1HhQX1y8XLeZRK83bIOI9avlAibLc1d05Ym6eG HzkKOypVA+M3UqIXnY5VJGSsRRJKvrc4+cj6HRIrMWTg99ASVt/msfrnkli81kdhgulC JhUc+rQ+3IheqEUgoMhfFiRItr20uYb5BxBbfY4fhvXp692sAruKErHYr0cqEpIlH5Aa SBg33e4IGf8Z6hoQ+CCxI2GzcJi6KK9GqqdKa/uEOqur3VAmETel1+RKxHfQWgWFeuEA Jlj4rs81z6c/fIH2eCcUNH2u7zroD9W5YeGQ2Ckze7q9hE7MRd1EIMYA7VKLPcO2Po6Y CTvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=EwhAW3ZM; 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=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pc3-20020a17090b3b8300b00219a8d98afbsi36348032pjb.132.2023.01.01.22.11.01; Sun, 01 Jan 2023 22:11: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=@alien8.de header.s=dkim header.b=EwhAW3ZM; 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=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229645AbjABFuq (ORCPT + 60 others); Mon, 2 Jan 2023 00:50:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjABFuo (ORCPT ); Mon, 2 Jan 2023 00:50:44 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB024114E for ; Sun, 1 Jan 2023 21:50:42 -0800 (PST) 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 04F8C1EC04AD; Mon, 2 Jan 2023 06:50:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1672638641; 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=KNARFvNRF3/uNoEZNfyHRQ1mNp3FRIAd1Kh6JpigTAU=; b=EwhAW3ZMQ5mHmamvxGQza8LDPgkAHg2W9i+6MiWrnI1SmyPZXvcR3V/wNJSjhdWFVEs9Eh yON4gwl2XO/AnTuZ6o61SoQgppqUAbgm1nJbtaE5vfCCrKi9fbK2z7KkpP3HF2+ZlJ22t7 9XgvfECl0k/BcwM98LAA/58G602g+8w= Date: Mon, 2 Jan 2023 06:50:35 +0100 From: Borislav Petkov To: "H. Peter Anvin" Cc: "Jason A. Donenfeld" , 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> <60566f8b-c90f-12e7-c13e-94e9829eee2d@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <60566f8b-c90f-12e7-c13e-94e9829eee2d@zytor.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Sat, Dec 31, 2022 at 07:21:06PM -0800, H. Peter Anvin wrote: > As far as the decompression itself goes, it should only a problem if we are > using physical KASLR since otherwise the kernel has a guaranteed safe zone > already allocated by the boot loader. However, if physical KASLR is in use, No KASLR in Jason's config AFAICT: $ grep RANDOMIZE .config CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET=y CONFIG_RANDOMIZE_KSTACK_OFFSET=y # CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT is not set > then the decompressor needs to know everything there is to know about the > memory map. Yeah, we do have that but as you folks establish later in the thread, those setup_data regions would need to be avoided too. ;-\ > However, there also seems to be some kind of interaction with AMD SEV-SNP. > > > The bug appears to have been introduced by: > > b57feed2cc2622ae14b2fa62f19e973e5e0a60cf > x86/compressed/64: Add identity mappings for setup_data entries > https://lore.kernel.org/r/TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com > > ... which was included in version 5.19, so it is relatively recent. Right. We need that for the CC blob: b190a043c49a ("x86/sev: Add SEV-SNP feature detection/setup") > For a small amount of setup_data, the solution of just putting it next to > the command line makes a lot of sense, and should be safe indefinitely. Ok. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette