linux-kernel - Re: [PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

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:	Thu, 18 Jul 2013 17:50:07 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Julien Grall <julien.grall@...aro.org>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Ian Campbell <Ian.Campbell@...rix.com>, patches@...aro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>
Subject: Re: [PATCH] arm: choose debug/uncompress.h include when uncompress
	debug is disabled

On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> When Xen will boot, it will use one UART, given by the user, to be able
> to log its information. Xen will not map the UART region and the IRQ to
> dom0. Of course it will not be present in the device tree either. So if
> Linux tries to access to this memory region, it will crash.
> 
> When Linux will boot as dom0, it will either use an hvc console or
> another UART.
> 
> In case of multi-platform environments, there is no issue because when
> CONFIG_DEBUG_UNCOMPRESS is disabled.
> 
> Now, in non-multiplatform environment, the decompressor will use a
> pre-defined UART. This UART may be already used by Xen and Linux will
> abort at the first access.
> 
> I think, the decompressor should be able to detect if the UART exists
> (I'm not sure it's possible) or disabled at compile time uncompress log.
> 
> Do you have any better ideas?

Let me get this straight.

1. You want to run an _existing_ platforms kernel under Xen, where the
   platform assumes that it has various devices at various locations,
   and will make direct accesses to those devices.

2. You don't want to provide some of those devices, and you arrange for
   those unprovided devices to fault.

Excuse me if I think that's really silly.

Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
supposed to be part of the multiplatform kernel stuff now?
--
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/