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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5221C468BC for ; Fri, 7 Jun 2019 20:40:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 778AD212F5 for ; Fri, 7 Jun 2019 20:40:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="xrvdgiwg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730307AbfFGUkK (ORCPT ); Fri, 7 Jun 2019 16:40:10 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:34688 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729677AbfFGUkJ (ORCPT ); Fri, 7 Jun 2019 16:40:09 -0400 Received: by mail-pg1-f195.google.com with SMTP id h2so1753289pgg.1 for ; Fri, 07 Jun 2019 13:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/zXZ0PAO7hrTuftMmJADCccAFJNVvLuJoT5zW483dm4=; b=xrvdgiwgMy+n6sUxDDjF6GbcFmqZ9IbL4LqbaOlUjeE8uqFUu4xLwLCn5TySJGkcHl fXPiABlcfNSCw9bl0NwfmBnfApC4fAM1xXXJDZ27D9KyYVvW3Pd4X+nasECUMC2LBZEJ fKA5BQIw1BcsTounoXppfOwxaeXfpEVX0HyHm3x1KFjINzS4PCb6c6IaljqNaSCBm7Od drrmRGWCxY710x1mQlxy/KRBEo0C1hie/MUbVm5jM/+AlavFNb6N+fUr8V+MNbUOPbuC xC4rbQBCWUzb43kM79GQ/pk24o4zNJi31I1dPZeQMzNZkLkM+wXFQ8x1bMx3nK65vvQb mnNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/zXZ0PAO7hrTuftMmJADCccAFJNVvLuJoT5zW483dm4=; b=ZVqfFEdlWyJdLHg/zgBcbnBWrWdM4taZhCddPhDT5GiwaphYbTvi/0gP+NZe0nGo7i YKD+JZLimlZqqELZJ3NmuLwdYbMjdYYfo3JyTEWfzUVFgk7nQzj2kGTlelCpsz+uZg1N nVw+I6fjPnl8+rlaYWt4UhOsauWxawqCosSlU6xM+2dZjty0Mj6u6oBiQeqgYybsEFnw 7FgR4egV5X1W9AzOErG94E1wZA6Sng6QKtk24LCAwxvWU6htKmk7MWGjoaJ0C8XoFCui //MOP/qQM1okpHD7mqxFXbmd7GPxzHT9e5kCKBfnHp8c/iZ/ax8Uw1gBwursDAZzBw+9 ueow== X-Gm-Message-State: APjAAAX7mq7SPwNHHjy+/cq/0VzotjFcEAIA7bqvB39F0VXMM5PgJ2KM rzQ23bvwx0LUmcLrSY+be0aVyw== X-Google-Smtp-Source: APXvYqw9CMgTx+uPCBp2eShznieLWxzWHpVNj71rqNoWul6wN77odT5+ocrO71ob0NcUvASo3obsmg== X-Received: by 2002:a63:490a:: with SMTP id w10mr4721938pga.6.1559940008694; Fri, 07 Jun 2019 13:40:08 -0700 (PDT) Received: from ?IPv6:2600:1012:b044:6f30:60ea:7662:8055:2cca? ([2600:1012:b044:6f30:60ea:7662:8055:2cca]) by smtp.gmail.com with ESMTPSA id 128sm3433146pff.16.2019.06.07.13.40.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 13:40:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function From: Andy Lutomirski X-Mailer: iPhone Mail (16F203) In-Reply-To: <352e6172-938d-f8e4-c195-9fd1b881bdee@intel.com> Date: Fri, 7 Jun 2019 13:40:06 -0700 Cc: Peter Zijlstra , Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <20190606200926.4029-4-yu-cheng.yu@intel.com> <20190607080832.GT3419@hirez.programming.kicks-ass.net> <20190607174336.GM3436@hirez.programming.kicks-ass.net> <34E0D316-552A-401C-ABAA-5584B5BC98C5@amacapital.net> <352e6172-938d-f8e4-c195-9fd1b881bdee@intel.com> To: Dave Hansen Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jun 7, 2019, at 11:58 AM, Dave Hansen wrote: >=20 > On 6/7/19 11:29 AM, Andy Lutomirski wrote: > ... >>> I think this new MSR probably needs to get included in oops output when >>> CET is enabled. >>=20 >> This shouldn=E2=80=99t be able to OOPS because it only happens at CPL 3, >> right? We should put it into core dumps, though. >=20 > Good point. >=20 > Yu-cheng, can you just confirm that the bitmap can't be referenced in > ring-0, no matter what? We should also make sure that no funny business > happens if we put an address in the bitmap that faults, or is > non-canonical. Do we have any self-tests for that? >=20 > Let's say userspace gets a fault on this. Do they have the > introspection capability to figure out why they faulted, say in their > signal handler? We need to stick the tracker state in the sigcontext somewhere. Did we end up defining a signal frame shadow stack token? >=20 >>> Why don't we require that a VMA be in place for the entire bitmap? >>> Don't we need a "get" prctl function too in case something like a JIT is= >>> running and needs to find the location of this bitmap to set bits itself= ? >>>=20 >>> Or, do we just go whole-hog and have the kernel manage the bitmap >>> itself. Our interface here could be: >>>=20 >>> prctl(PR_MARK_CODE_AS_LEGACY, start, size); >>>=20 >>> and then have the kernel allocate and set the bitmap for those code >>> locations. >>=20 >> Given that the format depends on the VA size, this might be a good >> idea. >=20 > Yeah, making userspace know how large the address space is or could be > is rather nasty, especially if we ever get any fancy CPU features that > eat up address bits (a la ARM top-byte-ignore or SPARC ADI). That gets extra bad if we ever grow user code that uses it but is unaware. I= t could poke the wrong part of the bitmap. >=20 >> Hmm. Can we be creative and skip populating it with zeros? The CPU > should only ever touch a page if we miss an ENDBR on it, so, in normal > operation, we don=E2=80=99t need anything to be there. We could try to pr= event > anyone from *reading* it outside of ENDBR tracking if we want to avoid > people accidentally wasting lots of memory by forcing it to be fully > populated when the read it. >=20 > Won't reads on a big, contiguous private mapping get the huge zero page > anyway? The zero pages may be free, but the page tables could be decently large. Do= es the core mm code use huge, immense, etc huge zero pages? Or can it synth= esize them by reusing page table pages that map zeros? >=20 >> The one downside is this forces it to be per-mm, but that seems like >> a generally reasonable model anyway. >=20 > Yeah, practically, you could only make it shared if you shared the > layout of all code in the address space. I'm sure the big database(s) > do that cross-process, but I bet nobody else does. User ASLR > practically guarantees that nobody can do this. I meant per-mm instead of per-task.