Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp897317ybg; Wed, 29 Jul 2020 00:02:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMgfATVM4e4UmSYuHq0N7Hj1qx6syAFWDMZsK36Mz0aymE7pj51EDAj/x/T5hLwduRVj81 X-Received: by 2002:a17:907:4303:: with SMTP id nh3mr11747066ejb.520.1596006178797; Wed, 29 Jul 2020 00:02:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596006178; cv=none; d=google.com; s=arc-20160816; b=RulzMJPAyCf+Er0rP5b+jqJPy+7vQjZd/AmkIv4jQ1pn4ceL1jMR/+O4iXf+dHpNw1 MUVYyW6rbEwtfMW2ZhtTs3CtOl/fLP8UqeT0vkyVid24j3bri5L38bXk0aSIgC18fl7S busiHFhvxgzr9AaCzF2e2gr4w/y2NpNQJbMszWVagZl7RjQ+F981lwn22mZQyTXM+KDi GN3txx1RGQWuuiDvWffxqT77g+C5D+wRllMOrxTDZuDhSzMtM6xFJHfz6Y92NEKvtISP BbgLCh1aavODJRaKvnAbSSC0N2ITldcWQoaOl3Sg6PuBXgdP5d58beh23RKMTevNx2Ki xdlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=BKx6S2q3lWVKQxyCl9y32XXM/M3WBszfImBZH6+wmtk=; b=JvZSj4UW7RFtrhAFYe+OjkFfW8kL1obi8zIfHOhFB4zrrGmIq8Mo4zhHFc2t7F27HT 6vbRY2r1cbwDtuHkn1Ey9Wap04OHz6CvcG8VzoiP7HbT1u9bTsnm0xGZJUUmb3FaK9OO /hzX7p3xuKgSWuRF8kEiCooLkAwJVp6fzMPsdHHntEzJzyJp44NrDZ5uk9nmXaXZWPY/ RT3swA9cXHMqUSSGSjtidt42hLK6ODqPSWziTe9x3/qD118m9j0HG2kEbUQKENmAhbwB G3b8HISwyC0bxNt9K9GZrgw5jn511fxqWSvswaq3VXwUDVgmTPQljNkEXnb6v4OlKClN EgvQ== ARC-Authentication-Results: i=1; mx.google.com; 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 cw11si492388ejb.6.2020.07.29.00.02.35; Wed, 29 Jul 2020 00:02:58 -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; 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 S1727112AbgG2G76 (ORCPT + 99 others); Wed, 29 Jul 2020 02:59:58 -0400 Received: from verein.lst.de ([213.95.11.211]:51231 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726536AbgG2G76 (ORCPT ); Wed, 29 Jul 2020 02:59:58 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id E3DD968B05; Wed, 29 Jul 2020 08:59:55 +0200 (CEST) Date: Wed, 29 Jul 2020 08:59:55 +0200 From: Christoph Hellwig To: Andy Lutomirski Cc: Gabriel Krisman Bertazi , Peter Zijlstra , Christoph Hellwig , Thomas Gleixner , Kees Cook , X86 ML , LKML , kernel@collabora.com Subject: Re: [PATCH 2/6] arch: x86: Wrap TIF_IA32 checks Message-ID: <20200729065955.GA32309@lst.de> References: <20200728202229.1195682-1-krisman@collabora.com> <20200728202229.1195682-3-krisman@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 28, 2020 at 08:43:27PM -0700, Andy Lutomirski wrote: > > index d4edf281fff4..d39f9b3ae683 100644 > > --- a/arch/x86/include/asm/compat.h > > +++ b/arch/x86/include/asm/compat.h > > @@ -181,7 +181,7 @@ static inline void __user *arch_compat_alloc_user_space(long len) > > { > > compat_uptr_t sp; > > > > - if (test_thread_flag(TIF_IA32)) { > > + if (TASK_IA32(current)) { > > sp = task_pt_regs(current)->sp; > > Christoph, you spend a *lot* more time looking at this stuff lately > than I do, but this looks totally wrong. Shouldn't this be either: > > sp = task_pt_regs(current)->sp; > > /* This might be a compat syscall issued via int $0x80 from 64-bit-ABI code. */ > if (user_64bit_mode(task_pt_regs(current)) > sp -= 128; > > Or perhaps the same thing without the user_64bit_mode() check at all? > There shouldn't be much if any harm done by respecting the redzone > unnecessarily. compat_alloc_user_space is only used when either called from compat calls or if in_compat_syscall() is true (and there are very few callers left, and we plan to kill it off entirely..). Which means we are either called from an i386 or x32 syscall, but then again IIRC user_64bit_mode would also return true for x32. So your above version looks correct, and I'd also be tempted to just always respect the redzone. > Surely this should be: > > if (user_64bit_mode(task_pt_regs(regs)) s/regs/current/ Btw, I wonder if want a shorthand for user_64bit_mode(task_pt_regs(thread)) instead of always open coding it.