Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1401598ybv; Thu, 6 Feb 2020 03:27:43 -0800 (PST) X-Google-Smtp-Source: APXvYqznzZ+a0BG6IdA2C8xnUSj4Zv4x2D86qn72CMUk2zWtr7CflyUKyT8Gk3h6uFZmArB1gu12 X-Received: by 2002:aca:4ad8:: with SMTP id x207mr6234448oia.55.1580988463623; Thu, 06 Feb 2020 03:27:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580988463; cv=none; d=google.com; s=arc-20160816; b=tn45ZP2yDwNPhivpS3hqL7ACDp8s2KGAG4l6yihgq/oBDQBHmlsJGGchVpxKvAyjQv j4Og+4ZWi4/hyQ0Fh5awMYClz5yD0dUeotXUBQIOGZANuTv7upFMHZcev2f4t7s5MO6c wiTpt4ypXENANBINcn0WcAWDD+LH/azR6hL5o85GWxFRwfgtB/Arqgh1MWl0QYD6pgtP m3QSKbvJNYMzuy8RKL7EyFt89JEH46h4v9QZQ7bwy6B7Nm4I1RNlocxoCoyQOwROHTnL Xtdk4WUiqODZtx2IOQdgqIG1R0p5/eHm+g+0+B48jEARL1Mx+PUoyANvXvEcXrWURMO7 SBhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=h2zaw6iYfCWOwDZ0jhzlPX+I4JIVjefxCpHGGlUTe4o=; b=Da9GyyWQIDW0KwM1AAbE+Ml18JUv/aJBMw566UBDdZHK6uRzRDwGJgUt2kHkVJfdPR g7jMdeYTLLtgKre8pH2DF9nxSi9a5eSUH0JbShpJImZnD6/kTv3Ido7oQ2k0gjrXvoaN DE6oUWIQ01m9KCwke3o2U+UUQYO6Euxj7uGB0qvobeaXjkpDpX9jJXMlZKjxJ3k2QfwK 6ZF2qPkuDf/W5NNs2Nb28gE1O3XptCO2E01pSCBf4IYr1h+Y4jiUdQf9R089UMdshF7e aJ8gzPxLgcRgOYtjUs91bMNEI1SyPLgqQZ8PTPWBuB/+oAEoR7x1FcR82/U9U9vZYwZn njWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="ONYb77D/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14si1704936otf.178.2020.02.06.03.27.31; Thu, 06 Feb 2020 03:27:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="ONYb77D/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727591AbgBFLNQ (ORCPT + 99 others); Thu, 6 Feb 2020 06:13:16 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:34189 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727455AbgBFLNP (ORCPT ); Thu, 6 Feb 2020 06:13:15 -0500 Received: by mail-oi1-f193.google.com with SMTP id l136so4202447oig.1 for ; Thu, 06 Feb 2020 03:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=h2zaw6iYfCWOwDZ0jhzlPX+I4JIVjefxCpHGGlUTe4o=; b=ONYb77D/SZI16E9+HCdImeDUPdAG6Mr6whETfwFD/8yOkEPWUogsT0L+v7jxLgNgYM bdJzQr5rIdFpNCUd66hCFhq7P5RMFf4Wxj1XqaCQg4tgUN54X1cZc43hHrBR/6L81wmV LuvZmhlbyYuaus5JRJIk6GuIfYStFXOulZnuo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h2zaw6iYfCWOwDZ0jhzlPX+I4JIVjefxCpHGGlUTe4o=; b=DuAwjJGuz7QGU+2BWYQ8Rcj5RGrUGxU9lpCIC1TFT3OO8VXLfVgDrvLHtBMv0tOLdO lIv4w4e/i2B9O2/3NCaLi59iIqyyB0VMh6dBAvM5GpuAIY7TYtl8x2CgYcl7sEWRiVI1 zYDfwLygheKYVpeCGv6VG7Zl4nT4pCiRBPIxXMY8dV6pDs05HbKi2/AqkmPtuFI9HUa8 EgzmBO6lgsE1JXeo3Cs7EerpBa6Z8iggheU+RB7vU8/NrwSPj20U+BfhSjaPxVM534lT F3VHP/lEqnSuRgILFKqVuFOJigVMyy73S1AcpuU7r677yTHo903k6UN46fc9k2tD6vFK 2FPA== X-Gm-Message-State: APjAAAWTj4T5bLErOfzLQMeaqBFKPYPDJHEHIRr3r9AnFjWxGza+HQvE GsXoTsVN6vrDn0VxBzuYtaMd1Q== X-Received: by 2002:aca:aa0a:: with SMTP id t10mr6231066oie.156.1580987594941; Thu, 06 Feb 2020 03:13:14 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id h1sm983317otm.34.2020.02.06.03.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2020 03:13:13 -0800 (PST) Date: Thu, 6 Feb 2020 03:13:12 -0800 From: Kees Cook To: Arvind Sankar Cc: Kristen Carlson Accardi , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, arjan@linux.intel.com, rick.p.edgecombe@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [RFC PATCH 11/11] x86/boot: Move "boot heap" out of .bss Message-ID: <202002060251.681292DE63@keescook> References: <20200205223950.1212394-1-kristen@linux.intel.com> <20200205223950.1212394-12-kristen@linux.intel.com> <20200206001103.GA220377@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200206001103.GA220377@rani.riverdale.lan> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 05, 2020 at 07:11:05PM -0500, Arvind Sankar wrote: > From: Kees Cook > > This seems to be a trivial change because head_{64,32}.S already only > > copies up to the start of the .bss section, so any growth in the .bss > > area was already not meaningful when placing the image in memory. The > > .bss size is, however, reflected in the boot params "init_size", so the > > memory range calculations included the "boot_heap" region. Instead of > > wasting the on-disk image size bytes, just account for this heap area > > when identifying the mem_avoid ranges, and leave it out of the .bss > > section entirely. For good measure, also zero initialize it, as this > > was already happening for when zeroing the entire .bss section. > > I'm not sure I follow this: the reason the bzImage currently contains > .bss and a fix for it is in a patch I have out for review at > https://lore.kernel.org/lkml/20200109150218.16544-1-nivedita@alum.mit.edu Ah! Thank you. Yes, that's _much_ cleaner. I could not figure out why the linker was actually keeping the .bss section allocated in the on-disk image. :) We've only had this bug for 10 years. ;) > This alone shouldn't make much of a difference across compressors. The > entire .bss is just stored uncompressed as 0's in bzImage currently. > The only thing that gets compressed is the original kernel ELF file. Is > the difference above just from this patch, or is it including the > overhead of function-sections? With bzip2, it's a 4MB heap in .bss. Other compressors are 64KB. With fg-kaslr, the heap is 64MB in .bss. It made the bzImage huge. ;) Another thought I had to deal with the memory utilization in the fg-kaslr shuffle was to actually choose _two_ kernel locations in memory (via a refactoring of choose_random_location()). One to decompress into and the other to write out during the shuffle. Though the symbol table still needs to be reconstructed, etc, so probably just best to leave it all in the regular heap (or improve the ZO heap allocator which doesn't really implement free()). > It is not necessary for it to contain .bss to get the correct init_size. > The latter is calculated (in x86/boot/header.S) based on the offset of > the _end symbol in the compressed vmlinux, so storing the .bss is just a > bug. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/header.S#n559 Yes, thank you for the reminder. I couldn't find the ZO_INIT_SIZE when I was staring at this, since I only looked around the compressed/ directory. :) I should add this: diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c index d7408af55738..346e36ae163e 100644 --- a/arch/x86/boot/compressed/kaslr.c +++ b/arch/x86/boot/compressed/kaslr.c @@ -346,7 +346,7 @@ static void handle_mem_options(void) * in header.S, and the memory diagram is based on the one found in * misc.c. * * The following conditions are already enforced by the image layouts * and - * associated code: + * associated code (see ../boot/header.S): * - input + input_size >= output + output_size * - kernel_total_size <= init_size * - kernel_total_size <= output_size (see Note below) -- Kees Cook