Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2143349ybl; Thu, 30 Jan 2020 12:06:57 -0800 (PST) X-Google-Smtp-Source: APXvYqxQazomVgJWM3k7NrqlCQbapVur+twVGrE0ynORShr+/Bl1bmTNVJoJP4dCtMIaZ+uhQhuu X-Received: by 2002:aca:5fc6:: with SMTP id t189mr4148605oib.166.1580414817686; Thu, 30 Jan 2020 12:06:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580414817; cv=none; d=google.com; s=arc-20160816; b=VlAKUWYl3XvAIb3OByGOnmazRuxHhwDbtQ4LsEREzw+JdX6wId3rCQhDEjXbCAUMzD rwI5j0mo2J4reR/b/E+hcYNS+kvJzXIglYeZKLpxAqBOdUWMKQfRwFssHKpiMDq9LHTt 0xu29zY4B73+GP15fVAV1TdHPtfA5BJcR+41nBcE/bpNzAVfzH7FV31HzS4oU6sneBUx EDLxPRPgAFVmTPmlCtVUaaf5wGDpqjyKYHqYmY1+UvuTHcIRGbnnzGyanaiZ9de9WZEo HXiIzRSTuex6ppy5VkH3SoOGQt2O5sJbhP66ShXURjolCUTA4JbdEZjDcbe46ijsqwK2 835g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=94xgiZ2GumdGMWJPAkQ3lyvxruP/ROGgeixLfGHw8Ow=; b=rF4wfkOu15PeEfZha+g62DIYE8syxe+qqgXY0oFDiws4WkluXBq5906jN4RocbuOwc 9qG6gJEylJ6ZczGzhd8eq+96fiCDOw79kXHuel61M8Og/9uCnZSJyYVnCwHiKb1NqIut AguqYJy1rsPxQ3nWF1pVVx1IHERK3fl3zI7zZlrouIpyNBnKQ1WoLJDGU04aZ6MTf1zf E6MxYAK7uXehpaB3GWl19qGTVpD+EeFvljSvvrFIe6/0uHJ5Mvr09r1GVtc1gTCnML5L D0sQMja5fmERxo0R8UnpnjEoi1Qgqg9Bq7HLKA0ZPjj7IYhlVhDF6PGPTAUjTMvgzAo8 0I0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EiDoJLVi; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si3079548oij.139.2020.01.30.12.06.45; Thu, 30 Jan 2020 12:06:57 -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=@gmail.com header.s=20161025 header.b=EiDoJLVi; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727558AbgA3UFc (ORCPT + 99 others); Thu, 30 Jan 2020 15:05:32 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:40742 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727089AbgA3UFb (ORCPT ); Thu, 30 Jan 2020 15:05:31 -0500 Received: by mail-oi1-f196.google.com with SMTP id a142so4888968oii.7 for ; Thu, 30 Jan 2020 12:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=94xgiZ2GumdGMWJPAkQ3lyvxruP/ROGgeixLfGHw8Ow=; b=EiDoJLViz5lUKkMfgtBo8x5JnS7D+OdkBhGRwWBdINZjG2IGt2XkWeAnHNpgBuUi5e +qAfzqN8IdhbxK/50JNcYwaSo+9mJ9BVi9jw+XsV0hjKstwSsTSSF2Xjv7Jyci+kp6DJ LpVxgaDXdnf5qntrp9/i2qcKJc2bAn2oLFD4zHdnzQmvOHlzbqAVY0ilMBHpoxPCvUxs hl30zg1wsxT8yKMOr5CZvPT7b4mKV3MjARh6A1cq3eh6kEG+W9CSZcNdwgoygeMP0usu iNbtD52IJSZ2KxFtmH7gTnYd3+m0vizDKMHpV2WYwmcYyitgswhnvKza5hwsKCg1XRAC RrTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=94xgiZ2GumdGMWJPAkQ3lyvxruP/ROGgeixLfGHw8Ow=; b=qDiad1V3gO87tcItaGpinS9+GFGHhluqLdEt2EIWWv1SyzXV9iOQIV4mEDny3OuqoS X1cuqTjI7axitSgT243ZSVDinXcgwtAuY/9P7l5AEtzfO8aHA3DBKc9fEWmXmXkWOnr5 CZKLvEYg3KStWM2JnJioTitnT/LrF/drG5WDTJDh2c5WKjtW7T2FGsVXC4aFbEtEaNeB KDfMNZ6+8tqyEo14nyH0sFLO1FVIiXQHI80eO4v4bQMtcKrAsC9A0MpVQR6I5KQg2G6b tp1WQDBlsI70qs3FNQcUZOctzdV2VLn2F4t+RcCNb8i31I57B1NqzD7BjvK96td/x8WX 83aw== X-Gm-Message-State: APjAAAUxGRpSQKzPWa9YibLGmGmrzWkZNkgntioDD7Xqi1mO16vM66cG Ig4E6hGbyApe0XrrGWGcG6viGmm07XzpnxgM2AM= X-Received: by 2002:aca:1b17:: with SMTP id b23mr2344068oib.95.1580414730517; Thu, 30 Jan 2020 12:05:30 -0800 (PST) MIME-Version: 1.0 References: <20200124181819.4840-1-hjl.tools@gmail.com> <20200124181819.4840-3-hjl.tools@gmail.com> <202001271531.B9ACE2A@keescook> <202001301143.288B55DCC1@keescook> In-Reply-To: <202001301143.288B55DCC1@keescook> From: "H.J. Lu" Date: Thu, 30 Jan 2020 12:04:54 -0800 Message-ID: Subject: Re: [PATCH 2/2] x86: Discard .note.gnu.property sections in vmlinux To: Kees Cook Cc: LKML , Andy Lutomirski , Thomas Gleixner , Thomas Lendacky , Sami Tolvanen , Heiko Carstens , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , "the arch/x86 maintainers" , Yu-cheng Yu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 30, 2020 at 11:51 AM Kees Cook wrote: > > On Thu, Jan 30, 2020 at 09:51:38AM -0800, H.J. Lu wrote: > > On Mon, Jan 27, 2020 at 3:34 PM Kees Cook wrote: > > > > > > On Fri, Jan 24, 2020 at 10:18:19AM -0800, H.J. Lu wrote: > > > > With the command-line option, -mx86-used-note=yes, the x86 assembler > > > > in binutils 2.32 and above generates a program property note in a note > > > > section, .note.gnu.property, to encode used x86 ISAs and features. > > > > But x86 kernel linker script only contains a signle NOTE segment: > > > > > > > > PHDRS { > > > > text PT_LOAD FLAGS(5); > > > > data PT_LOAD FLAGS(6); > > > > percpu PT_LOAD FLAGS(6); > > > > init PT_LOAD FLAGS(7); > > > > note PT_NOTE FLAGS(0); > > > > } > > > > SECTIONS > > > > { > > > > ... > > > > .notes : AT(ADDR(.notes) - 0xffffffff80000000) { __start_notes = .; KEEP(*(.not > > > > e.*)) __stop_notes = .; } :text :note > > > > ... > > > > } > > > > > > > > which may not be incompatible with note.gnu.property sections. Since > > I don't understand this. "may not be incompatible"? Is there an error > generated? If so, what does it look like? When -mx86-used-note=yes is passed to assembler, with my patch, I got [hjl@gnu-skx-1 linux]$ readelf -n vmlinux Displaying notes found in: .notes Owner Data size Description Xen 0x00000006 Unknown note type: (0x00000006) description data: 6c 69 6e 75 78 00 Xen 0x00000004 Unknown note type: (0x00000007) description data: 32 2e 36 00 Xen 0x00000008 Unknown note type: (0x00000005) description data: 78 65 6e 2d 33 2e 30 00 Xen 0x00000008 Unknown note type: (0x00000003) description data: 00 00 00 80 ff ff ff ff Xen 0x00000008 Unknown note type: (0x0000000f) description data: 00 00 00 00 80 00 00 00 Xen 0x00000008 NT_VERSION (version) description data: 80 a1 ba 82 ff ff ff ff Xen 0x00000008 NT_ARCH (architecture) description data: 00 10 00 81 ff ff ff ff Xen 0x00000029 Unknown note type: (0x0000000a) description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62 Xen 0x00000004 Unknown note type: (0x00000011) description data: 01 88 00 00 Xen 0x00000004 Unknown note type: (0x00000009) description data: 79 65 73 00 Xen 0x00000008 Unknown note type: (0x00000008) description data: 67 65 6e 65 72 69 63 00 Xen 0x00000010 Unknown note type: (0x0000000d) description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 Xen 0x00000004 Unknown note type: (0x0000000e) description data: 01 00 00 00 Xen 0x00000004 Unknown note type: (0x00000010) description data: 01 00 00 00 Xen 0x00000008 Unknown note type: (0x0000000c) description data: 00 00 00 00 00 80 ff ff Xen 0x00000008 Unknown note type: (0x00000004) description data: 00 00 00 00 00 00 00 00 GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 11c73de2922f593e1b35b92ab3c70eaa1a80fa83 Linux 0x00000018 OPEN description data: 35 2e 33 2e 39 2d 32 30 30 2e 30 2e 66 63 33 30 2e 78 38 36 5f 36 34 00 Xen 0x00000008 Unknown note type: (0x00000012) description data: 70 04 00 01 00 00 00 00 [hjl@gnu-skx-1 linux]$ Without my patch, [hjl@gnu-skx-1 linux]$ readelf -n vmlinux Displaying notes found in: .notes Owner Data size Description Xen 0x00000006 Unknown note type: (0x00000006) description data: 6c 69 6e 75 78 00 Xen 0x00000004 Unknown note type: (0x00000007) description data: 32 2e 36 00 xen-3.0 0x00000005 Unknown note type: (0x006e6558) description data: 08 00 00 00 03 readelf: Warning: note with invalid namesz and/or descsz found at offset 0x50 readelf: Warning: type: 0xffffffff, namesize: 0x006e6558, descsize: 0x80000000, alignment: 8 [hjl@gnu-skx-1 linux]$ > > > > note.gnu.property section in kernel image is unused, this patch discards > > > > .note.gnu.property sections in kernel linker script by adding > > > > > > > > /DISCARD/ : { > > > > *(.note.gnu.property) > > > > } > > > > > > I think this is happening in the wrong place? Shouldn't this be in the > > > DISCARDS macro in include/asm-generic/vmlinux.lds.h instead? > > > > Please read my commit message closely. We can't discard .note.gnu.property > > sections by adding .note.gnu.property to default discarded sections > > since default > > discarded sections are placed AFTER .notes sections in x86 kernel > > linker scripts. > > I see what you mean now, /DISCARD/ happens after the NOTES macro (now in > the RO_DATA macro). To this end, I think this should be in > include/asm-generic/vmlinux.lds.h in the NOTES macro? It's x86-specific > right now, but why not make this future-proof? I am trying to avoid touching generic parts. I will give it a try. > I'd like to avoid as much arch-specific linker stuff as we can. I spent > a lot of time trying to clean up NOTES specifically. :) > > > + /* .note.gnu.property sections should be discarded */ > > This comment should say _why_ -- the script already shows _what_ is > happening... I will update comments. > > + /DISCARD/ : { > > + *(.note.gnu.property) > > + } > Thanks. -- H.J.