From patchwork Thu Oct 4 09:40:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 1545831 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id B5B42DF238 for ; Thu, 4 Oct 2012 09:42:09 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TJhuq-00052l-3j; Thu, 04 Oct 2012 09:40:24 +0000 Received: from metis.ext.pengutronix.de ([2001:6f8:1178:4:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TJhul-000512-MK for linux-arm-kernel@lists.infradead.org; Thu, 04 Oct 2012 09:40:20 +0000 Received: from dude.hi.pengutronix.de ([2001:6f8:1178:2:21e:67ff:fe11:9c5c]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1TJhui-0002sv-Jv; Thu, 04 Oct 2012 11:40:16 +0200 Received: from ukl by dude.hi.pengutronix.de with local (Exim 4.80) (envelope-from ) id 1TJhuh-00039Y-KO; Thu, 04 Oct 2012 11:40:15 +0200 Date: Thu, 4 Oct 2012 11:40:15 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Will Deacon Subject: Re: [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions Message-ID: <20121004094015.GI598@pengutronix.de> References: <1339169935-31775-1-git-send-email-will.deacon@arm.com> <1339169935-31775-2-git-send-email-will.deacon@arm.com> <20121002175316.GA598@pengutronix.de> <20121002191851.GB20411@mudshark.cambridge.arm.com> <20121003060042.GB598@pengutronix.de> <20121003091636.GC22445@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121003091636.GC22445@mudshark.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:6f8:1178:2:21e:67ff:fe11:9c5c X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-Spam-Note: CRM114 invocation failed X-Spam-Score: -4.0 (----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-4.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "linux-arm-kernel@lists.infradead.org" , Nicolas Pitre X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Wed, Oct 03, 2012 at 10:16:36AM +0100, Will Deacon wrote: > On Wed, Oct 03, 2012 at 07:00:42AM +0100, Uwe Kleine-König wrote: > > On Tue, Oct 02, 2012 at 08:18:51PM +0100, Will Deacon wrote: > > > Ok, thanks for the heads-up. I didn't test it with an M-class CPU, but > > > hopefully that's understandable :) > > > > I think so, yes. But I intend to change that, and I heard your coworker > > gets an efm32 :-) > > Yep, he'll be in charge of testing for us (!) :-) > > > > > +#define user_addr_max() \ > > > > > + (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL) > > > > > + > > > > I think this is the problem as for no-mmu USER_DS == KERNEL_DS. I will > > > > take a look tomorrow. > > > > > > I can't immediately see why that would cause a problem, so please let me > > > know if you get more information. > > BTW, I once saw the call to sys_mount fail: > > > > sys_mount -> > > copy_mount_string -> > > strndup_user -> > > strnlen_user returns 0 which makes sys_mount fail with -EFAULT. > > > > but that was not the problem I hit when I bisected (using merges instead > > of rebasing). > > Was this also on your M3? Yeah. I found a change that fixes it for me: I'm not sure if this has some security implications for the !MMU case!? (But if so according to my understanding (which might well be wrong) using TASK_SIZE isn't correct also. So this only widens the window, but doesn't create it.) On !MMU TASK_SIZE is CONFIG_DRAM_SIZE, but I'm using XIP and the flash is at an higher address than RAM. So maybe XIP is broken on MMU machines, too? Best regards Uwe diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h index 77bd79f..7775e03 100644 --- a/arch/arm/include/asm/uaccess.h +++ b/arch/arm/include/asm/uaccess.h @@ -216,7 +216,7 @@ static inline void set_fs(mm_segment_t fs) #define access_ok(type,addr,size) (__range_ok(addr,size) == 0) #define user_addr_max() \ - (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL) + (segment_eq(get_fs(), KERNEL_DL) ? ~0UL : TASK_SIZE) /* * The "__xxx" versions of the user access functions do not verify the