Hi Jesse,

On Thu, Dec 19, 2019 at 7:33 PM Jesse Gilles <jesse.gilles@...> wrote:

Hello,

I am working on a project using the i.MX6UL and I am curious about the state of Linux kernel support in various different kernel recipes in meta-freescale.

After reading documentation and various posts, this is my understanding of the different kernels in the layer:

linux-fslc: purely community maintained kernel, kept pretty up to date with upstream
linux-imx-fslc: community maintained kernel, based off NXP official BSP release kernel
linux-imx: NXP official BSP release kernel

For i.MX6UL support and functionality, is there a significant difference between linux-fslc and linux-imx-fslc?

For linux-imx-fslc, is there a specific reason it is still using 4.9-1.0.x-imx and not the newer 4.9-2.3.x-imx branch?

If linux-imx-fslc is the best option, is anyone maintaining the 4.9 branch and planning to keep it up to date with upstream LTS updates? I see that 4.9-2.3.x-imx has been updated to 4.9.166.

In short, I am looking for the best maintained and updated kernel with support for the i.MX6UL, including security fixes into the future. My existing project uses a customized linux-imx 4.9 kernel.

Any help would be greatly appreciated.

I suggest you to move to kernel 5.4.x instead.

Regards,

Fabio Estevam

Jesse,

    1. The best answer is probably to take a look at NXP's notes and defconfigs here:

    repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml

    ~/Yocto/imx-yocto-bsp/sources/meta-freescale/recipes-kernel/linux/

    2. There were a lot of changes made to the DRM in the 4.9 kernels that had a major impact on NXP's IPU and V4L2 support drivers. Some fundamental stuff (like /dev/fb, X11 and Wayland) were broken and NXP seems unlikely to ever fix that for newer kernels on the i.MX6.

    3. Certainly not NXP.

Most developers still on the i.MX6 seem to either stick with 4.1.15 or move to a mainline kernel.

Regards, Clay

Hi Jesse,

On Fri, Jan 3, 2020 at 4:41 PM Jesse Gilles <jesse.gilles@...> wrote:

Can you explain why you recommend the 5.4 kernel? I don't see a recipe for it in meta-freescale.

5.4 kernel is the most recent kernel that will be LTS.

Hi,

On 09/01/2020 16:13, Jesse Gilles wrote:

Hi Clay, thanks very much for your answers. 

...

Can anyone comment on how they are handling kernel CVEs for products that are i.MX-based?  Are you using a mainline LTS kernel and keeping up with upstream updates?  Are you using an NXP kernel and manually patching specific CVEs?

We're using the latest stable mainline kernel for different i.MX6 derivates.

For us everything (USB, ETH, SATA, MMC, I2C, CODA, HDMI, etc...) works with the mainline kernel.
Except the JPEG encoder which is currently under Patch review and will
hopefully be merged soon.

If you have any specific questions just ask ;-)

Thanks,
Jesse

regards;rl

Jesse,

   I have inserted replies below...

Hi Clay, thanks very much for your answers. 

On Fri, Jan 3, 2020 at 4:22 PM Clay Montgomery <clay@...> wrote:

Jesse,

    1. The best answer is probably to take a look at NXP's notes and defconfigs here:

    repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml

    ~/Yocto/imx-yocto-bsp/sources/meta-freescale/recipes-kernel/linux/

    2. There were a lot of changes made to the DRM in the 4.9 kernels that had a major impact on NXP's IPU and V4L2 support drivers. Some fundamental stuff (like /dev/fb, X11 and Wayland) were broken and NXP seems unlikely to ever fix that for newer kernels on the i.MX6.

When you say that NXP is unlikely to fix IPU/video related driver support in newer kernels, which kernel versions are you referring to?  Later NXP-released 4.9 kernels like 4.9.123-2.3.0ga?

I mean ALL kernels from 4.9.x onward.

Many developers are using newer kernels on the i.MX6, but they got there by going to mainline and either not using the VPU or GPUs at all, or using the open source Etnaviv drivers, which are limited in functionality (mainly OpenGL ES 3.0 and OpenCL stuff) compared to the Vivante package from NXP.

For example, if you build Yocto Sumo, Warrior or Thud from the FSL Community BSP, you get no functional VPU or GPU support. Even a lot of NXP's unit tests fail to run. Pyro is the latest one that works, because it has Vivante with 4.1.15 kernel.

Maybe someone has manually integrated a Vivante package with a mainline kernel themselves? But, that is likely a lot of work and undocumented. The issues are mainly with the DRM, I think. I would really like to see comments from anyone that has done that successfully, and what was required?

As far as NXP ever fixing this. They will not even reply about it:

https://community.nxp.com/thread/518771

    3. Certainly not NXP.

Most developers still on the i.MX6 seem to either stick with 4.1.15 or move to a mainline kernel.

Do you know which mainline kernel version has full support for the i.MX6 or how I would be able to find out the status of support in various kernel versions?  If mainline is stable for the i.MX6 and the driver support is on-par with the NXP-released kernels, I may considering moving to mainline at some point.  I was under the assumption that mainline might be missing critical driver support or bug fixes and I would be better off with an NXP kernel, but perhaps that is not the case.

If developers stick with 4.1.15, how do they address kernel CVEs?  This is the main issue I am concerned about.  I'm coming at this from a maintenance and security perspective.  I need to be able to support shipping products by providing fixes for any major CVEs and that includes the Linux kernel, especially if any CVEs are remotely exploitable.  I would also like to do this with the least impact possible, so avoiding major kernel upgrades is preferable in my mind.

Can anyone comment on how they are handling kernel CVEs for products that are i.MX-based?  Are you using a mainline LTS kernel and keeping up with upstream updates?  Are you using an NXP kernel and manually patching specific CVEs?

Thanks,

Jesse

I think the Vivante package (and DRM) is the big issue. The GPUs and VPU are maybe 30% of the i.MX6 quad die area.  That means it's 1/3 of the cost of the hardware, at least.

You are confusing the security needs of a desktop system with embedded. With embedded linux, kernel updates are not needed for good security if you configure the system well.

Regards, Clay

On Thu, Jan 9, 2020 at 5:08 PM Jesse Gilles <jesse.gilles@...> wrote:

On Thu, Jan 9, 2020 at 11:18 AM Clay Montgomery <clay@...> wrote:
Hm, I don't agree. If an embedded Linux device uses Wi-Fi and Bluetooth communications, won't vulnerabilities affecting those parts of the kernel need to be patched?

Examples:
https://www.linuxkernelcves.com/cves/CVE-2019-17133
https://www.linuxkernelcves.com/cves/CVE-2019-16746
https://www.linuxkernelcves.com/cves/CVE-2019-9506

I believe some of these could be exploitable without accessing the device or gaining local privileges.

I agree with you Jesse and that's why we've been moving most of our
customers to Linux mainline. Most vendor BSP does not have stable
updates.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

On Thu, Jan 9, 2020 at 5:08 PM Jesse Gilles <jesse.gilles@...> wrote:

On Thu, Jan 9, 2020 at 11:18 AM Clay Montgomery <clay@...> wrote:
Hm, I don't agree.  If an embedded Linux device uses Wi-Fi and Bluetooth communications, won't vulnerabilities affecting those parts of the kernel need to be patched?

Examples:
https://www.linuxkernelcves.com/cves/CVE-2019-17133
https://www.linuxkernelcves.com/cves/CVE-2019-16746
https://www.linuxkernelcves.com/cves/CVE-2019-9506

I believe some of these could be exploitable without accessing the device or gaining local privileges.

I agree with you Jesse and that's why we've been moving most of our
customers to Linux mainline. Most vendor BSP does not have stable
updates.

It depends in your target application/market. If anyone can connect to your device with Wi-Fi or Bluetooth, then obviously security is a lot more important.

But, consider the digital signage player market, for example, where it's actually an advantage over Windows and Android devices to never require updates.

Regards, Clay

On 1/9/20 9:14 PM, Jesse Gilles wrote:

On Thu, Jan 9, 2020 at 9:28 AM Richard Leitner <richard.leitner@... <mailto:richard.leitner@...>> wrote:

We're using the latest stable mainline kernel for different i.MX6 derivates.

For us everything (USB, ETH, SATA, MMC, I2C, CODA, HDMI, etc...) works with the mainline kernel.
Except the JPEG encoder which is currently under Patch review and will
hopefully be merged soon.

If you have any specific questions just ask ;-)


Thanks for the info. Do you know if mainline 4.14.x contains adequate support for the i.MX6UL? 4.14 appears to have the longest planned support according to https://www.kernel.org/category/releases.html

We've never tried 4.14. The last "LTS" version I used was 4.9.
Since then our strategy is to always use the latest stable version. Therefore
we are currently on 5.4 and will move to 5.5 in a few weeks.

This is due to known reasons which mainly derive from the kernels "every
fix has to be in master first" policy (or however it is really
called^^).

As we update our kernel regularly (especially in networked or physically
exposed solutions) it made no difference for us if we move to a new
stable release or LTS update.

Of course you should have an adequate test-depth to make sure nothing
breaks or other unwanted things (like a drop in performance) happens. ;-)

For more info on picking a kernel version I suggest reading Greg-KHs
blog on that: http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

regards;rl

Thanks,
Jesse