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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3080AC433FE for ; Tue, 4 Oct 2022 04:04:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E1C96B0072; Tue, 4 Oct 2022 00:04:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 892086B0073; Tue, 4 Oct 2022 00:04:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 732556B0074; Tue, 4 Oct 2022 00:04:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5B30C6B0072 for ; Tue, 4 Oct 2022 00:04:03 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 29C801C6422 for ; Tue, 4 Oct 2022 04:04:03 +0000 (UTC) X-FDA: 79981923966.13.8A5F802 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf01.hostedemail.com (Postfix) with ESMTP id BD65940022 for ; Tue, 4 Oct 2022 04:04:02 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id e11-20020a17090a77cb00b00205edbfd646so17481966pjs.1 for ; Mon, 03 Oct 2022 21:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=RvEgKxP6T1qxqAkm7Unywj2tbhQw7Pjq7jdmWAsf7To=; b=hnk1iBSJ70l817ATL90p2KUf/st5w6VY728N6VYCOyE5NZEV0I5QKKoKHWaibjPaLq pZ9gLKLeXx+vt27FliXjO96UKvvr5+sDu4InpI2ML4eAI4ENY/Blyh0fLL7UN+z36Nq2 zID3qeceqlcQWqa226GaXwdViomNJnxxcfdR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=RvEgKxP6T1qxqAkm7Unywj2tbhQw7Pjq7jdmWAsf7To=; b=jqHdJf+K+eORmTO9/ioTr3vjAEapNuBWRt/kr7Yg6DR5Gi5hGtq6BzaVLh4TnfMziz 6KEtS2Nyu7f15IHzpnllYwhj2q8QFCsOdWW/uj5juvpZfKIKfp4X9RWrNoiIZFXFJtiz upCqehCtPYy8ubFZtGD6V9cVEQh7p4yBRfUqOLSrQUOF51T9TJY7O2j1Tt26Zn+DOyLG 3QIipUzXjbvC6Dgk/BFHIzuVkPu5WCnaWRt0NMgLl5vtKsQHGYZ9wzlCNZzZTLg6OaZV lGVf14L9AbowKWQ0YVZluTUtrvuEaFX6+EInbb4eSRoRW0sVAFEL0betx5sXRaGtxHkN 2cLw== X-Gm-Message-State: ACrzQf06aew1PckvuRKT02LyL5K8TgnBO90ILO8qQOrEBOPJ12GCiRgX WiVWtk3udeho8ZbtBXKW/T+9BQ== X-Google-Smtp-Source: AMsMyM7KdEI59H+iJ47/cAMFWwA0qEn0hsnOiP5znSBXMuB570wDOkrIO5UVg5W1BrAPa62Gu5h5tQ== X-Received: by 2002:a17:90b:4c41:b0:202:78e9:472b with SMTP id np1-20020a17090b4c4100b0020278e9472bmr15538866pjb.207.1664856241699; Mon, 03 Oct 2022 21:04:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id h8-20020a17090a604800b0020a9f7405aesm2572982pjm.13.2022.10.03.21.04.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 21:04:01 -0700 (PDT) Date: Mon, 3 Oct 2022 21:04:00 -0700 From: Kees Cook To: Dave Hansen Cc: Rick Edgecombe , 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 , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V . Shankar" , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, Yu-cheng Yu Subject: Re: [PATCH v2 24/39] x86/cet/shstk: Add user-mode shadow stack support Message-ID: <202210032101.A33914E4@keescook> References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-25-rick.p.edgecombe@intel.com> <202210031203.EB0DC0B7DD@keescook> <474d3aca-0cf0-8962-432b-77ac914cc563@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474d3aca-0cf0-8962-432b-77ac914cc563@intel.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664856242; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RvEgKxP6T1qxqAkm7Unywj2tbhQw7Pjq7jdmWAsf7To=; b=uGDoW5CX9hgQ6igIp4fFNfLly8y2Lt6cI5R8SyrAILZ1iSPNs9HMQKEo8+k86S9Jx43UDe Uyk9ZZ6g+zra0wDMOUXrVf35K3RFafs01JsZ5t3gSwXOJBCFVx4awaOJsjxWRthzqFpgzR 9AApkvbR5SqgM/y+m+S02G9KVYltqVs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hnk1iBSJ; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.54 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664856242; a=rsa-sha256; cv=none; b=p+phhx0j6Qg1yiGoIP8+Rgv6w1gDNnBx7P28vRoviRcGUz6LcVjkQCUVJd++IgScXCYFp0 bK2VK5IMmsPZ/STuspqgbkxcNoe00tCiXcdeCpTSZsdoPTn4conHgRecps5i3DAQ2VR7zw 3TUaOgSeiKkTn9z50+B85pQw+KbPHlw= X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hnk1iBSJ; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.54 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BD65940022 X-Stat-Signature: cs9pixpzza5cj43jy3kbr4rapunz8ard X-HE-Tag: 1664856242-350289 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 03, 2022 at 01:04:37PM -0700, Dave Hansen wrote: > On 10/3/22 12:43, Kees Cook wrote: > >> +static inline void set_clr_bits_msrl(u32 msr, u64 set, u64 clear) > >> +{ > >> + u64 val, new_val; > >> + > >> + rdmsrl(msr, val); > >> + new_val = (val & ~clear) | set; > >> + > >> + if (new_val != val) > >> + wrmsrl(msr, new_val); > >> +} > > I always get uncomfortable when I see these kinds of generalized helper > > functions for touching cpu bits, etc. It just begs for future attacker > > abuse to muck with arbitrary bits -- even marked inline there is a risk > > the compiler will ignore that in some circumstances (not as currently > > used in the code, but I'm imagining future changes leading to such a > > condition). Will you humor me and change this to a macro instead? That'll > > force it always inline (even __always_inline isn't always inline): > > Oh, are you thinking that this is dangerous because it's so surgical and > non-intrusive? It's even more powerful to an attacker than, say > wrmsrl(), because there they actually have to know what the existing > value is to update it. With this helper, it's quite easy to flip an > individual bit without disturbing the neighboring bits. > > Is that it? Yeah, it was kind of the combo: both a potential entry point to wrmsrl for arbitrary values, but also one where all the work is done to mask stuff out. > I don't _like_ the #defines, but doing one here doesn't seem too onerous > considering how critical MSRs are. I bet there are others, but this just weirded me out. I'll live with a macro, especially since the chance of it mutating in a non-inline is very small, but I figured I'd mention the idea. -- Kees Cook