Omdat ARM staat voor een reduced instructionset is machinecode eenvoudiger, wat de kans op zwakheden verkleint. Dit geld niet voor de fouten gemaakt door een programmeur of compilerfouten.

Kort door de bocht: Een reduced instructionset zoals ARM en RISC-V verminderen voor een deel de kans op kwetsbaarheden, mits juist geprogrammeerd.

Eigenlijk is ARM in het leven geroepen om via de reduced instructionset een snelheidsvoordeel te behalen met minder zware hardware (goedkopere hardware productie). De voordelen op security zwakheden is eigenlijk bijvangst en minimaal. Echter de gelimiteerde instructie-set levert wel eens wat uitdagingen op.

Nadelen zijn er ook, de randapparatuur voor ARM moet hierdoor veelal voorzien van eigen microcontrollers, waar x86 nog wel eens e.a. kan afhandelen of emuleren. Kan ook een voordeel zijn. Agile hardware.

ARM is flexibeler/efficiënter in het afhandelen van het e.a (geheugen) omdat er geen x86 stuctuur geldt (nog steeds een 640kb limiet).

ARM is vooral veel zuiniger dan x86. Mullticore afhandeling was vroeger veel beter in ARM, tegenwoordig is het verschil veel kleiner (vooral door snelheid).

Dus vooral goedkopere hardware (CPU en chipset) en vooral zuiniger in energieverbruik.
Securitywise ? Nagenoeg geen verschil behalve een afwijkende OS structuur.

Het verschil op veiligheidsgebied is niet zo groot. Exploits die gebaseerd zijn op x86 machinecode zullen niet op een ARM werken, maar exploits gebaseerd op ARM machinecode bestaan ook, al zijn die nu nog zeldzaam. Heel veel gaten in systemen zijn uit te buiten zonder de machinearchitectuur te kennen, het kleine voordeel van de ARM valt in het niet bij hoe de gebruiker zijn systeem configureert.
Belangrijkste voordeel van ARM boven x86 is energie-efficiëntie. De ARM kan ook omgaan met "domme" randapparatuur, maar dan moet de device driver wel voor de ARM architectuur gecompileerd worden. Een x86 BIOS driver werkt niet. Voor zover ik weet ondersteunt Linux dezelfde randapparatuur onder ARM als x86.

ARM CPU's zijn gemaakt op basis van een simpele architectuur, de CPU zelf is moeilijk te misbruiken.
intel CPU's bevatten al management software waarvan de laatste tijd gebleken is dat deze nogal eens wat issues met zich meebrengt.

Een stap verder, het OS dat gebruik maakt van de CPU, laten we Linux nemen voor Intel en ARM.
Linux voor Intel komt veel vaker voor dus zal een mogelijke kwetsbaarheid eerder voor dat OS gecompileerd worden dan voor een ARM architectuur, hoe meer gebruikt des te meer kans op slachtoffers.

Nu Apple ARM gebruikt krijg je een situatie waarbij je de kans hebt dat software wat voorheen op de x86_64 CPU gecompileerd was nu ook voor de ARM cpu gecompileerd wordt. Daarbij loop je het risico dat de software op de ene CPU beter functioneert dan op de andere en misschien ook meer of minder kwetsbaarheden gaat vertonen.

Uiteindelijk maakt de CPU het niet meer of minder veilig maar de software ontwikkelaar,

Er is nooit een 640kB limiet in de x86 structuur geweest! Dit was een limiet van het IBM PC design.
Je zou kunnen zeggen dat de 8086/8088 een 1MB limiet had.
Echter met de 80286 is dat al opgehoogd naar een 16MB limiet en tegenwoordig is dat al helemaal niet relevant
meer omdat alle software toch wel minimaal in 32bit mode werkt en dus is de limiet dan 4GB. Wat dan door operating
systems weer verkleind wordt omdat men wederom (net als bij de IBM PC!) een vaste memory map maakt waarbij een
deel voor het OS en een deel voor de gebruiker gereserveerd is.

Werk je met 64bit mode (waar je wel vanuit kunt gaan als er vergeleken wordt met de M1) dan is het niet eens x86
mode maar heb je het over x86_64 of amd64 mode en dan speelt dit al helemaal niet meer.

Kortom, haal er geen dingen bij die helemaal niet meer relevant zijn.

Deze schud je neem ik aan even uit de losse pols zonder je te baseren op feiten?
Ik durf em wel aan te gokken dat er meer Linux op ARM draait dan op Intel...

Android!

P.S. Heb je voor het gokken toestemming van de kansspelautoriteit?

Ik schat zo in dat het merendeel van de xDSL modems ook een ARM/Linux combinatie is.

Mogelijk zitten er ook Arm procesoren in Telefoons,mogelijk ook in Navigatie apparetuur,zoals de Tom Tom.
Maar ja dat van de Tom Tom is ook een soort Linux achtig OS,Android is eigenlijk ook een soort Aftreksel op Linux gebasseerd.

Alles valt of staat met de daadwerkelijke implementatie. Kijk bijvoorbeeld naar de kwetsbaarheden bij Intel, maar niet bij AMD. Dat de ene architectuur veiliger zou zijn dan de andere valt daarmee absoluut niet te zeggen, zelfs niet als je bereid bent erg kort door de bocht te gaan.

Je hebt gelijk dat de 640KB limit, niet direct X86 is maar IBM PC design.

Even wikipedia geraadpleegd: It is still present in IBM PC compatibles today if they are running in real mode such as used by DOS. Even the most modern Intel PCs still have the area between 640 and 1024 KB reserved.[3][4] This however is invisible to programs (or even most of the operating system) on newer operating systems (such as Windows, Linux, or Mac OS X) that use virtual memory, because they have no awareness of physical memory addresses at all. Instead they operate within a virtual address space, which is defined independently of available RAM addresses.[5]

Ik denk dat niet zo relevant is (het gebruik van ARM in SBC's). De vraag was volgens mij gericht op het gebruik van ARM als desktop processor of mobile processor, meer specifiek in dit geval de M1 CPU zoals die onlangs in omloop is gekomen met de nieuwe Apple producten.

Kortom voor dit doel is ARM waarschijnlijk minder kwetsbaar, getuige de vele CPU kwetsbaarheden in Intel based platforms over de afgelopen jaren.

Ook voor ARM geld natuurlijk dat slechte code (zoals reeds gesteld) dit platvorm niet vrijwaart van zwakheden.

Mijn 2 centen

In geval van de vaak voorkomende PEBCAK maakt het niet uit welke processor er wordt gebruikt.

Er is geen enkele reden om te denken dat de M1 veiliger is dan welke andere CPU dan ook. Elke uitspraak in die richting is wilde speculatie, net als het tegendeel. Aan zomaar wat roepen heeft niemand wat.

Bedoel je PEBCAK aan de gebruikers- of aan de ontwikkelaarskant? In beide gevallen ben ik het met je eens!

Sure! You nailed it 100%. ;-)

In de internet wereld worden de meeste Linux servers nog steeds Intel geinstalleerd,
Ik denk dat jij niet op de hoogte bent van de werkelijkheid rond Linux installaties.

Daar tegenover staat dat iedere eindgebruiker van die servers een router heeft staat met een ARM-chipje en Linux-afgeleide. Dan hebben we het nog niet over de ettelijke lampen, camera's en andere ongein die een Linux-kernel onder de motorkap hebben. Simpele logica dicteert dat dat er toch veel meer moeten zijn dan de bijbehorende servers.

Hoeveel Linux servers zouden er op internet draaien in vergelijking met het aantal Android telefoons, modem/routers,
smart TV's, settopboxen, slimme thermostaten, VoIP telefoons, Raspberry Pi's enz enz allemaal bij elkaar?

Had ik niet ergens gelezen dat Linus voorlopig geen M1 ondersteuning zag, zo niet nooit....?

Ik heb dat gelezen , dus jij zou het ook gelezen kunnen hebben....

De CPU is geen probleem, maar Linus heeft (iig zelf) geen interesse in het reverse engineeren van de GPU en andere peripherals om Linux native op de macbook arm te draaien.

Binnen een VM is wellicht mogelijk, maar dat is amper interessant voor kernel development.

Ik kan me de tijd nog wel herrinneren dat het een doodzonde was om de woorden GPU en kernel in 1 zin te noemen.
Maar kennelijk is dat nu toch wel een beetje bijgedraaid??

Huh ?
Klinkt als klok met verre klepel .

GPU is een generieke term - Graphics Processing Unit. vroeger "videochip" .

Linus wil een gewoon werkende laptop - inclusief beeldscherm, muis,wifi etc.
Hij wil geen ARM systeem met alleen een seriële connector.

De kans is nogal klein dat Apple die chip(onderdelen) voldoende documenteert om een Linux _systeem_ snel te porten.

Je relatie met "GPU en kernel" slaat _vermoedelijk_ op Nvidia (chipset/GPU) drivers. De feitelijke video server draait in userland, maar er is altijd een stukje kernel interface waarin de kaart als een device gepresenteerd wordt.
Die kernel interface is bij nvidea een binary module.
Met een warning "geen GPL code" ('tainted') , en bij kernel crashes op dergelijke systemen zeggen de kernel developers "zoek het maar uit, we gaan niet zitten raden wat die module doet" .

Of bedoelde je alleen het punt 'video driver in de kernel' ?
Die draait dus nog steeds in usermode (X server, of 'wayland' ), maar heeft enige kernel interface, omdat de kernel nu eenmaal alle toegang tot hardware 'regelt'.


FWIW - er is nu al iemand die Linux wil gaan porten
https://9to5mac.com/2020/11/30/developer-hector-martin-announces-patreon-funding-for-bringing-native-linux-to-m1-macs/

Beetje praktijk ervaring. In normaal gebruik merk ik weinig verschil tussen amd64 en aarch64 op Linux bij normaal gebruik. Ga ik echter compileren dan is arm stukken trager (20 minuten vs 3 minuten), dus ik kan me voorstellen dat het geheel afhankelijk is wat je doet. Beetje internetten, email en netflix kijken denk ik dat je met arm ook wel goed zit. Maar dat is echt heel subject.

Wat je schrijft zegt _niets_ over de CPUs .
Welke cpu, hoeveel cores, welke klokfrequentie, hoeveel geheugen, wat voor disken .

De eerste testen van de M1 gebaseerde macbook's gaan duidelijk in de richting van heel solide performance - die alleen onderdoet voor een behoorlijke desktop versie van de AMD Zen3 .

Heel veel van de ARM-opties zijn gewoon op veel vlakken een low-end systeem - of het nu een chromebook of een rPI is.

Welke machines vergelijk je (qua processor, opslag, etc.) Het maakt voor compileren wel verschil of je een HDD of een SSD gebruikt. De compiler zal ook verschillen tussen ARM en x86. Zelfs de beschikbare hoeveelheid RAM kan verschil maken. Het zal me niet verbazen als een x86 core per GHz iets effectiever is dan een ARM core, maar dat is aan de ARM kant te compenseren door meer cores te gebruiken (voor hetzelfde energieverbruik.)

Zo werkt het niet - er is niet 'een' ARM core, en 'een' x86 core .

Er zijn behoorlijke verschillen in architectuur en implementatie tussen cores afhankelijk van de bedoelde toepassing.
Je kunt een ARM core hebben met vrij beperkte performance - en heel laag stroomverbruik.

In X86 land heb je de intel 'atom' - relatief low power en lage performance. Of de Zen3 serie aan de bovenkant.

De M1 arm van Apple lijkt in alle opzichten erg hoog te performen. ARM cores bedoeld voor embedded gebruik komen niet in de buurt van die performance.

(Sterker - de M1 , en sommige andere ARM chip implementaties bevatten 'big' en 'little' cores - de little cores zijn langzaam en zuinig, de big cores worden alleen gebruik als er meer performance nodig is.
https://en.wikipedia.org/wiki/ARM_big.LITTLE

Een deel van de maximaal haalbare performance van een cpu implementatie volgt uit de micro-architectuur.
Daarin zitten ook keuzes die grenzen stellen aan de hoogst haalbare frequentie - of het laagst mogelijke stroomverbruik.
Het is niet alleen kwestie van de klokfrequentie omhoog of omlaag draaien - er is een zekere range die je met dezelfde micro-architectuur kunt afdekken, maar verder naar de randen van low power of ultra (single-thread) performance zijn fundamentele keuzes gemaakt in het ontwerp van de chip - (en eventueel in de packaging en omgeving).