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 E84F8C433F5 for ; Mon, 3 Oct 2022 20:04:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A13D8E0001; Mon, 3 Oct 2022 16:04:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 551A96B0073; Mon, 3 Oct 2022 16:04:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F1C68E0001; Mon, 3 Oct 2022 16:04:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 295CB6B0071 for ; Mon, 3 Oct 2022 16:04:44 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EC5D9AB14E for ; Mon, 3 Oct 2022 20:04:43 +0000 (UTC) X-FDA: 79980716046.15.EB824AA Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf19.hostedemail.com (Postfix) with ESMTP id 744961A000F for ; Mon, 3 Oct 2022 20:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664827482; x=1696363482; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Y6lmOQaQb09t80GLATBzGHheq+H668G2htPXwlOpJUk=; b=NButL9KuAzhqgaloE5SspA9w7wC/UE8meEqGfvmQuI9QRcHUVcPFYJD7 QriuSbgxJgsoIFVHq8sJ6a3DKk+oAMm/lGIAA2koo44D0gZdqSa6Q015z RWRmimSuBHeD1uCakdQ2SFmtwj5QkBB20CDX2nlrcHg8DAFG/Hdy1qbB8 zzgFt94DHc+9V1vavwkwfBgBSo+oFVfiQ0fG5rUwxZz1qOoiEGAetGDKU zNXabBRdJlcSrm4s9Gjsy7IDonb6KRP+61UV3PX5f0OtxCUVOGv4/IcQL MCldUX4Bv1RSKpkeF2hAMBKKKI0LDkp8xDLmdRkzV5+FJYsWjMXhSeP4Y A==; X-IronPort-AV: E=McAfee;i="6500,9779,10489"; a="289966692" X-IronPort-AV: E=Sophos;i="5.93,366,1654585200"; d="scan'208";a="289966692" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2022 13:04:40 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10489"; a="686277425" X-IronPort-AV: E=Sophos;i="5.93,366,1654585200"; d="scan'208";a="686277425" Received: from akashred-mobl.amr.corp.intel.com (HELO [10.212.139.217]) ([10.212.139.217]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2022 13:04:37 -0700 Message-ID: <474d3aca-0cf0-8962-432b-77ac914cc563@intel.com> Date: Mon, 3 Oct 2022 13:04:37 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2 24/39] x86/cet/shstk: Add user-mode shadow stack support Content-Language: en-US To: Kees Cook , Rick Edgecombe Cc: 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 References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-25-rick.p.edgecombe@intel.com> <202210031203.EB0DC0B7DD@keescook> From: Dave Hansen In-Reply-To: <202210031203.EB0DC0B7DD@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664827483; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BvWTLMOe+dFpQqXTCYNNVd+G5vsIfW4iea/7QDWTTrc=; b=xYGJTj1p7oYwReXtsbLawK3R9ecctPq4L8psNxcKSBXoavm4sFNvnjlOrd25OeYOG2xWId M7F9rRvdFEtLUxLpVoDA4EBtiIA5v4LWNUoEPFkJ/PKtOakRpJtCyJG+lRehWEO1k9wk16 KlY/KJuWQkCH/58UbDYRQ+ekjvssAMk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=NButL9Ku; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664827483; a=rsa-sha256; cv=none; b=HbZ3MOcY3v2fzfzSTDWM0fjZRqxGC2rH9Q8KKsnNpPL0GkaRiwY5ugeX9Ye0+NQwXsagZC JTq47IL2SJUUENHz0BUvVbX8RIHbarNKMhfYPSz/DGV4u2cjcvHmlFi0WnWuy6CGOKUWwp 83AygnAte7SluxKlV0cuhbx/T904DzM= Authentication-Results: imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=NButL9Ku; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 744961A000F X-Rspam-User: X-Stat-Signature: ukfwxp63wstq7ussa7e1ctys9dbu59xa X-HE-Tag: 1664827482-483067 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 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? I don't _like_ the #defines, but doing one here doesn't seem too onerous considering how critical MSRs are.