lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 3 Jan 2021 15:30:30 +0900
From:   Masahiro Yamada <>
To:     Valdis Klētnieks <>
Cc:     Michal Marek <>,
        "David S. Miller" <>,
        Networking <>,
        Linux Kbuild mailing list <>,
        Linux Kernel Mailing List <>
Subject: Re: Kconfig, DEFAULT_NETSCH, and shooting yourself in the foot..

On Sun, Jan 3, 2021 at 5:14 AM Valdis Klētnieks <> wrote:
> Consider the following own goal I just discovered I scored:
> [~] zgrep -i fq_codel /proc/config.gz
> Obviously, fq_codel didn't get set as the default, because that happens
> before the module gets loaded (which may never happen if the sysadmin
> thinks the DEFAULT_NET_SCH already made it happen)
> Whoops. My bad, probably - but....
> The deeper question, part 1:
> There's this chunk in net/sched/Kconfig:
>         string
>         default "pfifo_fast" if DEFAULT_PFIFO_FAST
>         default "fq" if DEFAULT_FQ
>         default "fq_codel" if DEFAULT_FQ_CODEL
>         default "fq_pie" if DEFAULT_FQ_PIE
>         default "sfq" if DEFAULT_SFQ
>         default "pfifo_fast"
> endif
> (And a similar chunk right above it with a similar issue)
> Should those be "if (foo=y)" so =m can't be chosen? (I'll be
> happy to write the patch if that's what we want)
> Deeper question, part 2:
> Should there be a way in the Kconfig language to ensure that
> these two chunks can't accidentally get out of sync?  There's other
> places in the kernel where similar issues arise - a few days ago I was
> chasing a CPU governor issue where it looked like it was possible
> to set a default that was a module and thus possibly not actually loaded.

If there is a restriction where a modular discipline cannot be the default,
I think you can add 'depends on FOO = y'.

For example,

           prompt "Default"

           config DEFAULT_FOO
                  bool "Use foo for default"
                  depends on FOO = y

           config DEFAULT_BAR
                  bool "Use bar for default"
                  depends on BAR = y

           config DEFAULT_FALLBACK
                  bool "fallback when nothing else is builtin"


Best Regards
Masahiro Yamada

Powered by blists - more mailing lists