Misschien een enkeling, maar Linus sprak over _maintainers_ . Ik denk niet dat er een maintainer is die hier meeleest. Dat is anders dan een willekeurige 'kernel hacker' .
Een willekeurige kernel hacker werkt aan een bv een driver, of een onderdeel van een subsysteem.

Een maintainer is verantwoordelijk voor een totaal subsysteem (bv 'VFS' , 'Networking', 'scheduling') , een architectuur port, of een oude kernel release.

Linus zelf is overall maintainer van de huidige kernel , en de maintainers zijn de mensen met wie hij rechtstreeks werkt.

Een maintainer moet een combinatie van eigenschappen hebben : een uitstekende ontwikkelaar met een brede en heel grondige kennis van het subsysteem , en de interactie met andere kernel delen, zicht op (heel) lange termijn , "goede smaak" qua code , effectief kunnen werken met mensen die code submitten - waaronder "nee" zeggen , (hetzij hard , hetzij zacht).
En dan ook nog langdurig beschikbaar .
En , zoals Linus zegt - met 'trust from the community' . Oftewel, lang genoeg bijgedragen aan de kernel dat mensen vertrouwen in je kunnen - en in je persoon - hebben.

Wel, no shit , daar zijn er niet zoveel van.

Je krijgt wel een beeld van de stijl van werken - en diepte van inzicht - als de kernel mailinglist leest en de bijdragen van de top maintainers volgt. Zeker als er gebrainstormed wordt over toekomstige wensen, of een echt subtiele bug uitgevogeld wordt zie gewoon hoe goed - en hoe breed de achtergrond is - van de kernel toppers.

@ anoniem van heden,

Dank voor je gewaardeerde inzichten. Mij interesseert vooral de achtergrond van "bewust veilig"
en waarom en hoe dat in te richten?

Ik kreeg NT4 en de kernel onderwezen vlak na de eeuwwisseling te midden van allemaal linux admins,
die het verplicht moesten gaan uitrollen in hun ziekenhuis-omgeving of binnen de transportsector.
"Let op", luidde het dan, "Kijk wat Windows event viewer allemaal mist hier.
Twee dikke Windows NT4 en de kernel- tomen staan hier nog voor me.

Zelf draai ik o.a. Libre Office en een aangepaste versie van bobby's Malzilla malware-analyse browser.
Ook snort en SNYK onder the command prompt.

Nu ben ik voornamelijk DOM-XSS issues aan het analyseren qua sources & sinks.
Dat o.m. aan de hand van o.a. bekende retirable jQuery-scripts via Retirable.JS, de-minnifying,
o.a. bootstrap.min.js code en het nalopen van kwetsbaarheden o.a. ook op inline scripts
en kwetsbaarheden op webservers (bijvoorbeeld recent veel bij nginx-header code)
via de developer's console in de webbladeraar.

Mij gaat het dan om best policies en practices en waarom die gehanteerd moeten worden.

Helaas komt code kwalificeren ook steeds minder vrij van cyberwar-politieke factoren.
Dan beoordeelt men vervolgens uw Chinese chat app als PHISHIN'
en dan blokkeren we die gewoon, als ons dat qua positionering beter uitkomt.

De zuivere open "puristen tijd"van resource hackers en searchlore guru's als F.R.A.V.I.A
(ik ben een vroege discipel van hem met bijdragen over weak PHP en cgi)
ligt reeds lang achter ons. Vrijwel alles is heden ten dage overwoekerd. door ads & smut.
Een figuur als Fravia (R.I.P.) zou zich in zijn graf omdraaien.
Ook Giorgio Maone krijgt ook steeds minder ruimte met zijn NoScript script blokker extensie.
Goed dat er nog uMatrix overal kan draaien.

De dominante propriety-only-software spelers zitten al met veel te veel vingers in de digitale pap onderhand.
TRUST is een goedkope term geworden online. Daarom zullen we linux meer nodig hebben dan ooit
tevens als "advocaat van de duvel".

luntrus

Heel lange knip over browser security en maatschappij - dat staat allemaal nogal ver van een kernel , waar je het topic mee begon. Tip : neem een andere thread.

Ik zag geen relatie met je link naar kernel hacking en het wel of niet disablen van soft IRQs naar een bepaalde cpu core .
(Dat heeft te maken met met scheduling, niet speciaal met security).

Voor wat betreft de kernel en security - werk een steeds gedetailleerder access control van allerlei resources (niet alleen files) gebeurt via onder andere selinux , apparmor en het 'integrity subsystem' .
De kernel krijgt 'KASAN' - kernal address sanitizer' - om memory leaks e.d. sneller te vinden.
En KASLR - kernel address space layout randomization .

Verder zie je dan (met de nodige discussie) dingen voor trusted boot verschijnen.

Google heeft project Titan (niet alleen die keys, maar een hardware module ) .
(google haters zijn al gestopt met lezen, maar google doet serieus veel moeite om te zorgen dat buitenstaanders niet in hun infrastructuur kunnen )
https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext
zie https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html

Als je echt belangrijk genoeg bent als target begint je security zorg bij het hardware platform.
Dat speelt des te meer als een 'trusted omgeving' niet bestaat - bij een mobiel device moet je ervan gaan dat een tegenstander fysieke toegang kan krijgen, zelfs uitgebreid en langdurig.

Maar het overgrote deel van security werk zit in de applicaties .

Ik heb de 1e 2 jaar ofzo wel een paar keer wat bijdragen geleverd en een jaar of 2 geleden heb ik nog geprobeerd een
2-regelige patch er door te krijgen maar ik heb het opgegeven door de bureaucratie die er tegenwoordig is.
Zou me niks verbazen als er veel meer mensen om die reden afgehaakt hebben...

Zelf heb ik een keer ondervonden dat een Linux kernel-driver (video) brak bij een kernel update. Patch geschreven en deze gemailed naar de main-developer in Frankrijk. Een paar maanden later bleek dit te zijn meegenomen; het bubbelde automatisch over alle linux-distros.

En het afbrandrisico: je loopt kans dat je in plaats van dank verwensingen naar je hoofd krijgt geslingerd.

Ik snap wel dat Linus hoge eisen stelt. Overigens, bureaucratie in de vorm van regressietesting is goed. Je wilt niet dat jouw patch ergens iets kapot maakt of degenereerd.

Er zal ook wel veel recruiting plaatsvinden door allerlei bedrijven - zoals Microsoft - die naar mensen zoeken. Ook al hebben ze zelf totaal geen verstand van of respect voor hoe open source werkt. Open source is niet hier en daar een symbolisch bedragje doneren, de code nemen en een close-source fork beginnen. Dat mag je gerust als parisitair beschouwen.

@anoniem van 18:22

Vergeef mijn nieuwsgierigheid en barst maar los.
Er komen hier altijd wel enkele lieden voorbij met gelijkaardige interesse(n).

En als je het goed met jezelf en anderen voor hebt, ben je nooit te oud om bij te leren
en verdere kennis te verwerven. Hier leert men de jeugd en de ouderdom.

De goede code analist "hongert" a.h.w. naar verdere en diepere inzichten;
dit om de juist niet zo voor de hand liggende zaken te combineren.

Zo is elke kernel hack begonnen ooit, om systemen bepaalde onverwachte dingen te kunnen laten doen.
Dan komen zaken zoals hieronder geschetst ook voorbij.

Zie hier wat hen onder meer kan bezig houden:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINTAINERS?id=v5.8-rc3&id2=v5.8-rc2
om later te kunnen worden gebruikt voor functies in operandi.

Zie tevens deze draad: https://lkml.org/lkml/2020/6/18/6
Dan moeten we %pUb gebruiken bij Linux en %pUl in het geval van OP-TEE
(bepaald door het verschil in het aangewende big en little endian formaat).
Info credits gaan hier naar Jasper Spaans.

Er wordt daarbij nogal wat vooraf bekende kennis en ervaring vereist om dit goed te kunnen evalueren.
Dan zit je echt al een eind op niveau Technische IT specialisatie met inzicht.
Zeker niet iets voor de "fainted of heart", maar wel bere-interessant om in het achterhoofd te hebben,
als cold recon security-researcher.

Vandaar mijn aanvankelijke vraagje na de overpeinzing vanwege het artikel in The Register (UK).

luntrus

Het was een patch om iets instelbaar te maken wat hardcoded was, dmv een parameter van een module.
Als de parameter er niet was dan werkte alles zoals voorheen. Kans dat er iets kapot ging leek me 0.
Ik heb heen en weer gemaild met de maintainer van die module en nadat ik eerst 3 keer de patch anders heb aangeleverd
(terwijl hij zelf die code in de source had kunnen plakken als het format hem niet beviel) en een paragraaf tekst had
aangeleverd wat die parameter deed, moest ik ineens een dissertatie gaan schrijven over het hele onderwerp om het
geaccepteerd te krijgen. Toen ben ik er maar mee gestopt.
Het was fijn geweest als deze patch geaccepteerd was, maar het is mogelijk om er omheen te werken met een stukje
hardware dus dat doen we dan maar...

Het goed representeren van hardware kan inderdaad lastig zijn. Zeker als er soms nieuwe gevallen komen met een stijl die niet goed past .
En inderdaad kan endian-ness zichtbaar worden , hetzij vanuit native hardware, hetzij vanwege een protocol standaard keuze die los staat van het platform.
(uuh. pci brug achter een pci brug , staat me vaag bij als het soort ding . Het gebruikte model had nog geen voorziening voor een twee-laags bereikbaarheid).

Taaldingetje: 'Faint of heart' ,(Of 'Faint-hearted' ) . Niet Fainted of heart.

Wat snap ik niet helemaal wat je bedoelt te zeggen met die link naar maintainers diff ?
Soms houden maintainers op en adopteert iemand anders de code, en soms veranderen ze alleen maar van werkgever en/of email-adres .
Overigens - ondanks de generieke term 'maintainers' in die file - je ziet duidelijk in het Register interview verslag dat Linus' specifiek praat over een krapte aan "maintainers" in de zin van mijn antwoord van 11:16 .
Dat is een kleine subset van de mensen in de 'maintainer' file.

Voor een tweetal voorbeelden van echt architectuur discussie (de details zijn moeilijk te volgen, de stijl niet)
zie bv
http://lkml.iu.edu/hypermail/linux/kernel/2006.3/01022.html
http://lkml.iu.edu/hypermail/linux/kernel/2006.3/00964.html

Christoph Hellwig , Oleg Nesterov, en Peter Zijlstra zijn wel _maintainers_ .
Linus claimt wel in interviews dat hij 'nog amper code schrijft' , en dat is misschien wel letterlijk waar geteld in regels code, maar als je die discussie ziet is het wel duidelijk dat hij volkomen en in detail betrokken is met een aantal fundamentele kernel zaken.
Je moet z'n uitspraken dat hij 'amper meer code schrijft' niet interpreteren alsof hij een project manager en gepensioneerde mascotte geworden is.