Suppose you have a functional layer which needs to apply certain kernel fragments to the kernel (example: enable Smack, see https://github.com/01org/meta-intel-iot-security/tree/master/meta-security-smack/recipes-kernel/linux-yocto). The layer is meant to be agnostic of the actual BSP it is used with, so it cannot make (strict) assumptions about the name of the kernel recipe. That rules out using, for example, a linux-yocto_%.bbappend, because there are BSPs where the kernel is not called "linux-yocto", even if it includes linux-yocto.inc. Copies of the .bbappend or symlinks for all known kernels do not work either, because then the layer cannot be used unless all of these kernel recipes are present (which is not the case when using BSP layers only when needed). It also does not scale. What happens to work at the moment is a linux-%.bbappend, which merely assumes that the kernel recipe starts with "linux-". That's because wildcard matching in cooker.py:get_file_appends() is fairly simplistic. However, this aspect of the implementation is not guaranteed because % is only documented as matching the version part. As an aside, it's worth pointing out though that a "foo_%.bbappend" does not match a foo.bb, which it probably should match?! Extra care must be taken in such a linux-%.bbappend to not make changes to recipes which are not actually kernel recipes, like this: FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:" SRC_URI_append = " ${@bb.data.inherits_class('kernel', d) and ' \ file://some-kernel-config.cfg \ ' \ or ''}" For this to work officially, the meaning of % in a .bbappend would have to be changed. That's a change in bitbake's documentation (but not the code, unless you also want to deal with the foo_%.bbappend -> foo.bb issue). The alternative discussed with rewitt on IRC was to not use a .bbappend at all, and instead let the layer.conf list additional kernel config fragments in a variable. The downside of that is that it is less obvious that the kernel gets modified by a layer, and mechanisms like BBMASK cannot be used. That would be a change in the kernel.bbclass.
meta-intel-iot-security now uses linux-%.bbappend. See https://github.com/01org/meta-intel-iot-security/pull/38 and https://github.com/pohly/meta-intel-iot-security/commit/2515e235c02a452f4fe4c558f2e2d3839b1ac4fd for the actual commit. Better solutions welcome :-/
It's worth noting that if you truly want this to be *truly* agnostic of the actual BSP it's used with, then we need all kernel recipes to support config fragments, but that's not the case today. Today it's linux-yocto and whatever BSP kernels inject their own merge_configs.sh usage :)
The update to the bug, prompted me to realize that I had left the state as "new". I've fixed that now. Indeed, the broader fragment support had the stage set in the upcoming 2.0 release, and in 2.1, the next steps can come in (just not enough hours in the day! :)
This change is big enough, that M3 is not the time to introduce it. Moving it to 2.2, so the implementation can get more mileage.
Design & implementation complete for arbitrary fragment support .. or more precisely "on demand" fragment support. Will send out the changes for the 1.2 cycle .. after they've had a good long soak.
Is the design available for review anywhere, or the implementation on a branch for folks to poke at yet, or holding off till 2.2?
(In reply to comment #6) > Is the design available for review anywhere, or the implementation on a > branch for folks to poke at yet, or holding off till 2.2? It's dirty at the moment .. functional, but needs more tweaking. I want to re-base it off some new 2.2 work (the fragment auditing and "why it was dropped" support), so I'm still sitting on it locally to avoid distraction. I will put it out in M1 for RFC, and make sure to copy you.
As much as we can get into 2.2 is done and in the tree. This can be completed in the 2.3 cycle.
re-working the implementation. This is unlikely for M3, and is too big for m4. So I'm preemptively moving this out, but will continue to work on it.
+brian&saul
moving to m3. meeting the varied requirements and allowing the kernel-cache to be used without .scc files has caused some re-work. Rather than rush it, I'll do this for M3.
Bumping this, now that the new design is in implementation. The strategy is streamlined/simple non invasive fragment merging in the core kernel bbclass. Even that support is only triggered when a .cfg is detected in the SRC_URI. kernel-yocto maintains the .scc (aka inclusion/integrated features + frags) and configuration audit functionality. shared kernel configuration fragments (which is important for re-use) can come in via kernel-meta repositories in the SRC_URI (optionally with the fetcher only bringing in specified fragments) + a variable that instructs the configuration merging to process fragments from that external meta store. We want to promote/leave the door open for fragment re-use, since otherwise we end up with a soup of namespace colliding fragments (assuming anyone actually uses it).
Reducing the days to 2. Implementation is done, and I can build all the linux-yocto variants against it without regression. custom kernels can also do defconfig + fragments with support enabled via the presence of frags in the src_uri. The 2 remaining days is for review and extended regression testing.
Change is available here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments And I've also attached the patch
Created attachment 4001 [details] arbitrary kernel fragments
(In reply to comment #14) > Change is available here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > And I've also attached the patch I'm not sure how this solves the problem. You are adding support for kernel config fragments to non-linux-yocto kernels, but then the original problem remains: how can a layer or distro change the configuration of the kernel without knowing the actual kernel recipe name? A more recent example is how tpm.scc and tpm2.scc are defined by meta-measured and meta-security (both basically have the same code): https://github.com/flihp/meta-measured/tree/master/recipes-kernel/linux There's a bunch of .bbappends. But that only works for certain well-known and common kernels. Appending to KERNEL_FEATURES globally kind of works if the referenced feature is defined in meta data cache of the kernel. But I can't see how one can add a custom .scc/.cfg in a clean way.
(In reply to comment #16) > (In reply to comment #14) > > Change is available here: > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > And I've also attached the patch > > I'm not sure how this solves the problem. You are adding support for kernel > config fragments to non-linux-yocto kernels, but then the original problem > remains: how can a layer or distro change the configuration of the kernel > without knowing the actual kernel recipe name? That was *never* my original problem. The problem was to bring fragment support to kernel's that want to use them. You should never apply a fragment to a kernel without knowing the target. Since the capabilities vary based on version and patching. > > A more recent example is how tpm.scc and tpm2.scc are defined by > meta-measured and meta-security (both basically have the same code): > https://github.com/flihp/meta-measured/tree/master/recipes-kernel/linux > > There's a bunch of .bbappends. But that only works for certain well-known > and common kernels. > > Appending to KERNEL_FEATURES globally kind of works if the referenced > feature is defined in meta data cache of the kernel. But I can't see how one > can add a custom .scc/.cfg in a clean way. Setting KERNEL_FEATURES searches any layer/directory structure that has a kernel-meta repo or a fragment. So that is the suggested mechanism. Add your fragments grouping via a kmeta SRC_URI and then select them via KERNEL_FEATURES.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #14) > > > Change is available here: > > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > > > And I've also attached the patch > > > > I'm not sure how this solves the problem. You are adding support for kernel > > config fragments to non-linux-yocto kernels, but then the original problem > > remains: how can a layer or distro change the configuration of the kernel > > without knowing the actual kernel recipe name? > > That was *never* my original problem. But it is what this issue here is about. > You should never apply a fragment to a kernel without knowing > the target. Since the capabilities vary based on version and > patching. Some features like Smack and or TPM support are generic enough that it would make sense to enable them for arbitrary kernel recipes, provided that the kernel recipe supports config fragments. > > Appending to KERNEL_FEATURES globally kind of works if the referenced > > feature is defined in meta data cache of the kernel. But I can't see how one > > can add a custom .scc/.cfg in a clean way. > > Setting KERNEL_FEATURES searches any layer/directory structure that > has a kernel-meta repo or a fragment. So that is the suggested > mechanism. Add your fragments grouping via a kmeta SRC_URI and then > select them via KERNEL_FEATURES. So there can be more than one kmeta SRC_URI entry? I read the documentation today again and that part was not clear to me. But that still doesn't address the problem from the description: how can SRC_URI be set without knowing the name of the kernel recipe? But how can one set t
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #14) > > > > Change is available here: > > > > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > > > > > And I've also attached the patch > > > > > > I'm not sure how this solves the problem. You are adding support for kernel > > > config fragments to non-linux-yocto kernels, but then the original problem > > > remains: how can a layer or distro change the configuration of the kernel > > > without knowing the actual kernel recipe name? > > > > That was *never* my original problem. > > But it is what this issue here is about. Fair enough. I've had a bug open for two years about moving the fragment support into a more general location. That is what I was using this for. .. I have no intention of changing the way that the meta data is separated from kernel providers and recipes. So I'll create a new bug for my work. > > > You should never apply a fragment to a kernel without knowing > > the target. Since the capabilities vary based on version and > > patching. > > Some features like Smack and or TPM support are generic enough that it would > make sense to enable them for arbitrary kernel recipes, provided that the > kernel recipe supports config fragments. TPM ? definitely not, that requires h/w to be truly useful. But even with a better example, not actually useful IMHO this is an area that you really shouldn't be throwing features out and hope that they stick in the kernel you are building. > > > > Appending to KERNEL_FEATURES globally kind of works if the referenced > > > feature is defined in meta data cache of the kernel. But I can't see how one > > > can add a custom .scc/.cfg in a clean way. > > > > Setting KERNEL_FEATURES searches any layer/directory structure that > > has a kernel-meta repo or a fragment. So that is the suggested > > mechanism. Add your fragments grouping via a kmeta SRC_URI and then > > select them via KERNEL_FEATURES. > > So there can be more than one kmeta SRC_URI entry? I read the documentation > today again and that part was not clear to me. Yep. You can have as many as you want. The docs may be out date or lagging. > > But that still doesn't address the problem from the description: how can > SRC_URI be set without knowing the name of the kernel recipe? > It can't. As I mentioned above, this is talking about breaking the separation of the meta data from the recipe that is processing those variables. That's not a separation that I'm willing to break, but it is what KERNEL_FEATURES can do if it was part of the global configuration namespace .. which isn't entirely a great idea. To provide a feature like you are talking about, a layer can have a kernel meta available, and a kernel recipe that someone is building can use it. Simply including a layer should not modify the kernel configuration unless it is asked for (like the yocto compatibility changes that have been happening throughout the various layers). So unless a kernel recipe asks for a feature (via KERNEL_FEATURES) or a specific kernel is targeted .. this is not a good thing to have in a layer. > > But how can one set t
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > Some features like Smack and or TPM support are generic enough that it would > > make sense to enable them for arbitrary kernel recipes, provided that the > > kernel recipe supports config fragments. > > TPM ? definitely not, that requires h/w to be truly useful. Of course, but a kernel with TPM support will work fine on a device without TPM hardware. So it is not unreasonable to enable the feature, just in case, and then check at runtime in userspace whether the hardware is present. > > But that still doesn't address the problem from the description: how can > > SRC_URI be set without knowing the name of the kernel recipe? > > > > It can't. As I mentioned above, this is talking about breaking the > separation of the meta data from the recipe that is processing > those variables. > > That's not a separation that I'm willing to break, but it is what > KERNEL_FEATURES can do if it was part of the global configuration > namespace .. which isn't entirely a great idea. > > To provide a feature like you are talking about, a layer can have > a kernel meta available, and a kernel recipe that someone is building > can use it. That's exactly where things become complicated. There are various layers (Smack, TPM, Brian's work with containers) that try to be easy to use in the sense that a) adding the layer and b) setting some global config variable or sourcing a config file is enough to activate the functionality of the layer. That ease of use is gone once developers have to start reconfiguring their kernel recipe. A distro that supports arbitrary BSPs also can't help there.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > (In reply to comment #17) > > > Some features like Smack and or TPM support are generic enough that it would > > > make sense to enable them for arbitrary kernel recipes, provided that the > > > kernel recipe supports config fragments. > > > > TPM ? definitely not, that requires h/w to be truly useful. > > Of course, but a kernel with TPM support will work fine on a device without > TPM hardware. So it is not unreasonable to enable the feature, just in case, > and then check at runtime in userspace whether the hardware is present. > We'll disagree on this point .. I've been fighting this battle for 13 years. If a fragment applies and is enabled, people think it will work. No amount of holding our breath and hoping they'll look at the actual h/w to determine if it really will work will make it happen .. they simply don't. So there's a contract between the kernel -> BSP that if an option is enabled, it really has to have the supported h/w in that BSP. See my old bugs that talk about machine features, distro features and kernel features all working in coordination. This is not something we solve by arbitrarily applying configs to a kernel when a layer is included. > > > But that still doesn't address the problem from the description: how can > > > SRC_URI be set without knowing the name of the kernel recipe? > > > > > > > It can't. As I mentioned above, this is talking about breaking the > > separation of the meta data from the recipe that is processing > > those variables. > > > > That's not a separation that I'm willing to break, but it is what > > KERNEL_FEATURES can do if it was part of the global configuration > > namespace .. which isn't entirely a great idea. > > > > To provide a feature like you are talking about, a layer can have > > a kernel meta available, and a kernel recipe that someone is building > > can use it. > > That's exactly where things become complicated. There are various layers > (Smack, TPM, Brian's work with containers) that try to be easy to use in the > sense that a) adding the layer and b) setting some global config variable or > sourcing a config file is enough to activate the functionality of the layer. > > That ease of use is gone once developers have to start reconfiguring their > kernel recipe. A distro that supports arbitrary BSPs also can't help there. ... and that's not something we are going to solve for the kernel in any different way from the rest of the ecosystem. The bug that Brian raised about setting kernel options in local.conf was reject by myself, RP and others, for the reasons I'm giving here. You just don't break the separation of recipes -> global config in that way. You can always set kernel features in those very same files by using the _pn notation on a variable. There has already been a push for layers to exactly not do this. If you include a layer, it does nothing until you enable a DISTRO or other feature that triggers the functionality. No bbappends, etc, that change package configurations unless explicitly enabled. That's how we now do it in meta-virtualization. If someone is doing their work, and it requires kernel features, it really isn't too much to ask that they understand which kernel they are building and the name of the recipe so they can enable the functionality. But if it is too much to ask, then maybe something in anonymous python or a bitbake mod like you are talking about would be possible, but that functionality still will only be enabled when a distro or other flag is set. So while I recognize that the goal is noble, it just isn't something that is broadly going to happen .. unless there's a complete shift in yocto compliance and the ability to include a layer and have it do nothing. What I can do, and what I'm doing here, is make sure that if a layer has kernel configuration fragments that they can be selected via KERNEL_FEATURES (or via another type of include) and then applied to any kernel, even if it isn't based on kernel-yocto directly.
(In reply to comment #19) > (In reply to comment #18) > > > That was *never* my original problem. > > > > But it is what this issue here is about. > > Fair enough. I've had a bug open for two years about moving the > fragment support into a more general location. That is what I > was using this for. I'm moving this issue back to "NEW" so that it can be triaged again. (In reply to comment #21) > (In reply to comment #20) > > Of course, but a kernel with TPM support will work fine on a device without > > TPM hardware. So it is not unreasonable to enable the feature, just in case, > > and then check at runtime in userspace whether the hardware is present. > > > > We'll disagree on this point .. I've been fighting this battle > for 13 years. > > If a fragment applies and is enabled, people think it will work. > > No amount of holding our breath and hoping they'll look at the > actual h/w to determine if it really will work will make it happen > .. they simply don't. > > So there's a contract between the kernel -> BSP that if an option > is enabled, it really has to have the supported h/w in that BSP. Huh? Then why are there kernels with support for IDE, SATA and SCSI when actual boards only support a subset of that? This stance that "it really has to have the supported h/w in that BSP" sounds rather extreme to me and a poor fit for BSPs which try to support a variety of different devices. I agree that it makes sense for BSPs that target only one specific hardware configuration. > This is not something we solve by arbitrarily applying configs to > a kernel when a layer is included. I'm not advocating that merely including a layer should be enough. That would clearly go against "Yocto Compatible 2.0". > ... and that's not something we are going to solve for the kernel in any > different way from the rest of the ecosystem. The rest of the stack often looks at distro features. A "tpm" or "tmp2" distro feature make sense to me. Specifically in Refkit I'd like to use that to enable whole-disk encryption support based on a TPM. That works for individual recipes, just not for the kernel. It does not work because adding distro-specific changes (like enabling TPM based on a distro feature) to a BSP would limit the usage of the BSP to that distro. It does not work in the distro because the distro can't know which BSP is going to be used. This is the catch-22 that somehow needs to be solved. If the general consensus is that this problem should be punted to developer who sets up a build configuration, then okay, let's close this issue as "wontfix". Personally I think it would be better to address the problem in a more developer-friendly way. Checking KERNEL_FEATURES is one piece of the puzzle. What's missing is adding the necessary feature definitions without knowing the kernel recipe. How about supporting a KERNEL_META variable that supports listing additional meta repository URLs in the same way as SRC_URI?
I clearing the date, and giving this one to RP. I will be submitting my kernel fragment support for any kernel, regardless, but this needs RPs architectural input. But as for layers applying features/fragments to arbitrary kernel recipes without needing a bbappend for the specific kernel recipe, that isn't something that I think is a good idea, or a separation of meta data that I want to break. If Richard agrees that the idea is sound, and that there's no other existing mechanism for this, then whatever support form it takes, I'll make sure it works for the kernel, but it won't be a kernel specific overall implementation since any package (i.e. u-boot, X, etc) could also use something like this.
I can answer these questions as well as anyone else (no insult to Saul). The entire point of me assigning it to RP was to actually get *his* input. I'll take it back, and ask via email.
... and clearing the date again. I'm not sure why there's so much mucking happening with these cases.
is this change still applicable to master and can we get it submitted? if not, can we close as wontfix. I won the lottery an got the AR from the bug triage meeting : )
(In reply to comment #26) > is this change still applicable to master and can we get it submitted? if > not, can we close as wontfix. > > I won the lottery an got the AR from the bug triage meeting : ) Ha! The answer is somewhere in the middle of the options: - the patch is absolutely still valid for master, I build with this for everything I do - I've missed the cutoff for the release, but will immediately submit it for the next cycle - With CVEs, kernel-devsrc and this bug having some lively discussion about what is possible, the time to bike-shed this on the oe-core mailing list never came about. I'll update the target for this, do some tweaks and attach a new variant.
My patches are still complete/valid for this, but it is hard to commit to it in the 2.8 timeframe. I'll take it through another set of test cycles and then see if it can be ready by the M3 timeframe .. but I'm still leaving it as 2.99.
Bruce, Can we move this to a 3.1 milestone? If so pick one please.
(In reply to comment #29) > Bruce, Can we move this to a 3.1 milestone? If so pick one please. Does http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes?id=eac8f2f9ca26bf8cdb7f554803fd73c73b0b576e help this?
Created attachment 4649 [details] Patch for fragments for all kernels v2. Refreshing the reference patch to apply to latest master.
*** Bug 14064 has been marked as a duplicate of this bug. ***
Note that do_merge_config cannot be used without kernel-yocto with the current patch unless you add the 'depends' that are currently only set on kernel_configme in kernel-yocto either to your custom kernel_configme or to merge_config, as merge_config requires them as well.
This is still a valid concept, so bumping it to 4.2 for more consideration.
Bulk move of medium importance bugs from 5.1 to 5.2 on behalf of Bruce.