linux-kernel - Re: [PATCH] ARM: Set proper TEXT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150820195455.GT7557@n2100.arm.linux.org.uk>
Date:	Thu, 20 Aug 2015 20:54:55 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Andy Gross <agross@...eaurora.org>
Cc:	Varadarajan Narayanan <varada@...eaurora.org>,
	Kumar Gala <galak@...eaurora.org>,
	David Brown <davidb@...eaurora.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Lina Iyer <lina.iyer@...aro.org>,
	Georgi Djakov <gdjakov@...sol.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org
Subject: Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x

On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote:
> On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote:
> > > RAM starts at 0x40000000 for IPQ. The lower 21MB of RAM is used
> > > for Shared Memory and the kernel can start from 0x41500000.
> > 
> > Why do people keep creating crap like this?  Each time something like
> > this is created, it means that you _need_ to have a special kernel for
> > your platform and you can't be part of the single zImage.
> > 
> > Please, rather than creating crap like this, find a better way.
> 
> In the case of the IPQ, we don't use the zImage because the decompress
> requires a larger jump than we can do on that platform.  Having this
> change at least gets us back 2MB of memory.

Your argument about "a larger jump" makes no sense what so ever.  The
branches between the decompressor and the main kernel are all done
using a mov, which can jump to any 32-bit address.

Even if you load the compressed kernel image at 0x41500000, the
decompressor will mask that with 0xf8000000, and decide that RAM
starts at 0x40000000.  It will then want to place the decompressed
kernel image at 0x40008000.  Nothing there has anything to do with
jump ranges.

The only restriction that the ARM has as far as jump ranges are
concerned is the 'b' or 'bl' instruction, which in ARM mode is
limited to +/- 32MB.  That doesn't apply here since we don't use
that to jump between the decompressor and the decompressed kernel
image.

So...

Why is it necessary to have this 21MB block of shared memory at
the start of RAM?  Why can't it be reserved by other means higher
up in system memory?

It's up to the submitter to justify why any change is required, and
in this case, part of that justification is why the shared memory is
placed at the start of RAM, and why you need to be different from
almost everyone else, and why you need to be a special case.  The
justification also must make sense.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/