Software-update: Linux Kernel 5.8

Linus Torvalds heeft versie 5.8 van de Linux Kernel vrijgegeven. De kernel is het hart van het besturingssysteem en zit, simpel gezegd, als laag tussen de hardware en de applicaties in. Nieuw in versie 5.8 is onder meer een energy driver voor de Zen en Zen 2 cpu's van AMD, ondersteuning voor Thunderbolt en de igp uit de Intel Tiger Lake cpu's en Trusted Memory Zones in AMD gpu's, wat het aanspreken van versleuteld videogeheugen mogelijk maakt. Meer informatie over de verbeteringen in deze release is te vinden bij Phoronix. Hieronder is een overzicht van de belangrijkste verbeteringen in Linux Kernel 5.8:

Graphics:

• Qualcomm Adreno 405 / 640 / 650 open-source support.
• AMDGPU TMZ support with Trusted Memory Zones for encrypted video memory.
• Intel Tiger Lake SAGV support and other Gen12 graphics updates.
• Radeon Navi/GFX10 soft recovery support.
• The Radeon driver also now better handles critical thermal faults.
• P2P buffer/DMA support between GPUs.
• Other updates too like Lima run-time power management, Nouveau support for NVIDIA format modifiers, and more.

Processors:

• The AMD Energy Driver was merged for (finally!!!) exposing the Zen/Zen2 energy sensors on Linux.
• AMD Ryzen 4000 Renoir temperature and EDAC support.
• Nested AMD live migration with KVM is now supported.
• Loongson 3 CPU support for KVM virtualization.
• Spectre mitigation fixes also being back-ported now to the stable series.
• Boost support for the CPPC CPUFreq driver.
• PCIe NTB support for Ice Lake Xeon servers.
• RISC-V Kendryte K210 SoC support has been wrapped up.
• New Arm SoC and platform support.
• Initial support for booting POWER10 processors.
• AMD Zen/Zen2 RAPL support for run-time average power limiting.
• Intel TPAUSE power-optimized delays support for Tremont cores and newer.
• Tightened Arm 64-bit security with now supporting Branch Target Identification (BTI) and the Shadow Call Stack.
• XSAVES supervisor states support, Memory Bandwidth Monitoring Counters, and other x86 (x86_64) updates.

Storage / File-Systems:

• A block device back-end for Pstore in saving oops/panic messages to disk.
• ERASE/Discard/TRIM support for all MMC hosts rather than being opt-in previously.
• F2FS LZO-RLE compression support is added for this flash optimized file-system.
• Microsoft exFAT driver improvements courtesy of Samsung.
• Support for emulating MLC NAND flash memory as SLC.
• A performance optimization for Xen 9pfs.
• SMB3 performance work for large I/O.
• Fixes for EXT4.
• Improved DAX support for direct access on persistent memory storage.
• Various Btrfs improvements.

Other Hardware:

• Habana Labs Gaudi support for this AI inference accelerator.
• Intel Tiger Lake Thunderbolt support as well as ComboPHY support for Intel's Gateway SoCs.
• Support for Thunderbolt on non-x86 systems.
• The possibility of significant power-savings for motherboards with PCIe to PCI/PCI-X bridges.
• Peer-to-peer DMA for AMD Raven and Renoir.
• AMD Renoir ACP audio support.
• Cable Testing Infrastructure in the Linux network code albeit initially limited to select hardware/drivers.
• Restoring the Intel Atom (AtomISP) camera driver.
• Support for swapping Fn and Ctrl keys on Apple keyboards.
• Numerous power management updates.
• AMD SPI controller driver was merged.

General Improvements:

• Jitter RNG improvements and landing of the Arm CryptoCell CCTRNG driver. AMD PSP SEV-ES support is also part of the crypto updates.
• The Kernel Concurrency Sanitizer has been merged with KCSAN helping to detect race conditions in the kernel and has already been used for uncovering dozens of real bugs.
• Staging and IIO updates.
• Scheduler optimizations.
• A general notification queue initially wired up for notifying on key/keyring changes.
• SELinux optimizations.
• Modernization improvements for Procfs with now supporting private procfs instances.
• A new initrdmem= option that among other use-cases can be used when replacing Intel ME space with an initrd image in the saved flash area.
• L1d cache flushing on a per-context basis as an opt-in feature was originally merged. However, Linus Torvalds ultimately reverted it for now as in the current implementation is "beyond stupid".

Versienummer	5.8
Releasestatus	Final
Besturingssystemen	Linux
Website	Linux Kernel
Download	https://www.kernel.org/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (34)

[SherlockHolmes]

Ik heb meerdere keren van mensen gehoord, waaronder Linus Torvalds, dat dit de grootste upgrade ooit van de kernel is. Wat is hier zo speciaal aan? Ik zie geen gigantische veranderingen - maar ik ben ook een redelijke beginnende Linux user.

[rover87]

Het heeft er mee te maken dat veel code is opgeschoon en enorm veel code is verwijderd. Klopt dat de features dit niet reflecteren maar er is veel veranderd "under the hood"

[Munchie]

So in the 5.8 merge window we have modified about 20% of all the files
in the kernel source repository.

In pure numbers: over 14k non-merge commits (over 15k counting
merges), ~800k new lines, and over 14 thousand files changed.

Via https://lore.kernel.org/[e-mail]/

[UPPERKEES]

Linux releases zijn zeer kort op elkaar. Dus grote kernel changes zoals Windows 8 naar Windows 10 veranderingen ga je niet zien. Relatief gezien is dit inderdaad een grote update met relatief veel changes.

[MeMoRy]

However, Linus Torvalds ultimately reverted it for now as in the current implementation is "beyond stupid".

Dat klinkt alsof hij weer terug bij zijn oude gedrag is xD

[Douweegbertje]

Nooit weg geweest, net zoals het gedeeltelijk uit context plaatsen. Voor de volledigheid:

At a _minimum_, SMT being enabled should disable this kind of crazy
pseudo-security entirely, since it is completely pointless in that
situation. Scheduling simply isn't a synchronization point with SMT
on, so saying "sure, I'll flush the L1 at context switch" is beyond
stupid.

En

I'm more than happy to be educated on why I'm wrong, but for now I'm unpulling it for lack of data.

Ik ben blij dat er zo'n persoonlijkheid als Linus er zit. Om eerlijk te zijn proberen vaak genoeg bedrijven dikke stront door te pushen en in "de wereld" wordt dat maar vaak genoeg geaccepteerd. Wat dat betreft is dit een blessing.

[RxTweak]

Inderdaad, Linus Torvalds weet het ook weer prachtig te verwoorden...

In other words, from what I can tell, this takes the crazy "Intel ships buggy CPU's and it causes problems for virtualization" code (which I didn't much care about), and turns it into "anybody can opt in to this disease, and now it affects even people and CPU's that don't need it and configurations where it's completely pointless".

Volledige artikel: https://www.phoronix.com/...Linux-Blasts-L1d-Flushing

[Reactie gewijzigd door RxTweak op 26 juli 2024 11:01]

[goarilla]

Dat klinkt alsof hij weer terug bij zijn oude gedrag is xD

Die kerel is gewoon obsessief over kwaliteit en daar geef ik hem alle gelijk in.

[OMEGA_ReD]

Is deze kernel gewoon te installeren op Ubuntu 20.04 server zonder dat de secure boot over de toeren gaat? Bij de vorige update moest ik een rollback doen omdat hij niet gesigned was.

Heb het draaien op een NUC hier thuis maar die secure boot geeft me af en toe hoofdpijn. Tijdens de setup werd het aanbevolen omdat een aantal os features er afhankelijk van waren.

[Reactie gewijzigd door OMEGA_ReD op 26 juli 2024 11:01]

[hackerhater]

Normaal wel zolang je grub (het deel wat gesigned is) met rust laat.
Maar geen garanties. Maar waarom zou je de nieuwste kernel op een server willen?

[Verwijderd]

Hou er wel rekening mee dat een mainline kernel nog niet per se geschikt is voor een specifieke distro. Ubuntu zal nog de nodige patches en aanpassingen doen aan kernel 5.8 voordat deze officieel beschikbaar komt. Zeker op een server zou ik gewoon op de Ubuntu kernel wachten.

[beerse]

Om te beginnen zou ik bij ubuntu in de development lijn gaan zien wanneer ze naar deze kernel gaan. Dan heb je in ieder geval de ubuntu specifieke zaken mee genomen. Wil je verder zie dan hoe zij het doen,

Met custom kernels heb je met secure boot altijd een uitdaging: Secure boot is er onder andere voor dat er gecontroleerd wordt of er met de kernel is geklooid. En ja, een nieuwe kernel wordt door secure boot gezien als geklooid.

[terradrone]

Ik vraag me af, bij nieuwe kernel releases, soms in een moment van onverschilligheid, hoe men überhaupt gaat pogen bestaande hardware/drivers te supported op deze nieuwe releases.

Anders gezegd: er is zo verschrikkelijk veel hardware in omloop, vaak SOC based ,en nog veelal niet zo heel oud, wat op heel oude kernels draait, en wat helemaal niets aan development ontvangt. Want zoals bekend: hardware bakken is relatief goedkoop, software development relatief kostbaar.

Om bestaande hardware te "tillen" naar nieuwe kernel releases kost vaak zo enorm veel effort , dat het soms een onmogelijkheid lijkt.

En dan moet het nog zo zijn dat er überhaupt meegewerkt wordt vanuit hardware vendors; als er enkel binary blobs voor oude kernels beschikbaar zijn dan wordt het verhaal al helemaal dramatisch.

Wellicht dat iemand met meer kennis en ervaring mbt kernel development hier zijn/haar licht op kan schijnen.

[Jazco2nd]

Als je drivers zou moeten reverse engineeren had je gelijk. Maar het zijn juist de fabrikanten (met name AMD in deze release) die dit gewoon regelen.

[terradrone]

Nu heb je het over amd, maar ik doel juist op de talloze SOC producenten, zoals rockchip, amlogic, allwinner, freescale, hisilicon, marvell, solidrun, stmicroelectronics en ga zo maar door. Bovendien houden veel van deze fabrikanten zich niet eens aan gpl, wat het al helemaal onmogelijk maakt code te porten naar mainline:

https://linux-sunxi.org/GPL_Violations

[N8w8]

De Linux gemeenschap doet gewoon zijn ding en dat werkt goed.
Veel hardware vendors doen daar ook goed aan mee, zorgen voor open source drivers en werken samen met de gemeenschap aan het mainlinen ervan etc.

Dat er ook hardware vendors zijn die daar niet aan meedoen, jammer natuurlijk.
Maar (muv GPL schending) zijn ze daar gewoon vrij in.
Als een vendor ervoor kiest om niet mee te doen met hoe het werkt in Linux land, en er ook geen derde partij is die de support ervan regelt, dan houdt het op.
Het is niet de verantwoordelijkheid van de Linux gemeenschap om vendors die niet mee willen doen te accomoderen. Ze werken samen met degenen die willen samenwerken, niet met degenen die dat niet willen.
En als n vendor niet wil samenwerken, dan is het ook aan de vendor zelf om al dan niet support voor nieuwere niet-mainline kernels te regelen, daar heeft ie immers zelf voor gekozen.
Vandaar die "onverschilligheid"; men besteedt liever aandacht aan de partijen die meedoen.

Als je als consument hardware wilt hebben met goeie Linux support, dan kan je ervoor kiezen om hardware te kopen met goeie Linux support.
Koop je hardware die dat niet heeft, dan spreekt het voor zich dat je het zal moeten doen met de Linux versie(s) die de vendor jou geeft.
iig, zoals ik het zie, als mijn eis goeie mainline Linux support is, en bepaalde hardware heeft dat niet, dan is die hardware ongeschikt voor mij en negeer ik die gewoon.

Het blijft natuurlijk jammer dat er veel consumentenspul in omloop is met oude kernels en gesloten drivers enzo. Maar je kan vendors nou eenmaal niet dwingen om goed mee te doen.
Als het verplicht zou zijn om goed mee te doen, dan hadden ze mss wel iets heel anders dan Linux gekozen. Zo bekeken is het ook wel een mooi iets dat ze toch Linux hebben kunnen gebruiken.

Maar er wordt wel gewerkt aan dat te verbeteren hoor, ik moet vooral denken aan Linaro, die heeft enorm veel werk verzet qua ARM mainline ondersteuning, dat is nu veel beter dan 10-20 jaar geleden. Maar dan moet nog steeds de vendor ervoor kiezen om samen te werken, of moet een derde dat willen doen.

De SoC producenten die je noemt "en ga zo maar door", je doet het voorkomen alsof die allemaal slechte support hebben, maar dat is niet waar.
Veel SoCs worden best goed ondersteund, mede dank zij de fabrikanten zelf.
Groot probleem is nog wel GPU drivers, ben daar niet genoeg in thuis om veel over te zeggen, maar die zijn vaak closed source om bepaalde redenen.
Maar ik geloof wel dat Qualcomm (mss via Codeaurora) het nodige bijdraagt aan de open source Freedreno driver.

Ja en los van ondersteuning van zulke grote losse "chips", moet de vendor van het complete eindproduct, ook eea doen om te zorgen voor mainline Linux support van alle peripherals die ze in hun apparaat hebben gestopt.
Bij PC's is dat veel makkelijker dankzij UEFI/ACPI/BIOS, maar ARM heeft dat meestal niet dus moet de Linux support niet alleen per onderdeel maar ook per apparaat worden geimplementeerd.

[terradrone]

Voor bepaalde gpu's in soc's zijn zelfs helemaal geen linux drivers. Hieruit is bijvoorbeeld panfrost ontstaan, een poging om een FOSS driver voor linux hiervoor te ontwikkelen. Het gaat dan om de inmiddels "beruchte" gpu in de amlogic s912 soc.

https://panfrost.freedesktop.org/

https://www.collabora.com...w-of-the-panfrost-driver/

"Bij PC's is dat veel makkelijker dankzij UEFI/ACPI/BIOS, maar ARM heeft dat meestal niet dus moet de Linux support niet alleen per onderdeel maar ook per apparaat worden geimplementeerd."

Daar sla je de spijker op de kop; bij x86-64 uefi/bios systemen bestaat er een relatief sterke uniformiteit in systeem architectuur , wat bij al die verschillende arm en mips soc's niet het geval is. Met als gevolg dat er bijv een wildgroei aan sbc's is ontstaan, velen met erg matige software support.

Hoe is alles anders aan de andere kant vh spectrum, in de wereld van enterprise computing, waar juist heel veel tijd (en dus geld) wordt gestoken in ontwikkeling (in linux) om juist systemen ultra stabiel te laten werken. Het zijn ook de grote spelers die veel bijdragen een de codebase van linux.

[N8w8]

Ja het probleem is duidelijk, maar ik dacht dat je vraag was, wat eraan te doen (mijn idee was samengevat "niet kopen"), maar mss had ik dat verkeerd begrepen.

Ik zie het in zekere zin als 2 verschillende OS'en; Linux mainline, en Linux van de vendor.
Linux mainline heeft er op zich weinig last van als vendors niet meewerken en hun eigen kernel maken voor hun apparaat. Maar dan is t dus wel begrijpelijk dat mainline die vendors niet gaat accomoderen en ze gewoon doorgaan met degenen die wel meewerken.
Als vendors hun eigen kernel maken, dan is het ook aan hun om die te vernieuwen.
Maar die nemen idd vaak 1 kernel versie en zolang het werkt en het product niet EOL is, prima.

Als consument heb je dan de keuze, neem ik iets dat Linux mainline draait, of neem ik iets met zo'n vendor kernel.
Die hele wildgroei aan slecht ondersteunde SBCs hoeft dan niet jouw probleem te zijn; die kan je gewoon links laten liggen.
Of als je een leuk shiny apparaat ziet met vendor Linux, dan weet je dat die mss geen kernel upgrades krijgt en kan je dat feit meenemen in je aankoop beslissing.

Maar goed, wat ik (en jij) al zei, alleen die GPU drivers nog dus.
Wat ik zei, ik ben daar niet zo in thuis, maar dat is zo'n beetje het enige pijnpunt vziw.
Ja en die GPU drivers zitten vaak ook niet eens in de kernel maar vooral in userspace.

Voor de rest (en al helemaal als je geen 3D/video nodig hebt) zijn er allerlei opties met goeie mainline support.
Het gebrek aan UEFI etc maakt daarvoor weinig uit; enige verschil is dat een vendor bij een ARM apparaat, de board support moet verwerken in Uboot en Linux, in plaats van in de UEFI firmware. Maar is in de kern verder hetzelfde lijkt mij.

[geoffrey.vl]

Zoals je ziet in deze kernel release zit er o.a. ook driver support voor bepaalde Qualcomm GPUs. Er zijn daarnaast nog wel gelijkaardige open bron alternatieven van populaire gesloten drivers, bijvoorbeeld de RPi GPU driver, of de Freescale Community dingen. Maar je hebt ook wel gelijk, er zijn nog (te veel) dingen gewoon gesloten en gebonden aan oude kernel release. Heb je iets populair dan kan je vaak terugvallen op de community, maar dat is zeker niet altijd het geval.

[Lennie]

Zou wel eens kunnen dat het zo werkt, zie het test-programma (er is dus een nieuwe syscall die je moet gebruiken):

https://wiki.linux-nfs.or...py#Userspace_test_program

Ik zag ook nog in een oude presenatie:

"Security a big issue, requires updated security model (RPCSEC_GSS Version 3) "

https://www.snia.org/sites/default/files/NFS_4.2_Final.pdf

Dus mogelijk is er een afhankelijkheid met bepaald type authenticatie ?

[Reactie gewijzigd door Lennie op 26 juli 2024 11:01]

[Arjan Scholl]

Support for Thunderbolt on non-x86 systems.

Zou Apple hier wat mee te maken hebben nu dat ze Thunderbolt gaan ondersteunen op hun ARM based Apple Silicon?

[- peter -]

Denk vooral dat USB4 wat thunderbolt inbegrepen heeft hiervoor zorgt.

[Jazco2nd]

Ik ga dit maar gewoon hier vragen:
NFSv4.2 zit al poosje in de kernel en ondersteund server sided file copy. Ongelooflijk handig anders wordt alles 2x over het netwerk gestuurd. Toch is er 0.0 documentatie hoe je dit werkend krijgt. Ik heb veel geprobeerd.

Is SMB dan de toekomst voor Linux?

Zie oa de documentatie die hier wordt genoemd: https://github.com/Jakele.../8#issuecomment-626967559

[Reactie gewijzigd door Jazco2nd op 26 juli 2024 11:01]

[wica]

Ik heb dit niet uit gezocht. Maar meestal als server en cliënt de zelfde features hebben. Wordt het automatisch enabled.

[Jazco2nd]

Heb het geprobeerd met Ubuntu 19.10.. veel tijd aan besteed maar kreeg het niet werkend.

[Raventhorn]

Heb het zelf niet geprobeerd, maar wellicht dat deze guide wat wil helpen? Al zal je die zelf wellicht ook al gevonden hebben...

[Jazco2nd]

Dit is een generieke en verouderde guide. Nieteens v4.0. laat staan 4.2 die server side copy introduceert.

Je hebt er dus niks aan. Als jij remote op een server inlogt via NFS en bestanden wil knippen/plakken, gaat hij dat eerst naar je eigen pc downloaden. En daarna uploaden naar de nieuwe map, op dezelfde remote server.

[Raventhorn]

Via deze link kom ik dezelfde packages tegen voor de v4(.2) client; althans, dat is wat ik vermoed op basis van de vers=4.2 in de mount config...( cat /proc/mounts | grep mnt )
Wellicht dat het meegeven van -o vers=4.2 tijdens het mounten noodzakelijk is? (ik zie daar zo snel enkel iets voorbij komen als je v3 gebruikt, maar wellicht dat het voor 4.2 ook werkt of nodig is )

K snap verder precies wat je bedoeld; het is nogal zonde om die data continu heen en weer te sturen, zeker als het enkel van map wisselt... Een verplaatsing op disk is zo gebeurd, een flinke backup heen en weer sturen niet...

Nu begin ik zelf ook nieuwsgierig te raken, ik ga van de week eens spelen met een paar VM's...

[Jazco2nd]

Het gaat mij er meer om dat er zo weinig documentatie is en dat het een onbekende feature is, waarvan de meesten verwachten dat het standaard zo werkt.

Toont toch aan dat men NFS wellicht allang niet meer gebruikt en het overbodig is geworden?
In Ubuntu heb je File Share in de UI. Dat is gewoon SMB/Samba!

[noskill]

Ik beheer een mixed Windows/Linux omgeving en mijn idee was alles naar SMB over te zetten. Linux gebruikers kunnen niet symlinken op een CIFS-share... In mijn omgeving was SMB ipv NFS daardoor alleen al een no-go.

Over server-side copy:

NFS COPY is a new operation which can be used by the client to request that the server locally copy a range of bytes from one file to another, or indeed the entire file.

However, NFS COPY requires use of the copy_file_range client system call. Currently, no bundled utilities in Linux distributions appear to make use of this system call, but an application may easily be written or converted to use it. As soon as support for the copy_file_range client system call is added to client utilities, they will be able to make use of the NFSv4.2 COPY operation.

Note that NFS COPY does not require any special support within the NFS server filesystem itself.

Lijkt er dus op dat het standaard ingeschakeld is, maar dat de copy tool een specifieke system call moeten gebruiken om de files te kopieren. Misschien kan je iets vinden dat die system call gebruikt, al lijkt Oracle van mening te zijn dat daar op dit moment nog niets voor bestaat.

Source: https://blogs.oracle.com/...terprise-kernel-release-6

[Jazco2nd]

Hmm, de NFSv4.2 specificatie dateert van 2016. Ik verwacht niet dat hier nog iets voor zal komen.

[Jogai]

Fijjne release voor de gebruikers van de laatste Ryzen CPU's

[MewBie]

Ja, hopelijk wat verbeteringen op mijn nieuwe laptop met Ryzen 5 4500U.
Sommige zaken zijn nu alsof je 20 jaar terug gaat in de tijd omdat veel dingen net niet helemaal lekker werken.

[machiel]

AMD had wel een inhaalslag te maken. Ze lijken nu lekker op stoom.