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
| ||
|
Date: Thu, 24 Oct 2019 14:38:44 +0200 From: Linus Walleij <linus.walleij@...aro.org> To: Rasmus Villemoes <linux@...musvillemoes.dk> Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>, Masahiro Yamada <yamada.masahiro@...ionext.com>, Andrew Morton <akpm@...ux-foundation.org>, Gao Xiang <xiang@...nel.org>, Sascha Hauer <kernel@...gutronix.de>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net> Subject: Re: [RFC PATCH 0/3] watchdog servicing during decompression On Thu, Oct 17, 2019 at 2:34 PM Rasmus Villemoes <linux@...musvillemoes.dk> wrote: > On 17/10/2019 14.03, Russell King - ARM Linux admin wrote: > > We used to have this on ARM - it was called from the decompressor > > code via an arch_decomp_wdog() hook. > > > > That code got removed because it is entirely unsuitable for a multi- > > platform kernel. This looks like it takes an address for the watchdog > > from the Kconfig, and builds that into the decompressor, making the > > decompressor specific to that board or platform. > > > > I'm not sure distros are going to like that given where we are with > > multiplatform kernels. That's a very good point. What we have for debug UART etc is explicitly just for debugging on one specific platform and not for production code. But as pointed out there is code like this already. > This is definitely not for multiplatform kernels or general distros, > it's for kernels that are built as part of a BSP for a specific board - > hence the "Say N unless you know you need this.". Not much to do about that, we need to support it already and adding another usecase just makes it more reasonable to support I think. What we need to think about is whether we can imagine some solution that would work with multiplatform. At one point we discussed putting some easily accessible values in the device tree for the "decompressing...." message, so easy to get at that the decompressor could access them easily, or even providing a small binary code snippet in the DTB file to write to the UART. None of this worked out IIUC. I think nothing really materialized from this and the problem is swept under the carpet: no decompress messages for multiplatform. I tried to think about something and just feel I would be reinventing mach-types. Do we have an idea of whether it is possible to dig into a DTB in early boot and find the node for the UART and watchdog and use the physical address from there? Is it really hard or is it just that no-one tried? (Sorry if this is a naive question...) Yours, Linus Walleij
Powered by blists - more mailing lists