linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions
Date: Thu, 4 Oct 2012 11:40:15 +0200	[thread overview]
Message-ID: <20121004094015.GI598@pengutronix.de> (raw)
In-Reply-To: <20121003091636.GC22445@mudshark.cambridge.arm.com>

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:

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

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

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2012-10-04  9:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 15:38 [RFC PATCH 0/2] Implement word-at-a-time string functions Will Deacon
2012-06-08 15:38 ` [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions Will Deacon
2012-06-08 15:43   ` Will Deacon
2012-06-12  2:53   ` Nicolas Pitre
2012-06-12 21:17     ` Will Deacon
2012-10-02 17:53   ` Uwe Kleine-König
2012-10-02 19:18     ` Will Deacon
2012-10-03  6:00       ` Uwe Kleine-König
2012-10-03  9:16         ` Will Deacon
2012-10-04  9:40           ` Uwe Kleine-König [this message]
2012-06-08 15:38 ` [RFC PATCH 2/2] ARM: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs Will Deacon
2012-06-12  2:55   ` Nicolas Pitre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121004094015.GI598@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).