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.
next prev parent 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).