Jesse,

   I have inserted replies below...

On 1/9/2020 9:13 AM, Jesse Gilles wrote:
Hi Clay, thanks very much for your answers. 

On Fri, Jan 3, 2020 at 4:22 PM Clay Montgomery <clay@montgomery1.com> 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