From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752053AbdASV1c (ORCPT ); Thu, 19 Jan 2017 16:27:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39106 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbdASV13 (ORCPT ); Thu, 19 Jan 2017 16:27:29 -0500 Date: Thu, 19 Jan 2017 16:27:18 -0500 From: "Frank Ch. Eigler" To: Thomas Gleixner Cc: David Smith , Peter Zijlstra , Linus Torvalds , Andy Lutomirski , Ingo Molnar , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC][PATCH] x86: Verify access_ok() context Message-ID: <20170119212718.GC20931@redhat.com> References: <20161122193720.GA3045@worktop.programming.kicks-ass.net> <20161205102747.GT3092@twins.programming.kicks-ass.net> <8758e5b4-050d-a5dd-2e58-e4f9dccc734b@redhat.com> <20170119202218.GB20931@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 19 Jan 2017 21:27:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thomas - > Well, if you are not in thread context then the check is pointless: > __range_not_ok(addr, size, user_addr_max()) > and: > #define user_addr_max() (current->thread.addr_limit.seg) > > So what guarantees when you are not in context of current, i.e. in thread > context, that the addr/size which is checked against the limits of current > actually belongs to current? We're probably in task context in that there is a valid current(), but running with preemption and/or interrupts and/or pagefaults disabled at that point, so in_task() objects. Think of it like from a kprobes handler callback, except maybe more temporary preemption blocking. > I assume this is about systemtap modules. Can you please explain > what you are trying to achieve? I guess you know that you actually > access current, but then we need a seperate special function and not > relaxing of the checks. This part is used in a part of the runtime that is a userspace analogue of probe_kernel_address(), where we're given a potential userspace address. We would like to quickly test whether it's even plausible as a userspace address, before doing a (pagefault-disabled) trial fetch/store to it. - FChE