Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp941461ybt; Wed, 1 Jul 2020 14:06:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyd7wixRoYbiVOjaotMNm3m129yLRNEJR0z4PR3SS+mJGDAfdkPVuVS6MNEU90S792AAXYL X-Received: by 2002:aa7:c714:: with SMTP id i20mr31749245edq.215.1593637583768; Wed, 01 Jul 2020 14:06:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593637583; cv=none; d=google.com; s=arc-20160816; b=GhYchCJKj4BhtigbOFkGIUtjOyvF6j+VquyucA+rvdFDnUbZr59qJCshC2Jz2NOTkX 7wZfKiJULns5Y3miNN3TZBFS/shBFtNgTjyoMAmY92ljd+ZZRb070BKvvwNl4hS9gyiU LyzgKJBZxWHkABLYXMKuQqpU92Wp98BgnPhSTwHZYNEbvTtJhPPFziHmSsGeRgU2uI31 2mPJwqS7nav6ehevgsrF1uD/0grX/rbTgjwqYWat0mbjGvqW42klhoK+HYUL53SEdLdz /Qdm6fa4UdJUgoILAVyfvbDgSLK7c33brl9M0t1lMCkxeFSAf3oySbWS9VzQgV5Ta3jR E4Rg== 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=DJJQ0JuSWbNincDMm+mwtyZQMnCdEroZXX8CnDea68I=; b=G3FyqJuaxQ5DgLSe/nPDyjI0Lbcq3JyWd4cS11PUERDbURDtyTW2i5TvywtzqZEGEi ShIk098lWN6Ze6Jy/05Zojj+vaeErvfb+2LypHoxYLlYtn0PSUtpRivmTkGO/i4D1kdj ZjGgfvcrB5B4xWzGXJDZiuQg5EtTaRq8wBtySKtl7ZpdWmgL17cCeP1ZaAvDl3jy1OwU k8dKFi6tSDsUrp6Rfure5wl1d45tbM21STOx6nfmc/w+16y6NF804UZ4ozY/7FA8F1fb OVvfls/9hDqzGtD3B+Ksfc+poAXOGgvx8fVDQEaAAN5p4UCtr5sS432ri26dO92qflqE FaNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=gZ8TD+jn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id br6si4485275ejb.203.2020.07.01.14.06.00; Wed, 01 Jul 2020 14:06:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=gZ8TD+jn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727101AbgGAVDC (ORCPT + 99 others); Wed, 1 Jul 2020 17:03:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726441AbgGAVDC (ORCPT ); Wed, 1 Jul 2020 17:03:02 -0400 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA716C08C5C1 for ; Wed, 1 Jul 2020 14:03:01 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t25so24327666lji.12 for ; Wed, 01 Jul 2020 14:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJJQ0JuSWbNincDMm+mwtyZQMnCdEroZXX8CnDea68I=; b=gZ8TD+jnU7OaD3x3gkybCeHrYMmT6lBf9QwEBW7+9DFLrbf4hlFHHJJHNCDWMDKt9O sqy39UJQbL13e7j9qdt/YVfX3zmsz9bdW9dqOW6xdFcJugF9ujGAHU91OUIRJKiiaD0+ cHqU1KIT5fVviHAZ90mmMkvOVj7MOn+ogU+eI= 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=DJJQ0JuSWbNincDMm+mwtyZQMnCdEroZXX8CnDea68I=; b=CHJJ2qpbsvo6BnKVmA56rt9Iu/EH6pVvUa14TmWd6rR2jm+9Gb3z6q8W6qqkz7m9v5 3rjGN+FT+E6FJ3MU34iKYJXof3z1wkuKi+DLZQFqTziTTSX2x2o1Fr/+lm9iweWEntR7 V+c1OhaUkuQaZjdfsjhfC8QQnhYTlN89llC0tUWijOW9aY2IZKzd0W5CGxGacFXoxwTK UazTMSAD2LUXwBUTaABmXJFxJzUOMTbJAw9Oebddb+P5w2Yv8DkRJKiRKHUn9lQJYLmq 7eK0DSJyBnliqqnclN2GZ5A5ThbqbYLUDTNvDq5BPljjTaObNMwEjzXDDVjO+Fyf1ocW EWlA== X-Gm-Message-State: AOAM533JemgQWkcyO30PrfMelT6DEHHqyI4uXJwieKEPPbaSjdtimWvW a0sWtkukM149EqiE3/sl80dTUshYTQw= X-Received: by 2002:a2e:9855:: with SMTP id e21mr9877796ljj.424.1593637379763; Wed, 01 Jul 2020 14:02:59 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id 2sm2445032lfr.48.2020.07.01.14.02.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2020 14:02:58 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id h22so21758484lji.9 for ; Wed, 01 Jul 2020 14:02:58 -0700 (PDT) X-Received: by 2002:a2e:97c3:: with SMTP id m3mr15024788ljj.312.1593637378147; Wed, 01 Jul 2020 14:02:58 -0700 (PDT) MIME-Version: 1.0 References: <5F1767D0-416A-4BA4-9DFF-E82D1EA3F5EE@amacapital.net> <20200701205108.wtgfnijav7lgfiqe@treble> In-Reply-To: <20200701205108.wtgfnijav7lgfiqe@treble> From: Linus Torvalds Date: Wed, 1 Jul 2020 14:02:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: objtool clac/stac handling change.. To: Josh Poimboeuf Cc: Andy Lutomirski , Andy Lutomirski , Peter Zijlstra , "the arch/x86 maintainers" , Linux Kernel Mailing List 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 Wed, Jul 1, 2020 at 1:51 PM Josh Poimboeuf wrote: > > Yeah. Peter's more of the expert here, but I think we'd at least need > to annotate the code which expects an implicit CLAC so objtool knows > what to expect. It's not trivial, but it might be doable. In both C and asm code, it's the "_ASM_EXTABLE_UA" cases that would do this ("UA" being for "User Access"). In fact, it should be quite easy to see: the thing that distinguishes those things is that the exception handler is "ex_handler_uaccess". So objtool should be able to see that quite easily as it follows the exception tables. It's a special case for entirely unrelated reasons (reasons objtool doesn't care about): a user access exception can be either due to a page fault (normal) or due to a misformed non-canonical address, and we warn about the latter case. That said, I wouldn't necessarily object to making the rule be that *any* exception handler invocation will always do the user_access_end(). It sounds dangerous/wrong to me to do anything that can fault (other than the user access itself, of course) within a STAC/CLAC region. So the objtool rule might be: - in a STAC region, no exception handlers at all except for that ex_handler_uaccess case - and that case will clear AC if it triggers. and maybe such an objtool check would show some case where I'm wrong, and we do some MSR read other other fault thing within a STAC region. That _sounds_ wrong to me, but maybe we have reason to do so that I just can't think or right now? Linus