/dev/null
- Overig
ARM vs Intel x86
26-11-2020, 10:35 door Anoniem, 27 reacties
Een relatief simpele (en maybe ook domme) vraag. Als ik eerlijk ben heb ik best even
ge-googled maar snap ik de google antwoorden niet echt :> De vraag: Biedt het gebruiken
van een ARM processor (zoals in bijvoorbeeld de nieuwe Macbook M1) nog security voor of
nadelen ten opzichte van een Intel x86 processor?
ge-googled maar snap ik de google antwoorden niet echt :> De vraag: Biedt het gebruiken
van een ARM processor (zoals in bijvoorbeeld de nieuwe Macbook M1) nog security voor of
nadelen ten opzichte van een Intel x86 processor?
Reacties (27)
26-11-2020, 11:58 door
dutchfish
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.
Kort door de bocht: Een reduced instructionset zoals ARM en RISC-V verminderen voor een deel de kans op kwetsbaarheden, mits juist geprogrammeerd.
26-11-2020, 12:28 door
Bitje-scheef
Door dutchfish: 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.
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.
26-11-2020, 14:24 door
MathFox
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.
Door Bitje-scheef: 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.
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.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.
26-11-2020, 14:51 door
_R0N_
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,
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,
Door Bitje-scheef:
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 flexibeler/efficiënter in het afhandelen van het e.a (geheugen) omdat er geen x86 stuctuur geldt (nog steeds een 640kb limiet).
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.
Door _R0N_:
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.
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.
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...
26-11-2020, 16:06 door
MathFox
Door Anoniem:
Ik durf em wel aan te gokken dat er meer Linux op ARM draait dan op Intel...
Android!Ik durf em wel aan te gokken dat er meer Linux op ARM draait dan op Intel...
P.S. Heb je voor het gokken toestemming van de kansspelautoriteit?
Door MathFox:
Door Anoniem:
Ik durf em wel aan te gokken dat er meer Linux op ARM draait dan op Intel...
Android!Ik durf em wel aan te gokken dat er meer Linux op ARM draait dan op Intel...
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.
Maar ja dat van de Tom Tom is ook een soort Linux achtig OS,Android is eigenlijk ook een soort Aftreksel op Linux gebasseerd.
Door dutchfish: 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.
Kort door de bocht: Een reduced instructionset zoals ARM en RISC-V verminderen voor een deel de kans op kwetsbaarheden, mits juist geprogrammeerd.
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.
27-11-2020, 14:14 door
Bitje-scheef
Door Anoniem:
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.
Door Bitje-scheef:
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 flexibeler/efficiënter in het afhandelen van het e.a (geheugen) omdat er geen x86 stuctuur geldt (nog steeds een 640kb limiet).
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.
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]
27-11-2020, 14:16 door
dutchfish
Door Bitje-scheef:
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.
Door dutchfish: 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.
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.
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.
Door dutchfish:
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
Door Bitje-scheef:
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.
Door dutchfish: 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.
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.
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
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.
28-11-2020, 12:16 door
MathFox
Door Anoniem: In geval van de vaak voorkomende PEBCAK maakt het niet uit welke processor er wordt gebruikt.
Bedoel je PEBCAK aan de gebruikers- of aan de ontwikkelaarskant? In beide gevallen ben ik het met je eens!Door MathFox:
Sure! You nailed it 100%. ;-)Door Anoniem: In geval van de vaak voorkomende PEBCAK maakt het niet uit welke processor er wordt gebruikt.
Bedoel je PEBCAK aan de gebruikers- of aan de ontwikkelaarskant? In beide gevallen ben ik het met je eens!
01-12-2020, 11:54 door
_R0N_
Door Anoniem:
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...
Door _R0N_:
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.
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.
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...
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.
Door _R0N_:
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.
Door Anoniem:
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...
Door _R0N_:
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.
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.
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...
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.
Door _R0N_:
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.
Door Anoniem:
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...
Door _R0N_:
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.
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.
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...
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.
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....?
Door Anoniem: 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.
Door Anoniem:
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.
Door Anoniem: 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??
Door Anoniem:
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??
Door Anoniem:
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.
Door Anoniem: 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/
02-12-2020, 16:24 door
botbot
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.
Door botbot: 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.
02-12-2020, 17:19 door
MathFox
Door botbot: 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.
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.)Door MathFox:
[..]
[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.)
[..]
[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).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.