Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5820128ybl; Tue, 27 Aug 2019 10:05:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZZZyFsR5s272K3VJeMGIZE0Rt4uBR16PAr/e4dzqA0UkhMXsYmjFc380o8D2VZTVuPR5s X-Received: by 2002:a17:902:4201:: with SMTP id g1mr25623747pld.300.1566925503227; Tue, 27 Aug 2019 10:05:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566925503; cv=none; d=google.com; s=arc-20160816; b=bzGM+1X9BabZ5q6IB55fR+IhvI/9UNfwoVki7mYe8ZEvbHaFoeqamxClLrgAmZHA6C I/oaDzeNKHyNEzkCMf/+2WHV9EboRcBqva+hRL3xXcyf0c6r67zITmZf98y4EyYWf0ts sVPACg9pvQugFT9OJ1sGrWYtATMBuLiXl76t0vjqC+7QOQ4qZsjqma3CaobmgK9XbDLT +Skeh6FiuX4Sggy6LBLtGbDuJOAznq5Wn0bM/GOCi6lRdakPdlDCYmyI0U1c43LFJo02 h8aTSxfyO66H1ptZINCiU1syVBnhazkqdbjnz1Zqw0wFB8s4aVdxlIt0C89iFI245vwh dbmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=S8rsamyfBXW/N7Wx0HIWmvrw01QHVusy6HCq7O34p0s=; b=0t3WT6jXfoUy5rSc9EtBsGBkZODffgGelY7Nh5ROLJQXapqNOeRjTNYM5GJCAx+IV8 2ouYF1HIkgZgLm6JWSnsMsqXxy82oOICVTt0PoUB8kHxAL8tfgVwXzHAIA2/VvPz8AqS XnNF1UVijxS8en6KavzeOWBp7YBQQ9e/G4MTOXS9L9WTGq9/M7O1YWOCtsi1KJCcTU4U xu3ZNfGlmkPzhZ6v/LtdvPLEpJosN1GPfVlCi5rIXhcvhtEczUg0LFffxMrprNIxhQL5 K9T002M+V3bdsBx+ib0TaOwOKA1ynCbffYqR2xUwdE+O52aOgrEsaoyvRQEiu9LP6f6v 9biA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=vbbxpR7N; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11si13061817pls.148.2019.08.27.10.04.47; Tue, 27 Aug 2019 10:05:03 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=vbbxpR7N; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727887AbfH0RD1 (ORCPT + 99 others); Tue, 27 Aug 2019 13:03:27 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:38820 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728834AbfH0RDY (ORCPT ); Tue, 27 Aug 2019 13:03:24 -0400 Received: by mail-wm1-f65.google.com with SMTP id m125so3811203wmm.3 for ; Tue, 27 Aug 2019 10:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S8rsamyfBXW/N7Wx0HIWmvrw01QHVusy6HCq7O34p0s=; b=vbbxpR7NcqMaRBjneOWBFEpZSiZKbZKUdEyZ+FVL1lo3MIDfEIPLoPZ1Ew3mHSOXxj QdPAJBKjq7YFQ2RRq8RupQdHZizFtG9zVdlxaJ9F0w1aakeIVnmFKpdoodcQKudCwmp1 W+paPEk5CE0dAAxNhbo1sEDIxPyp9fooqolCpKUBbB+tvjELu4g0otOd43GHEve2pNkb x4nS6oZAlJ/bN9zix3rUAqPquNm0aWr2fBWDfFLrKgQ0OnllJ2JqV4FQFlizQyZtIEzK xl5RW/1yJ/46dWZz8az35xpxkNtvuLxP1qR8gNF3lXtuqnGGLIdCyLrM3hMIj/IgJnTB Tx8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S8rsamyfBXW/N7Wx0HIWmvrw01QHVusy6HCq7O34p0s=; b=Onn1po15IIWx5kGn8a/fTDHzzij7iI7Q7CeCI19drOkv/u59zLuashOD//Yk3JmN2F TZ5hTcgpEv021WKgjZdYlnahgOHGjgrKmHy0dp0hNm0a0AOJt6eL/kcnKJGg0E5H/+q8 LSZX/dYIJgUsOY3ohbB4l5794CNYktfAp950YAV96QDGB7lVOYH7ITitY1JdFUi0XDft +CD5LL6i3LvRksXek8yl8raiGEt6yuuEAdZg5FsloOHZZHG5/2FQhw3Nl2WcaELaMeXs GLmITQ8uQRxMSdXA0AB0487mmbLAGzRPyG2d79PgUxHjfZcR4LmdtKiujFowmjCc6NVP MXiQ== X-Gm-Message-State: APjAAAVtWxHgVD8/U+rfo/Ls94Y8shUQwbAxzDdg+YQq/mYstnljbD8S zODHIjpF1AEfnYAWWx2eb4I= X-Received: by 2002:a1c:c4:: with SMTP id 187mr28258136wma.132.1566925402818; Tue, 27 Aug 2019 10:03:22 -0700 (PDT) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id o9sm17985634wrm.88.2019.08.27.10.03.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Aug 2019 10:03:22 -0700 (PDT) Subject: Re: get_unmapped_area && in_ia32_syscall (Was: [PATCH] uprobes/x86: fix detection of 32-bit user mode) To: Oleg Nesterov Cc: Thomas Gleixner , Sebastian Mayr , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, LKML , Masami Hiramatsu , Andy Lutomirski , Peter Zijlstra , Dmitry Safonov , Srikar Dronamraju References: <20190728152617.7308-1-me@sam.st> <20190827140055.GA6291@redhat.com> From: Dmitry Safonov <0x7f454c46@gmail.com> Message-ID: <15c5d9f6-6429-4775-05af-8a956d44a9ef@gmail.com> Date: Tue, 27 Aug 2019 18:03:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190827140055.GA6291@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oleg, On 8/27/19 3:00 PM, Oleg Nesterov wrote: [..] > But to remind, there is another problem with in_ia32_syscall() && uprobes. > > get_unmapped_area() paths use in_ia32_syscall() and this is wrong in case > when the caller is xol_add_vma(), in this case TS_COMPAT won't be set.> > Usually the addr = TASK_SIZE - PAGE_SIZE passed to get_unmapped_area() should > work, mm->get_unmapped_area() won't be even called. But if this addr is already > occupied get_area() can return addr > TASK_SIZE. Technically, it's not bigger than TASK_SIZE that's supplied get_unmapped_area() as an argument.. [..] > if (!area->vaddr) { > + if(!is_64bit_mm(mm)) > + current_thread_info()->status |= TS_COMPAT; > /* Try to map as high as possible, this is only a hint. */ > area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, > PAGE_SIZE, 0, 0); > + if(!is_64bit_mm(mm)) > + current_thread_info()->status &= ~TS_COMPAT;; > if (area->vaddr & ~PAGE_MASK) { > ret = area->vaddr; > goto fail; It could have been TASK_SIZE_OF(), but that would be not much better in my POV. I see that arch_uprobe_analyze_insn() uses is_64bit_mm() which is correct the majority of time, but not for processes those jump switching CS.. Except criu afair there are at least wine, dosemu. I had it in my TODO to fix this :) Do I read the code properly and xol is always one page? Could that page be reserved on the top of mmap_base/mmap_compat_base at the binfmt loading time? (I would need than to add .mremap() for restoring sake). Probably, not reserving it if personality doesn't allow randomization or providing a way to disable it.. Thanks, Dmitry