Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1617192ybf; Thu, 27 Feb 2020 14:36:09 -0800 (PST) X-Google-Smtp-Source: APXvYqzcfQytZtLpX3S6C5qtFxYP1nJ7Td5/gtd9afI3trBAQB9vG2j7DTMBIp69eD1lvSnf7/qn X-Received: by 2002:aca:44f:: with SMTP id 76mr144983oie.23.1582842969732; Thu, 27 Feb 2020 14:36:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582842969; cv=none; d=google.com; s=arc-20160816; b=yJ7BkRrm7Sccm/TU0sLMMapBQiQbmUPRFbKXDAAQuGttXJR4eSD0Ka3V1hfFKo1CSU NW0o977lc6CqfzVeu9lINQCn5WQRxFnb78Nynv78b82oNstl1w63iC3xG7XCMdFSTsYn Bmy53IVXmhAXszf4DC9R4lt/WuVoqEmBL0NzY2JLrNLCZWIhICj1ASxUdYxI0I4AJz/8 9bfJQ4SbBIl/B1Cm/7Pc0xmO/7YsyHpLHjAWC2ASOxuXH+O+MDKmSjE6tzwxVvrr8WKy 4mFGw47cMzsds991/rGXjSZFmOmgrJ+5gE7dl5F4e9NpVGVyAuTbTfNNjhFEXJepcvyC oBTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=oeSys58fhSXCrQfOvMfdoUQFTBoe5ekG62jeNkRbf3M=; b=Z4t+uLXuzr4IoD7No7l1eIaSLfrqo4KA+vR9A8y2LXoXnCgGxs5eXqFx177jL898+L wgbIQoEDbgoOB7qql2g0QkYMhMvDQe/rw8LRd7WhR6gV1a5wDUrxNvd+Tb/oPKLwJDcM yoM87cRggBUml3+7PcMFIUTn4uiyW2DnD+Qhk9klKWzyWnYrjX4FRkl/BpvPKfoLEpI8 W1cTlaQ4t8vOuXWFRmYGjCg1E8NNRrKJ6S44Dh2KwVIzcSiAFK8DDRo0k0+DYrH0xhrS tD0LMsqU5ErOppesVDNwVVSobvPxxIUgJUqCqSEnJ1e3Lwm8LiVMQk1wQpfjhl56DdLU zJUA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l14si417544otk.225.2020.02.27.14.35.57; Thu, 27 Feb 2020 14:36:09 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730435AbgB0Wft (ORCPT + 99 others); Thu, 27 Feb 2020 17:35:49 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:49428 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729955AbgB0Wft (ORCPT ); Thu, 27 Feb 2020 17:35:49 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j7Rks-0025iX-U0; Thu, 27 Feb 2020 22:35:43 +0000 Date: Thu, 27 Feb 2020 22:35:42 +0000 From: Al Viro To: Josh Poimboeuf Cc: Chris Wilson , linux-kernel@vger.kernel.org, Randy Dunlap , Peter Zijlstra , intel-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl() Message-ID: <20200227223542.GE23230@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 27, 2020 at 04:08:26PM -0600, Josh Poimboeuf wrote: > With CONFIG_CC_OPTIMIZE_FOR_SIZE, objtool reports: > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x5b7: call to gen8_canonical_addr() with UACCESS enabled > > This means i915_gem_execbuffer2_ioctl() is calling gen8_canonical_addr() > -- and indirectly, sign_extend64() -- from the user_access_begin/end > critical region (i.e, with SMAP disabled). > > While it's probably harmless in this case, in general we like to avoid > extra function calls in SMAP-disabled regions because it can open up > inadvertent security holes. > > Fix it by moving the gen8_canonical_addr() conversion to a separate loop > before user_access_begin() is called. > > Note that gen8_canonical_addr() is now called *before* masking off the > PIN_OFFSET_MASK bits. That should be ok because it just does a sign > extension and ignores the masked lower bits anyway. How painful would it be to inline the damn thing? static inline u64 gen8_canonical_addr(u64 address) { return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT); } static inline __s64 sign_extend64(__u64 value, int index) { __u8 shift = 63 - index; return (__s64)(value << shift) >> shift; } What the hell? Josh, what kind of .config do you have that these are _not_ inlined? And why not mark gen8_canonical_addr() __always_inline?