linux-kernel - Re: [PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc area

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 16 Feb 2016 12:57:30 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Michal Simek <michal.simek@...inx.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Josh Cartwright <josh.cartwright@...com>,
	Peter Crosthwaite <peter.crosthwaite@...inx.com>,
	Arun Chandran <achandran@...sta.com>,
	Russell King <linux@....linux.org.uk>, monstr@...str.eu,
	linux-kernel@...r.kernel.org, Rob Herring <robherring2@...il.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Sören Brinkmann <soren.brinkmann@...inx.com>
Subject: Re: [PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc area

On Monday 15 February 2016 17:05:17 Michal Simek wrote:
> The patch
> "ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000"
> (sha1: 6ff0966052c46efb53980b8a1add2e7b49c9f560)
> has moved also start of VMALLOC area because size didn't change.
> That's why origin location of vmalloc was
>    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> and now is
>    vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
> 
> That's why uart virtual addresses need to be changed to reflect this new
> memory setup. Starting address should be vmalloc start address.
> 
> Signed-off-by: Michal Simek <michal.simek@...inx.com>

All three patches look good to me,

Acked-by: Arnd Bergmann <arnd@...db.de>

I would like to hear back from Nico on this though: is this an expected
outcome of your patch, or is it something you had not considered at
all?

Do we need to audit all platforms for other instances of the same
problem? I see for instance

static struct map_desc jornada720_io_desc[] __initdata = {
        {       /* Epson registers */
                .virtual        = 0xf0000000,
                .pfn            = __phys_to_pfn(EPSONREGSTART),
                .length         = EPSONREGLEN,
                .type           = MT_DEVICE
        }, {    /* Epson frame buffer */

in arch/arm/mach-sa1100/jornada720.c. Could this have the same problem?

I would guess that only machines with 768MB of RAM (or more) can run
into the bug.

	Arnd