Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp23808imu; Thu, 10 Jan 2019 17:08:06 -0800 (PST) X-Google-Smtp-Source: ALg8bN4qzAT/u17E21Mg611OMKhkNV9FX4D3q4RFvQ+KMq6G+7deNuz5eViEjwcxAzkmaaejugH0 X-Received: by 2002:a62:d701:: with SMTP id b1mr12271066pfh.34.1547168886914; Thu, 10 Jan 2019 17:08:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547168886; cv=none; d=google.com; s=arc-20160816; b=zWwesV63Nr0EcorcMpiPc0U72xaPlleRd2LSKiylrka4xNr9/MXd5Iz3yA9A7RY7qk 91DncPtg3kjyvRz2XIlhMIWqZ0Foj18rApTC3nbSPDphQPXxu4F9suOVXqgWlNcCdewG zr+2nu9pWUWvg0rrEY03R9fhKtmEr4MsRvbh1US1raNR10Xd68qGFbDUTAm9R7b4ynuu bxRrHQfNsZ4Qvbpu/zKoAzqmMN7KK2lEEYYXMi2pzh4b13jdM+sJeldhsd4YDUe3Yb2a dzSsy7lV925bhUdCQhjeUSs6LilC3y4O+1MLB7cl6EjBZ6DFkgm04LDR/X2bQJ6viKhS SnVw== 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=Tvjyq81y2cn2t5gUg7evHnCajt4PsaUlEBWZtz7lrsA=; b=t25Vy1yckCDyw2Gr7IOC5k508eQ8S2TLZlSnNFU8fbCpNu4xwXfWqLAPUufV+sn95g pTKgLNf/iaGaT1ySBvU1Z4BxjEkQ98F1NpKrW+uV3f6731acQMdDExwohKVeea9SLuUM owG40uP4boTPLsThTta+hwop46vymJSyKDdWpOmQ/hwDCP562wK3hoq8oeotYVzpAZBF zi7GCaeh0tvu2Y0mtrzL4SwMwE0Sb7yfD0Y7sWGVzkhbnrYKFOd45xDFg0jNSIhY/xMG fPKzp1RJ1Ms38VW5FNYFXLgvo3D8JEZjsNxBZGDM6E9/H61bjsJaQzPvlGM222bhni7k FERw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=K20Ar9ZX; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si52760172pfm.71.2019.01.10.17.07.50; Thu, 10 Jan 2019 17:08:06 -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=@kernel.org header.s=default header.b=K20Ar9ZX; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729232AbfAKA4S (ORCPT + 99 others); Thu, 10 Jan 2019 19:56:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:40690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727401AbfAKA4S (ORCPT ); Thu, 10 Jan 2019 19:56:18 -0500 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 876932183F for ; Fri, 11 Jan 2019 00:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547168176; bh=xasxS/8z9Dmxu4txV11KFeQOiTthQE5c/dGewPZVGbE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=K20Ar9ZX/UwR4X3iPBf4/F6qFeTtXl4GKr/tO0cdFhiGRotg32nzkXik+kbjhnriQ X/pRmRK28Y3hfJ8PW9HWwtrYgWGvHU8efnuWNpLzbG121nopVt4yQSt85FRluBawQ7 Yf+i1Qy/VHgRG125Mq6s9Ch7j8BpHovLBLIfucwE= Received: by mail-wr1-f48.google.com with SMTP id t27so13419694wra.6 for ; Thu, 10 Jan 2019 16:56:16 -0800 (PST) X-Gm-Message-State: AJcUukfxlLJRW2GWsQHZHgI6JA6rzIEckqzAJxkyybMBz6Mq0Z5Qi0d+ UfbcOTzqBVbSAxklKq+k2CaHVudMZfjmxtcceMyv1g== X-Received: by 2002:adf:e08c:: with SMTP id c12mr10786034wri.199.1547168174960; Thu, 10 Jan 2019 16:56:14 -0800 (PST) MIME-Version: 1.0 References: <20190110203023.GL2861@worktop.programming.kicks-ass.net> <20190110205226.iburt6mrddsxnjpk@treble> In-Reply-To: From: Andy Lutomirski Date: Thu, 10 Jan 2019 16:56:02 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/6] Static calls To: Linus Torvalds Cc: Josh Poimboeuf , Peter Zijlstra , "the arch/x86 maintainers" , Linux List Kernel Mailing , Ard Biesheuvel , Andy Lutomirski , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Nadav Amit , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira 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 10, 2019 at 3:02 PM Linus Torvalds wrote: > > On Thu, Jan 10, 2019 at 12:52 PM Josh Poimboeuf wrote: > > > > Right, emulating a call instruction from the #BP handler is ugly, > > because you have to somehow grow the stack to make room for the return > > address. Personally I liked the idea of shifting the iret frame by 16 > > bytes in the #DB entry code, but others hated it. > > Yeah, I hated it. > > But I'm starting to think it's the simplest solution. > > So still not loving it, but all the other models have had huge issues too. > Putting my maintainer hat on: I'm okay-ish with shifting the stack by 16 bytes. If this is done, I want an assertion in do_int3() or wherever the fixup happens that the write isn't overlapping pt_regs (which is easy to implement because that code has the relevant pt_regs pointer). And I want some code that explicitly triggers the fixup when a CONFIG_DEBUG_ENTRY=y or similar kernel is built so that this whole mess actually gets exercised. Because the fixup only happens when a really-quite-improbable race gets hit, and the issues depend on stack alignment, which is presumably why Josh was able to submit a buggy series without noticing. BUT: this is going to be utterly gross whenever anyone tries to implement shadow stacks for the kernel, and we might need to switch to a longjmp-like approach if that happens. --Andy