Question on the decision making process for kernel variants' configurations

Khaled Elmously khalid.elmously at
Thu Mar 10 21:26:01 UTC 2022


On 2022-03-10 13:02:03 , Lexi Haley wrote:
> Hello and greetings,
> I am attempting to gain some insight into the decision making process that
> goes into the kernel configuration choices selected for a given variant
> kernel.  I have rummaged around the Ubuntu Kernel Wiki, applied search
> strings to the downloaded kernel-archive mailing list mbox, and bounced
> around on the Ubuntu Launchpad - all without finding either information on
> the general review process, or finding specifics on the particular detail
> I'm interested in.
> What am I interested in exactly?  In the gcp kernel variants the
> CONFIG_UNICODE (UTF-8 normalization and casefolding support) option is
> disabled.  This configuration option arrived via (assuming I've trawled
> around correctly):
> , and was set to unset (off).
> As to why, there are two guesses I might make:
> One: As the gcp kernel variant already exists with a set of known
> configuration values, perhaps anything new and considered optional is left
> unset, until such time as an issue is made asking for it (example,
> - perhaps I
> should submit an issue?
> Two: Perhaps this specific configuration was left unset per concerns a la
> - in which
> case submitting an issue would probably not be fruitful?  ( though I
> believe the post
> makes a nice case for why the CVE isn't precisely cause to leave this
> unavailable).

I think your guesses are mostly accurate.

The Ubuntu variant kernels are based on the Ubuntu master kernels, which are in 
turn based on the mainline kernels (plus patches from upstream stable kernels).
At any stage, we generally make changes only as necessary.

That necessity can come from any of several places. It can come from our
own needs/testing, or in the case of something like the cloud kernels, it
can come as a request from the cloud partner, or it can come from users 
who call our attention to specific things. It can be for CVEs or 
bug-fixes, or it can be for feature-enablement. There is no one hard rule.

I do not know why CONFIG_UNICODE specifically is off. My guess is that we just 
simply had no reason to change the default value. (That CVE that you mentioned 
appears to be a git CVE, not a kernel CVE, so it may not be relevant).

CONFIG_UNICODE is enabled in the main kernels and in the 5.15 gcp kernel. I 
am not aware of a reason that prevents it from being enabled for the 5.4 gcp 
kernel too.

I have created this bug to track the issue:

Feel free to add any additional info.

> And of course, the rationale might be something I have no clue at - So I am
> asking if someone might point me in the right direction - either towards
> the background information I seek, or perhaps specifically suggesting that
> I open an issue.
> My thanks, and I appreciate your time,
> Lexi Haley
> -- 
> Lexi Haley (she/her/hers)
> Computer Scientist, System Tools, Advanced Technology Division
> Medical Information Technology, Inc.
> Office: 781-774-5156 | Mobile: 508-713-2499
> lhaley at
> MEDITECH Circle, Westwood, MA 02090
> Main: 781-821-3000 | Fax: 781-821-2199
> *Diversity at MEDITECH* <>
> -- 
>  <>             
> <> <>   <>
> Subscribe 
> <> 
> to receive emails from MEDITECH or to change email preferences.
> COVID-19 
> Customer Resources 
> <>

> -- 
> kernel-team mailing list
> kernel-team at

More information about the kernel-team mailing list