[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFUG7CeRy7FOhdnqWHUY_Veb3rU8PbxDj5jk+qy-QvQTdC3A8w@mail.gmail.com>
Date: Sat, 7 Nov 2026 12:09:57 -0500
From: Boris Lukashev <blukashev@...pervictus.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Nakashima Seiichi <s-nakashima@....biglobe.ne.jp>, kernel-hardening@...ts.openwall.com,
mic@...ikod.net, paul@...l-moore.com
Subject: Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack
surface reduction for the post-AI-CVE era
I try not to get into the politics involved so please don't put me in the
position of having to rebuke facile deflections predicated on evoking a
feeling shame in those of us managing the downstream effects by referencing
the nonexistent plight of overworked unpaid developers - devs are paid and
nobody at the top of the organization is taking a bus anywhere unless its a
shuttle between airport terminals connecting two first class flights.
That's an old and disingenuous argument which hasn't gotten any more
effective in the years its been made. Offhand we can look at the ongoing
convert proto_ops_bind callbacks situation: paid amazon employee so not
free, fixing regression in stable backports so not tested, and the rest of
the argument flies in its own face when 55 CVEs a day mean testing didn't
cover those previously (very naively) bringing the 75 fixes a day to 20 not
being for prior misses of which some are regressions themselves and some
fixes for the regressions. Linux maintenance isn't a gratis service done
out of the good of anyone's hearts for the world at large - as documented
here https://projects.propublica.org/nonprofits/organizations/460503801 it
takes in money, it pays people, and it participates in the commercial
ecosystem like any other vendor (producing profit as evidenced by a fair
deal of publications claiming 7f personal income for at least one of the
maintainers from the work - not exactly the image your stipulation seems
meant to evoke). There is nothing wrong with making money, it makes life
and enjoyment of it possible but please don't pretend there are noble and
altruistic motivations driving a commercial operation branding itself a
non-profit in 2026 - we live in an age when childrens cancer charities are
slush funds for politicians, its a thin veil at best. The GPL wall is still
used to prevent defense contractors and other innovators who harden linux
in a small closed space from taking that work commercial and directly
profitting from their forks despite upstream using non GPL code extracted
from LLMs; really puts the "care about security of the users" and "freedom"
premises into question. Finally, the ops engineer having to patch 10k
systems every 2d without losing revenue for the business takes home far
less than the maintainers but that person is the one who's job is on the
line/health getting trainwrecked when the patches themselves do not meet
muster/cause loss of revenue to the org. Mechanically, LF gets
compensated/early access to advanced LLMs from various providers, tools to
proactively find/remedy pathologies and classes of concern, and the
aforementioned contributions of cash and code from those same commercial
entities - that is monetary value which needs to come back as ROI to the
stake/shareholders of the companies providing it per the fiduciary
responsibility of executives signing off on the outflow, don't you agree?
To the point i was making before that unfortunate reiteration of what
industry already knows: the proposed approach isn't to send some heroic
contributors preloaded with tech debt into indentured corporate servitude
but to redirect commercial resources (however branded for legal purposes)
paid for by the revenue those downstream companies generate and put back
into LF as cash or tools to improve the products and services which they
sell.
-Boris
On Sat, Nov 7, 2026 at 7:04 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> On Fri, Nov 06, 2026 at 04:00:48PM -0500, Boris Lukashev wrote:
> > @Greg KH: there is no practical choice for using anything but what's
> > prescribed by the vendor and contractually supported in the commercial
> > world (further complicated by binary blobs/device trees/intellectual
> > property concerns/etc). You cant ask the hotel to change the kiosk
> > distribution to a safer one in order to check you in despite them having
> > your PII and payment data running through it any more than the rest of us
> > despite your undeniable awareness of the threat involved. It would be far
> > more realistic and practical for the Linux Foundation to assign its
> > seasoned talent to work on downstream distributions of economic relevance
> > to its member entities than to swap out the OS' in the clustered engine
> of
> > today's economy.
>
> So, it's not enough that the kernel developers and stable maintainers
> provide a free feed of 75 fixes a day in a tested and released kernel,
> and 55 documented CVE fixes a day, they then are required to, for free,
> take those patches and integrate them into for-profit company's kernels
> for them because that for-profit company doesn't want to pay for that
> effort to meet the contractual requirements that their customers pay for
> them to meet?
>
> If you take the "pure numbers" point of view, that means that we should
> do this only for Debian and Yocto as those distros hold the huge
> majority of all of the server and embedded systems numbers in the world,
> everything else is just a tiny percent. Oh wait, the LF already does
> this for you, for Yocto, and Debian is also free and up to date with all
> of these security issues for you to rely on.
>
> So again, why not hold the companies that you feel are worth paying for
> this service, responsible for meeting their own self-defined
> contractural requirements? Given that the community is giving all of
> this to them for free, it's odd that anyone would ask for us to do more
> work than that, don't you agree?
>
> greg k-h
>
--
Boris Lukashev
Systems Architect
Semper Victus <https://www.sempervictus.com>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
