Door Anoniem:Notoir lek zou ik het niet noemen - de iPhone unlocks die iets met de 'baseband' willen zijn beduidend zeldzamer dan slechts de OS hacks
Je kijkt teveel met popi oogjes van de verkeerde kant.
Het was sterker geweest als je je bewering ondersteund had met een serie bewijzen .
Daar had ik even geen zin in. Die baseband interface wordt niet eens zozeer naar een standaard alswel naar de paar merken torenapparaat geknutseld; het zit dus vol met quirks. Daarnaast wordt het puur voor functie en niet voor security gebouwd, en dat gaat goed zolang de boze buitenwereld niet boos genoeg is. Zie begindagen internet. Er zijn dus af en toe wel securityneuskes die een gat of twee in zo'n baseband processor vinden. Daarmee zitten ze niet op de applicatieprocessor maar hebben er vaak wel ongelimiteerd toegang toe. Natuurlijk moet je de telco zijn (of een neptoren neerzetten) om daarmee te kunnen rommelen, maar als je kijkt naar het veld dan is daar nog heel veel te onderzoeken en te verbeteren. Op zijn minst is het een grote onzekere factor, dus veiligheidshalve ga je ervanuit dat die basebandprocessor gewoon lek is. Wat af en toe ook wel doorschemert uit de realiteit. Maar het is geen groot ding dus een paniekfestijn als heartbleed zal niet snel gebeuren. En patchen ook niet.
Het feit dat een redelijke groep gemotiveerde en slimme mensen die hard zoeken (de unlockers) vrij weinig baseband bugs vindt maakt een statement 'notoir lek' wat mij betreft onjuist.
Volgens mij doen die wat anders.
Je post ademde nogal de samenzweringsgedachten van geheime feature die 'een designer ongemerkt kan toevoegen'.
Dat lees je er zelf in.
Mijn denken werkt een tikje anders. Er zijn wel redenen om aluhoedjes op te zetten, bijvoorbeeld zijn er indicaties dat mainboards uit China met andere iME firmware aankomen dan de manufacturer samples direct van intel, maar als je de gedeelten waar je bij kan dumpt dan krijg je het origineel toch weer terug, dus wat daar precies aan de hand is? Dat is wel "ab werk", en dan krijg je dus een firmwareversie van "on trusting trust" voor je kiezen. Er zijn dus wel indicaties dat er aan gerommeld is of tenminste zou kunnen zijn. Maar daar had ik het nog helemaal niet over gehad.
Dat hoeft ook niet, want zelfs zonder dat, een CPU met eigen OS in je southbridge die zijn eigen ethernetaansluiting heeft en dus berichten van buitenaf kan ontvangen zonder dat de CPU waar het OS van jouw keuze op draait, zelfs als dat precies is als ontworpen, is voor jou een veiligheidsprobleem. Je weet niet wat het doet en het zit in een positie om jou een loer te draaien waar je heel weinig aan kan doen. Dat is uit veiligheidsoogpunt, zelfs als je intel met je leven vertrouwt, gewoon niet heel slim.
Dat die console poort de primaire CPU gebruikte en niet separaat de hardware kon resetten was een beperking.
De volledige systeem controle die je er vrijwel altijd mee kon krijgen was evenzeer een risico als een ongepatchte ilo nu is.
Die eerste beperking kan je opheffen met een FEP, wat in verbazend weinig transistoren zou kunnen. Ik denk dan aan bijvoorbeeld de J1 FORTH CPU, wier open source verilog source wel 200 lijnen is. Mischien dat je een hele FEP wel in 1000 lijnen kan, compleet met resetlijntjes, meer geavanceerde point-to-point serial van een paar megabits mischien, en wat dies meer zij. Maak het zuinig genoeg dat'ie van de stroom van de serial kan leven en je hoeft ook die extra wall-wart niet aan te sluiten.
Het punt is veel meer dat een iLO/DRAC/LOM/... veel complexer is dan'ie zou moeten zijn en dat dat een domino-effect heeft. Serial kan je wel bovenop automatiseren, IPKVM veel minder. Het is (alweer) die aanname van een operator aan de machine die zo diep in de peecee is ingebouwd die al die ellende veroorzaakt.
Maak een simpelere interface en het interfacen met die interface wordt ook simpeler. Plus dat als je je netwerkmanagement (en dus dier complexiteit) van die inbouwkaart naar een serial port server verplaatst, je toegangsbeheer op de console (en dus de macht) ineens ook een stuk simpeler wordt.
Die zit dan in de fysieke toegang (toch al "game over" hoe je het ook bekijkt) of in je goed gemanagde "bastion host" in de vorm van je netwerktoegankelijke serial console server waar de toegang tot zeg een heel rack tegelijk en per poort geregeld kan worden.
Ik zie dat wel omdat ik niet in "alle computers hebben scherm, muis, en toetsenbord" geloof, maar dat wil niet zeggen dat ik ook de klok wil terugdraaien. Veel meer, het hele peecee-gebeuren heeft nogal wat fouten gemaakt, vaak op kostengronden, die vaak neerkomen op goedkoop bleek duurkoop. Daar hoeven we natuurlijk niet mee door te gaan als we de noodzaak daartoe wegnemen.
Zelfs redmond heeft ondertussen toegegeven, schoorvoetend en zonder bronvermelding, maar wel toegegeven, dat de GUI ook niet uniform zaligmakend is en dat de CLI soms best makkelijk is, in de vorm van posershell.
Het punt was dat een console die de main CPU gebruikt (soms) niet genoeg is om een systeem echt te resetten.
Dan doe je dat toch niet. Dan plak je er een Font-End Processor voor. Wat ik ook noemde.
Een echt zelfstandige ilo kaart kan dat wel.
Die dat doet tegen een hele hoge prijs. Ik zeg, een nodeloos hoge prijs. We kunnen het ook wel op een andere manier. Die IPKVM-in-elke-server-inbouwen-aanpak heeft daar echt het monopolie niet op. En uit veiligheids- en betrouwbaarheidsoogpunt is complexiteit zoveel mogelijk te vermijden. Dus dat feature op een minder complexe manier inbouwen is toch een beter idee.
En dan moest je alsnog een mannetje sturen om op de reset knop te drukken. (en hopen dat het aanduiding van zaal, rij , rack en positie klopt voor _welke_ server gepowercycled moet worden).
Je leert vanzelf hoe slim die "smart hands"-diensten zijn. Dat weet ik inderdaad uit ervaring.
Ik wil _wel_ een out of band die een hard hangend systeem kan resetten.
Mee eens, maar kijk uit wat je "out of band" noemt. Als het in je southbridge ingebouwd zit, hoe "out of band" is het dan nog?
En het is ook wel erg prettig als de interface voldoende bandbreedte heeft om een basic systeem of recovery image naar een server te kunnen brengen.
Dat hoeft niet per se over je commandokanaal als je een bios hebt dat je gewoon kan vertellen zijn volgende image zelf over het netwerk op te halen, zoals openboot dat kan. Alweer een dingetje dat peecees nooit konden en dus moest het er tegen hoge kosten achteraf alsnog tegenaangeplakt worden. Door floppies en CDROMs te faken bijvoorbeeld. Overigens bestaan er wel open source projecten die vergelijkbare functionaliteit toch weer toevoegen, maar dan via de netwerkkaart. Compleet met zelf flashbare custom scripts en zo verder.
Maargoed, als je niet bolt-on hoeft te faken, dan kun je met relatief weinig moeite meer bereiken dan al dat glimmend moois dat de OoBMUs met veel kunst en vliegwerk aan je peeceetje plakken.
En ethernet is wel heel veel makkelijker te verlengen door een datacenter dan RS232.
Je bedoelt dat je even een switch kan neerplempen en het is wel goed? Voor je het weet hangt er iemand je netwerkje aan het internet en iedereen kan jouw servertjes managen. Uit veiligheidsoverwegingen is het beter de lijntjes simpel te houden. Maargoed, in plaats van switches pak je dan serial console servers, die dan als bastionhost dienst doen en dan dus wel aan een netwerkje hangen. Zoals gezegd, door dit handig aan te pakken elimineer je complexiteit en verplaats je de complexiteit die je overhoudt naar daar waar hij minder in de weg zit, of gewoon beter in de hand te houden is.
Want als je een machine uit de sloot wil trekken dan wil je simpele dingen die werken, niet obstakel na obstakel van andere dingen die je éérst moet doen.
Maargoed, het hoeft niet per se precies RS232 te zijn. Hoewel dat waarschijnlijk best voldoende kan zijn, zelfs op 9600 baud. Ik heb wel wat alternatieve encodings op het oog waarmee er meer bits per seconde over minder draadjes te sturen zijn, ook op redelijke afstanden. Het idee is altijd wel strikt point-to-point zodat je altijd met "de andere kant van deze draad" praat, en dat er niet eerst even uitgezocht moet worden welke van de tien of twintig of honderd aangesloten kandidaten je hebben wil. Die selectie doen we ergens anders, namelijk bij de poort.
En ja, ilo kaarten die een dikke java client vereisen zuigen ook heel erg.
Je kan ook de dotnet client pakken natuurlijk. Want iedereen gebruikt windows.
Net zoiets als roepen dat je teraterm moet pakken om je servertje te beheren, maar daar heb je wel de keuze om beter te weten en iets anders te pakken, en bij zo'n IPKVM toch wat minder. Zelfs "maar java is toch platformonafhankelijk!?!" blijkt niet altijd even waar. Ik weet niet hoe ze het doen maar ik weet wel dat er af en toe java opduikt die het domweg vertikt te werken op JVMs op andere dan voorziene platforms. Je kan gissen dat de ontwikkelaars puur op functie ontwikkeld hebben op een hele beperkte testbasis. Wat dat voor het ontwikkelen voor veiligheid lijkt dan op voorhand al nog minder rooskleurig.
Maargoed, het punt is, in abstracto, dat simpliciteit een beter idee is dan complexiteit. Het kost toch best veel ingewikkelde woorden om dat punt een beetje te maken.