Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp805664ybg; Tue, 28 Jul 2020 20:45:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/GduaXvGeg8FY/28DwdTOAQQUjCWXcYM/5OvmeH2Ef6EpawR29sK5zLkjpc2rAgig3b1E X-Received: by 2002:a17:906:c08a:: with SMTP id f10mr18365112ejz.181.1595994306227; Tue, 28 Jul 2020 20:45:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595994306; cv=none; d=google.com; s=arc-20160816; b=ygGDmgNfg8vMts3iy4Wwl1NMEU0svHY/VkdftQ/pOKV6G/hyj319J8ADVJwgnoG9Hj tcA/8Q6G6Exb73OeZHOShM4gyK7UYiwVSCVLBgN1yQw4Q24Y0KCAGrDHD4DeDYGvJAYE 7dqIOaALxy9xGETsQNFm51G7acdth7kJp/ApTJlQIDrNtUOLeP+lUH4h752kz8hhfkLt fRxyB25EHGsHPdX0YFia/BhITF+2q4yoF0wjYo4f6dJnEZINssY2+shOr5clF0fHQB1d USWSCcs4KKmaVq7GUJm2dn8yZDeSujeYWazMeeV4HbY0ANbAKPs0F2V94XSmAw5EPsm/ coRQ== 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=3qxHrflkneK//pRtaV4iIXJXt8vvI0U2EBrWh2Z6AwM=; b=bCgWhkQOysVdyqdmmIFHQwG4cwKYdf5dP6w0Slv8ilG9oHq5goG9aRyTa462cFqJIG c2eGlgHqLs4mAlSn79mgDelxE8GBpwSjt35dEM9MRNtt6MZLKsYFgSyj5kaQ8H4+Z6mL MXvg9dLVSzERS4cQCHdyOgX1N0s2lSBTCM+Ho+rRWxds9pA4auFp80jUw7Q5FHlh7Ieh kQJvb1B5OBIRPlFTDLqoShMbq9qb8vvf3ig8w/MDWEZH4SkfU2s0IJVgC2wPbx8oLZc1 Q+2ChAbzVgctZec+KTv8Rdljoo2qJE2hbm0sENW+I7m0dRJjJ3yjATLicD2G0DfbO25N genQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rbRCxZPb; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mc7si295195ejb.371.2020.07.28.20.44.43; Tue, 28 Jul 2020 20:45:06 -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=@kernel.org header.s=default header.b=rbRCxZPb; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726336AbgG2Dnl (ORCPT + 99 others); Tue, 28 Jul 2020 23:43:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:57668 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726245AbgG2Dnl (ORCPT ); Tue, 28 Jul 2020 23:43:41 -0400 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6FF862078E for ; Wed, 29 Jul 2020 03:43:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595994220; bh=0/XwXlzsN++/dVqNDxGGq/Z/PQlQgWXOuYRBreapNio=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rbRCxZPb+lXVLWwdf20/W3ygNORNLAmK9aiFdw7WvWybV40mRjZxkIqqBV1R9Xgwp QU1ZFlm/S3junAHlHNGKqy8muwdhcAvOTlITPhPWMTPQdOcrI3uq1BAYyXKwaJfWq5 lhxC3sgpkKjbZDKvqZN+hrS8Xfnz/+8akhNr5SQY= Received: by mail-wm1-f52.google.com with SMTP id 9so1378859wmj.5 for ; Tue, 28 Jul 2020 20:43:40 -0700 (PDT) X-Gm-Message-State: AOAM531Qmz9M6QcaZccQEuZSiiPw2Zt0WXfxdyddWjRUENKC1ORUzEPe gClznvCjkrSs8kRNkDj1kmKuhionQllBMr6Nh+dRBg== X-Received: by 2002:a1c:7e02:: with SMTP id z2mr6651703wmc.138.1595994218953; Tue, 28 Jul 2020 20:43:38 -0700 (PDT) MIME-Version: 1.0 References: <20200728202229.1195682-1-krisman@collabora.com> <20200728202229.1195682-3-krisman@collabora.com> In-Reply-To: <20200728202229.1195682-3-krisman@collabora.com> From: Andy Lutomirski Date: Tue, 28 Jul 2020 20:43:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] arch: x86: Wrap TIF_IA32 checks To: Gabriel Krisman Bertazi , Peter Zijlstra , Christoph Hellwig Cc: Andrew Lutomirski , Thomas Gleixner , Kees Cook , X86 ML , LKML , kernel@collabora.com 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 Tue, Jul 28, 2020 at 1:22 PM Gabriel Krisman Bertazi wrote: > > In preparation to remove TIF_IA32, add wrapper that check the process > has IA32 ABI without using the flag directly. Thank you for doing this, but let's please do it right. There is, fundamentally, no such thing as a "process with IA32 ABI". > > Signed-off-by: Gabriel Krisman Bertazi > --- > arch/x86/events/core.c | 2 +- > arch/x86/events/intel/ds.c | 2 +- > arch/x86/events/intel/lbr.c | 2 +- > arch/x86/include/asm/compat.h | 2 +- > arch/x86/include/asm/thread_info.h | 2 ++ > arch/x86/kernel/perf_regs.c | 2 +- > arch/x86/oprofile/backtrace.c | 2 +- > 7 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c > index 4103665c6e03..42dff74c6197 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -2491,7 +2491,7 @@ perf_callchain_user32(struct pt_regs *regs, struct perf_callchain_entry_ctx *ent > struct stack_frame_ia32 frame; > const struct stack_frame_ia32 __user *fp; > > - if (!test_thread_flag(TIF_IA32)) > + if (!TASK_IA32(current)) > return 0; if (user_64bit_mode(regs)) return 0; > > cs_base = get_segment_base(regs->cs); > diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c > index dc43cc124e09..27d1cc1f3d05 100644 > --- a/arch/x86/events/intel/ds.c > +++ b/arch/x86/events/intel/ds.c > @@ -1261,7 +1261,7 @@ static int intel_pmu_pebs_fixup_ip(struct pt_regs *regs) > old_to = to; > > #ifdef CONFIG_X86_64 > - is_64bit = kernel_ip(to) || !test_thread_flag(TIF_IA32); > + is_64bit = kernel_ip(to) || !TASK_IA32(current); PeterZ, does PEBS not give us a CPL? Is it really just IP? Anyway, this should probably be: is_64bit = kernel_ip(to) || user_64bit_mode(regs) || !user_mode(regs); > #ifdef CONFIG_X86_64 > - is64 = kernel_ip((unsigned long)addr) || !test_thread_flag(TIF_IA32); > + is64 = kernel_ip((unsigned long)addr) || !TASK_IA32(current); Same as above. > diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h > 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. > --- a/arch/x86/kernel/perf_regs.c > +++ b/arch/x86/kernel/perf_regs.c > @@ -123,7 +123,7 @@ int perf_reg_validate(u64 mask) > > u64 perf_reg_abi(struct task_struct *task) > { > - if (test_tsk_thread_flag(task, TIF_IA32)) > + if (TASK_IA32(task)) > return PERF_SAMPLE_REGS_ABI_32; > else > return PERF_SAMPLE_REGS_ABI_64; Surely this should be: if (user_64bit_mode(task_pt_regs(regs)) return PERF_SAMPLE_REGS_ABI_64; else return PERF_SAMPLE_REGS_ABI_32; > diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c > index a2488b6e27d6..3f1086afa297 100644 > --- a/arch/x86/oprofile/backtrace.c > +++ b/arch/x86/oprofile/backtrace.c > @@ -49,7 +49,7 @@ x86_backtrace_32(struct pt_regs * const regs, unsigned int depth) > struct stack_frame_ia32 *head; > > /* User process is IA32 */ > - if (!current || !test_thread_flag(TIF_IA32)) > + if (!current || !TASK_IA32(current)) > return 0; if (user_64bit_mode(regs)) return 0; And now you don't need the TASK_IA32 macro :) All of the above being said, I'm wondering how many of these profiling users remember to check whether the task is a kernel thread. And I have no idea what task_pt_regs(current) contains in a kernel thread. --Andy