zephyr-kernel: don't fetch sources we don't use

For legal reasons (to avoid downloading binary firmware covered by patents and whatnot) drop all repositories that aren't and the moment and most likely will never be used by Oniro.

Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@huawei.com

requested review from @pidge, @agherzan, and @alpianon

assigned to @brgl

My question with this is does this patch remove all repos that have closed firmware blobs (which is fine) or does it remove all repos we theoretically don't us?

I would prefer that if we are going to do this here, we just remove the repos with those blobs. If this patch does that, fine. If not, can we trim this down to just the problematic repos?

For the security point of view I would prefer to remove all repos we do not use. If we decide to use them finally, we'll enable them directly. Security analysis of the zephyr repo is a little...complicated

A change like this will pose maintenance overhead on rebases. I would prefer to explore a path where we could upstream the removal for the ones that have legal issues - I expect upstream would be happy to solve them as well.

The rule is that we review all sources included in recipes of components that actually end up in any reference image, on the assumption that such sources are actually used to build such components.

This is because we are simulating the compliance and security work a device maker would have to do on a real world product.

A good practice for any device maker is to identify sources that are actually used, and remove all unused stuff that may lead to false positives in compliance and security checks. So should do we.

I'm with @agherzan on this one. Gratuitously removing support for all platforms that aren't used in a Oniro reference board needs some more discussion.

I'd like to investigate using supportability and Security-related release notes to highlight the platforms for which we've done security review using whitelists instead.

Whitelist -> supportlist or includelist in this case

I agree that we might handle it in the supportability work. However, for now we deal only with packages. Adding boards to the mix is something we'll need to discuss

My vote at this point is to react to specific issues we have and drop the low-hanging items that are a considerable impact on IP work - for example, FreeRTOS (which is in the experimental stage anyway). The problem at hand here is not specific to Zephyr - Linux is a considerable codebase that is also modular, linux-firmware, etc. And a considerable additional amount of packages have modular configurations (implemented in different ways). All these can pull in way more than the build system is taking into consideration. I would avoid going down the route where we limit the support of the platform based on the capabilities of the IP load. This will end up to a point where users will have to revert out changes in their layers and maintain that to even consider using Oniro. We must remember that Oniro is meant for usecase-agnostic products and it is not a product in itself. The approach that is proposed in this MR would fit better in a product context - for example in a blueprint: If I know that my product doesn't use support X or feature Y, I can remove the associated sources and avoid unnecessary IP-related auditing. In a platform, a user might take advantage of any of the included support. Of course, supportability comes into play here and we already do that - see below.

Now, the issue at hand is IP load. We already have an 'includelist' approach to limit load - we audit the packages pulled in the reference images as opposed to the 'world' (we consider these supported packages too). This is the first level of granularity while this MR proposes a second level of granularity where we filter SRC_URI at the level of a recipe. For this to work as expected with an 'includelist', we need to have tooling that maintain this list otherwise we can easily end up in a situation where new support is not audited due to past decisions.

With all that being said, for us to be able to make compromises, we need to first clearly state the impact/current issue: understanding the current load, the additional low-hanging fruits we can use to improve it, and the proposed way to maintain an implementation.

My view is that if a board/device/hw component is officially supported by Oniro, we should audit and review any software (source or binary) needed to support it. If it's not officially supported, we should not review anything, and leave any liability to the downstream user/device maker who wants to add support for it. Something like "we do not support platform XYZ. If you want to add support to it, just extend the recipe with a bbappend in this way, but we didn't tested it nor we performed any due-diligence (on licenses, security, etc.)."

But I agree that this is a decision that needs to be discussed and made in a more official way (typically, within the Open Source Review Board)

^cc @cpiana @rahulmohang

Is anyone taking the lead here to move this forward? This has been stale for a month.

@agherzan is right, we need data to make a decision. I'm starting working on the sources->binaries mapping by parsing metadata generated by create-spdx bbclass, in order to generate meaningful stats. I may need help from @mrybczyn at some point