linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rabin@rab.in (Rabin Vincent)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: fix string functions on !MMU
Date: Fri, 25 Apr 2014 20:45:10 +0200	[thread overview]
Message-ID: <20140425184510.GA17229@debian> (raw)
In-Reply-To: <20140425091224.GA24499@arm.com>

On Fri, Apr 25, 2014 at 10:12:24AM +0100, Will Deacon wrote:
> On Thu, Apr 24, 2014 at 04:43:20PM +0100, Rabin Vincent wrote:
> > On Tue, Apr 22, 2014 at 10:44:24AM +0100, Will Deacon wrote:
> > > On Mon, Apr 21, 2014 at 07:10:08PM +0100, Rabin Vincent wrote:
> > > > 8c56cc8be5b38e ("ARM: 7449/1: use generic strnlen_user and
> > > > strncpy_from_user functions") apparently broken those string operations
> > > > for !MMU.  USER_DS == KERNEL_DS on !MMU, so user_addr_max() always
> > > > restricts the addresses to TASK_SIZE.
> > > > 
> > > > TASK_SIZE has anyway no meaning on !MMU, so make user_addr_max() not
> > > > restrict anything.
> > > 
> > > Might be worth mentioning that this is an issue because KERNEL_DS is 0x0
> > > (since it's a 32-bit quantity), so checks like addr < user_addr_max() will
> > > fail.
> > 
> > Thanks for the ack, but I don't quite understand what you mean here.
> > You describe the state before this patch, right?  Why does it matter
> > that KERNEL_DS is 0x0?
> 
> Apologies, I misread the code that you're patching so I guess I'll have to
> revoke my ack, sorry! That's not to say I think the patch is bad, I'd just
> like to discuss it with you a bit more.
> 
> Having re-read the code, the issue is because TASK_SIZE is defined as
> CONFIG_DRAM_SIZE, right? Since CONFIG_DRAM_BASE may be non-zero, it means
> TASK_SIZE is truly a size -- not a limit (as it would be in virtual space).
> What we actually want for !MMU is END_MEM instead of TASK_SIZE.

I guess you mean I should #define user_addr_max() to END_MEM for !MMU?
That won't work.  For example, on a !MMU boot, the first thing that
fails because of this bug is devtmpsfs_mount() -> sys_mount() ->
copy_mount_string() -> strndup_user(), which is run in a kernel thread.
The type argument of sys_mount() points to a string in flash since we
run an XIP kernel.  This flash address has no relation to END_MEM (which
is nothing but CONFIG_DRAM_BASE + CONFIG_DRAM_SIZE) and could be higher
than END_MEM.

  reply	other threads:[~2014-04-25 18:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 18:10 [PATCH] ARM: fix string functions on !MMU Rabin Vincent
2014-04-22  9:44 ` Will Deacon
2014-04-24 15:43   ` Rabin Vincent
2014-04-25  9:12     ` Will Deacon
2014-04-25 18:45       ` Rabin Vincent [this message]
2014-04-28 19:10         ` Will Deacon
2014-04-28  7:51 ` Uwe Kleine-König
2014-06-02 16:53   ` Rabin Vincent
2014-06-03  7:51     ` Uwe Kleine-König
2014-06-03 19:47       ` Uwe Kleine-König

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=20140425184510.GA17229@debian \
    --to=rabin@rab.in \
    --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).