linux-kernel - Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver

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]

Message-ID: <f60aece195cd0700728fc38b0398949a82b72fc3.camel@linux.intel.com>
Date:   Fri, 01 May 2020 12:50:36 +0100
From:   Daniele Alessandrelli <daniele.alessandrelli@...ux.intel.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        Paul J Murphy <paul.j.murphy@...el.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver

Thanks for your feedback.

> 
> First off, there is a "proper" way to send patches to the kernel
> community that Intel has that I do not think you are
> following.  Please
> work with the Intel "Linux group" to do that first, as odds are they
> would have caught all of these issues beforehand (hint, which is why
> that process is in place...)
> 

I actually followed that process and got the OK to try to upstream.

I think the issues you identified went uncaught mainly due to the
limited Linux ARM expertise within that group (and Intel in general).

Anyway, I'll keep working with our Linux Kernel people to try to reduce
the burden on you and the other kernel maintainers.

> > diff --git a/drivers/soc/keembay/Kconfig
> > b/drivers/soc/keembay/Kconfig
> > new file mode 100644
> > index 000000000000..2161bce131b3
> > --- /dev/null
> > +++ b/drivers/soc/keembay/Kconfig
> > @@ -0,0 +1,22 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# Keem Bay SoC drivers.
> > +#
> > +
> > +menu "Keem Bay SoC drivers"
> > +
> > +config KEEMBAY_IMR
> > +	bool "Clean-up Keem Bay bootloader IMR at boot"
> > +	depends on ARM64
> > +	help
> > +	  This option makes the Kernel clean up the Isolated Memory
> > Region
> > +	  (IMR) set up by Keem Bay bootloader (U-boot) to protect
> > itself during
> > +	  early boot.
> > +
> > +	  The IMR number to be cleaned up is taken from the device tree
> > +	  (property 'u-boot-imr' of the 'chosen' node).
> > +
> > +	  If you are compiling the Kernel for a Keem Bay SoC select Y,
> > +	  otherwise select N.
> 
> No module support?
> 
> What about kernels that support more than one ARM device in the same
> kernel, you just broke that :(
> 

<cut>

> 
> > +}
> > +early_initcall(kmb_imr_init);
> 
> Like I said above, you just broke multi-system kernels by always
> trying
> to do this.  Trigger off of a hardware device that only your platform
> has in order to properly load and run.  As-is, you don't want to do
> this.

My bad, I didn't consider the issue of multi-platform ARM kernels.

The problem is that I need this code to be run early at boot, so I
don't think I can make this a module.

But I'm sure there is a proper way to achieve what I need without
breaking multi-system kernels. I'll do my homework and try to find it.

> 
> Anyway, Intel owes me more liquor for this review as the resources
> you
> had to get review of this were obviously not taken advantage of.
> 
> greg k-h