Google: wijzigingen Samsung aan Android-kernel veroorzaken beveiligingsproblemen

Wijzigingen die Samsung heeft aangebracht aan de kernel van zijn besturingssysteem voor de Galaxy A50-smartphone, hebben geleid tot enkele beveiligingsproblemen, claimt Google. Het Project Zero-team van Google meent dat het beter is om de kernel ongewijzigd te laten.

Een van de exploits is mogelijk door een beveiligingsmaatregel die Samsung heeft toegevoegd aan de kernel van zijn Galaxy A50-smartphone, claimt Google Project Zero. "Kernelcode van Linux heeft veel scherpe randjes. Wijzigingen aan zo'n codebase, vooral een fork zonder enige controle van mensen die upstream de code bijhouden, kunnen gemakkelijk subtiele problemen opleveren, zelfs als deze wijzigingen zijn doorgevoerd voor beveiligingsmaatregelen."

De onderzoeker zegt dat het beter is om de code te laten checken door de mensen die de Linux-kernel bijhouden, of niet langer in de kernel te zetten. "Deze wijzigingen zouden beter kunnen in userspace, waar ze geschreven kunnen worden in veiliger programmeertalen of in een sandbox kunnen draaien. Op hetzelfde moment zou dat updates naar nieuwere kernel-releases ook niet moeilijker maken."

Google heeft zich niet eerder uitgesproken tegen het bewerken van de Linux-kernel door Android-fabrikanten. Project Zero vond een lek in de kernelfunctie Process Authenticator van Samsung en ook bleek het mogelijk om een oud lek in de kernel nog steeds te misbruiken, omdat zelfs een nieuwere update nog een oudere kernel draaide.

Reacties (89)

[ikweethetbeter]

Dit is natuurlijk het probleem van Android: fabrikanten wijzigen niet alleen de schil, het uiterlijk, maar ook het innerlijk, en niemand die ze dwingt om bij een nieuwe Android versie ook overal de bijbehorende nieuwe kernel te gebruiken.

[Twam]

Wait, wut?

Android-versies =/= kernelversies? Loopt dat ook nog eens los van elkaar?

Geen wonder dat het updatebeleid zo'n drama is -_-
Ik zou zo blij worden van een centraal beheerd (en dus bijgewerkt) Android-OS, en dan alle grappen van telefoonbouwers gewoon lekker via losse distributie daar overheen, ipv al die ingewikkelde constructies... Ik bedoel, iedereen is nu overgeleverd aan de genade van hun fabrikant, maar die hebben natuurlijk zelf bar weinig belang bij langdurige OS-ondersteuning.

[pookie79]

Daarom is het hebben van de laatste android versie ook lang niet zo belangrijk (qua veiligheid) als vaak gedacht wordt. Oudere versies van android kunnen goed bij de tijd zijn. Vaak zijn nieuwe toevoegingen op android ook op oudere versies te krijgen. Bij iOS is het updaten zo goed omdat je altijd de laatste versie moet hebben, want daar zit alles in. Bij Android werkt het anders. Ik wil zeker niet zeggen pre sé beter of zo, of dat iOS beter is, het is gewoon anders.
Nu weet ik wel dat er mensen niet blij worden van zo'n uitspraakl want: "Android krijgen nooit updates" en dat soort uitspraken krijg je dan (met het liefst een -1). En die incasseer ik graag.

Maar er zijn inderdaad fabrikanten die liever geld steken in markering en minder in het product.

[Reactie gewijzigd door pookie79 op 23 juli 2024 19:23]

[Twam]

Ik was er al wel achter dat beveiligingsupdates en bugfixes redelijk los van elkaar lopen. Ik zit zelf op Android 8 (Samsung A3 2017), maar met meest recentste beveiligingsupdate uit november 2019. Pluspunten voor beveiligingspatch, maar toch tamelijk frustrerend, omdat ik iedere ochtend wakker wordt met een bug in Do Not Disturb (grove notificatiespam bij geplande uitschakelen van DnD) die dus in 8.1 keurig is opgelost, maar dankzij Samsung keurig in mijn versie blijft zitten, want 8 was de laatste versie die ik ging krijgen

Ik weet dat rooten en andere rom flashen misschien workaround voor die bug is, maar dan werken aantal beveiligings- en bank-apps niet meer, dus dat vind ik dan ook niet echt een optie. Het maakt iig het werk van m'n wekker makkelijker, zullen we maar zeggen

[Cerberus_tm]

Met root e.d. kun je als het goed is wel Safety Net intact laten.

[ikweethetbeter]

Zou niet moeten mogen, maar deze ontdekking van Google toont aan dat het mogelijk is en ook gebeurt.

Kernel en core Android moeten een onlosmakelijk deel zijn. Fabrikanten kunnen wat rommelen in drivers en skins, dat zouden de grenzen moeten zijn. Google zou hierin strikter mogen optreden (dat ik dat hier ooit zou prediken...), alleen zo kan Google verantwoordelijk worden gehouden in de kwaliteit van Android.

[jbhc]

Het mag wel, dat is juist het mooie aan Open Source

[K-aroq]

Niet helemaal. Het idee van open source is dat je iets toevoegt of verbetert en het dan weer teruggeeft aan de community zodat iedereen het gebruikt. Als je (te) veel forks krijgt schiet het het doel voorbij.

[jbhc]

Toch gebeurt het vrij vaak:
Debian -> Ubuntu -> Mint bijvoorbeeld
Dat hoeft niet perse een slechte zaak te zijn.

[tweaknico]

Als Mint tegen een issue in Debian oploopt zullen ze dat wel degelijk richting Debianmelden, dan kan het gefixed worden anders moet je de fil elke keer mee porteren bij een upgrade...

Ook de distributies doen dat als het goed is naar de verschilende projecten.. zoals de bv. de kernel., glibc, ...etc. zodat ze niet alles moete blijven patchen..

[jbhc]

Mint kan niet tegen een issue in Debian aanlopen aangezien het op Ubuntu is gebaseerd Ze zullen dus bij Ubuntu aan moeten kloppen. En die zou dan bij Debian aan moeten kloppen. Wat ze ook kunnen doen is zelf een workaround creëren.

Ik denk dat Samsung ook zoiets gedaan heeft.

[tweaknico]

Mint kan heel wel tegen een issue van wat door een gebrek in Debian veroorzaakt wordt aan lopen, ze zijn niet identiek aan Debian, en gebruiken het net even anders met net even een andere set opties. Ook Ubuntu verbouwt niet heel Debian, maar is een bepaalde configuratie van Debian modules en wat eigen extra's.

Met zelf een work around creeeren help je jezelf direct, maar niet op de lange termijn. dan zul je je aanpassing bij elke versie upgrade opnieuw moeten evalueren en aanpassen...
Als je het upstream meld kan het daar laten opgelost worden en dan komt de definitieve oplossing vanzelf weer terug.

Als Mint ontwikkelaar tegen een issue in libxml aanlopen zullen ze zelfs naar de libxml ontwikkelaars moeten gaan om het te melden. (of bij iedereen in de keten als serrvice melding ook plaatsen met linkjes..)

[riotrick]

https://www.linuxmint.com/download_lmde.php

LMDE: Linux Mint Debian Edition

[kidde]

Het noemen van Debian is wel geinig:

Debian deed precies wat Samsung nu doet, namelijk zelf veiligheidsmeuk (OpenSSL) van anderen 'verbeteren'. Ze hebben het trouwens wel netjes gemeld aan de makers, hoe en waarom ze dit deden.
Resultaat was destijds (en zelfs zeven jaar later nog?) desastreus; je zou toch hopen dat Samsung daarvan geleerd heeft?

https://jblevins.org/log/ssh-vulnkey

[HollowGamer]

De drivers zitten in de kernel, dat is mede een van de reden dat fabrikanten kiezen voor hun eigen kernel/firmware.

Het maakt mij eigenlijk niet zoveel uit welke kernel ze draaien, als ze deze maar bijhouden en eventueel van backports voorzien als dat nodig is. Vooral bij dat laatste gaat het vaak mis en veelal geven ze de kernel sources wel vrij maar te laat.

[Stadtionalist]

Afaik, met 1 onwijzigbare kernel voor 1 android krijg je hetzelfde als met iOS, 1 telefoon (omdat je maar 1 reeks aan drivers en instellingen kunt gebruiken)

[thesinsher]

Maar moet ik dan fluiten naar mijn accuduur? Elk Google (en Samsung Galaxy S) telefoon dat ik gehad heb was een drama met betreft accuduur. Ongekend hoge idle-drain. Onbetrouwbaar. Nu heb ik meer dan een jaar lang een Huawei Mate 20 en de accuduur is sinds dag 1 hetzelfde gebleven met geen idle-drain terwijl de prestaties krankzinnig zijn (vergeleken met een S10). Als de kernel genormalilseert wordt, verliezen de merken die dingen wel op orde hebben ook hun goede accu-duur en/of prestaties?

Met een S10 kom ik circa 4-5 uur scherm-tijd vooruit op hooguit een enkele dag terwijl ik met de Huawei ongeveer 10-11 uur scherm-tijd behaal verspreid over 2 tot 3 dagen. Als ik de S10 continu zou gebruiken zou die het hetzelfde presteren kwa accuduur als de Huawei (of zelfs beter!), maar idle-drain is een drama op de S10 waardoor accuduur ook een getrocht er op is. Als dit allemaal aan de kernel ligt...oei!

[Darkstriker]

Als dit allemaal aan de kernel ligt...oei!

Maar daar heb je dus geen enkel bewijs voor. Je hele rant hangt aan een zijden draadje.

[thesinsher]

Geen bewijs? Daarom staan er op XDA-developers https://www.xda-developers.com/ verschillende kernels met allerlei optimalizaties met betrekking tot de accuduur en idle-drain? Als je een ondersteunde telefoon hebt (zo goed als elk populair Android smartphone) dan kan je het zelf uitproberen. Desnoods ga je de posts and threads langs op XDA-developers. Developers werken er niet voor niets aan. Dus, als alle Android fabrikanten geen wijzigingen mogen toebrengen aan de huidige Kernel dat dan geleverd wordt door Google...zal het zoals het nu is alleen maar negatief zijn.

[Reactie gewijzigd door thesinsher op 23 juli 2024 19:23]

[Darkstriker]

Ja, ze zeggen allemaal dingen over optimalisatie voor de batterij, maar ik zit sinds de originele Galaxy S in die scene en heb nog nooit een kernel gezien die noemenswaardige verbeteringen bij de batterij heeft kunnen bewerkstellingen zonder enorm op prestaties in te leveren (door underclocks of veel conservatievere schedulers). Kortom, ik heb het letterlijk honderden keren geprobeert (op verschillende Samsungs, OnePlus en Xiaomi telefoons) en de verschillen (als ze er al zijn) bewegen zich in de <5% marges.

Je doet alsof je hiermee dagen aan batterijduur kunt winnen maar dat is gewoon volstrekte onzin. Samsung en Huawei maken verschillende keuzes in het handelen van wake-ups in standby en dergelijk en dat zorgt voor de massale verschillen tussen die twee. En natuurlijk het feit dat de hardware compleet verschillend is.

[loki504]

Optimalisatie. 1 minuut langer idle is ook al een optimalisatie. Maar daar ga ik niet wakker over liggen.

En als we even op google kijken zien we al snel dat er meer mensen last hebben van een s10 idle van 3/4% per uur. Maar dat is niet normaal. En is ook een teken dat er iets mis is. Maar dat ligt niet alleen aan de kernel. En al helemaal niet aan de super kernel optimalisatie van huawei.

[Reactie gewijzigd door loki504 op 23 juli 2024 19:23]

[thesinsher]

Dat ik toen mijn S8 van 2-3% idle-drain terug gedrongen kreeg naar minder dan 1% simpelweg door een accu-geoptimaliseerde kernel te kiezen zegt genoeg. Er zit weldegelijk rek in de kernel. Natuurlijk is dat niet alles, maar elk bijdrage helpt en in dit geval kan het gaan om een enorme bijdrage.

@Darkstriker Jij vat het op zoals jij wilt en dat heb je zelf ook al als onzin verklaart, fijn. Een kernel is essentieel en een goed geoptimaliseerde kernel presteert beter dan een minder goed geoptimaliseerde kernel getuige Samsung en XDA-developers. Als Samsung niet aan hun kernel meer mag sleutelen, kan dat nadelige gevolgen hebben voor Samsung (maar ook voor alle andere android-gebasseerde smartphones). Ik noem accuduur als een gevolg, maar dat is maar één van de velen zaken waar een kernel veel bijdrage aan levert tot hoe een gebruiker de smartphone ervaart.

Moet het verbonden worden aan de security patches van Google? Dat durf ik niet te zeggen!

[Wickedmen030]

Paar weken oude S10 hier. Ik kom op een dag met een schermtijd van 6 tot 12 uur. Wel is de accuduur slechter dan de S6 en S8. Dit komt waarschijnlijk door de processor en de One UI.

[akooijman]

Zes tot twaalf uur...
Dat geeft wel aan dat kernel optimalisatie met een winst van een paar procent leuk zijn voor de ontwikkelaars, maar van geen enkele waarde voor de eindgebruiker. Een onhandig geprogrammeerde App en je levert zo een paar uur in. Je telefoon verkeerd op de kast en je bent alle winst kwijt aan extra wifi of 4g vermogen.

[tweaknico]

Idle drain heeft meer met userland te maken dan de kernel.
Als userland cycles blijft vragen worden ze gescheduled, en wordt de CPU gewekt, en begint te stoken.

Ik heb op een nokia de nodig zaken uitgezet en verwijderd en heb een veel langere Accu lifetime.

[jbhc]

Al die social-apps kunnen nooit goed voor je accu zijn.

[tweaknico]

Die zijn er al af bij eerste installatie.
Google spul ook voorzover mogelijk, en ook de Nokia eigen spullen zijn buitenbedrijf dat scheelt gelijk ook een hoop api-calls naar facebook.
Opencamera lijkt zuiniger dan de Nokia camera (mogelijk een van de Facebook issues).
Nextcloud is een stuk rustiger.
Wireguard is ook een hoop zuiniger dan openvpn...

Ook wat privileges van core taken verwijderen helpt dan kan de telefoon app niet voor en na een gesprek data "ophalen" of naar google "brengen". blokada houdt ook de nodige api-callouts tegen.

[thesinsher]

Userland? Idle drain heeft te maken met hoe de fabrikant software opgesteld heeft. De kernel is onderdeel daar van en niet de hoofdzaak. Waarom heeft de Galaxy A5 2016 van mijn moeder 0 last van idle drain en haar nieuwe S10 wel? De apps zijn hetzelfde. Waarom heb ik geen idle drain op mijn Huawei Mate 20 maar had ik dat wel op de Samsung Galaxy S8 en S7 Edge? Ik heb dezelfde apps. Sterker nog, ik heb sinds 2012 nog al mijn data (vooral media) en altijd dat naar de nieuwe telefoon verplaast. Zelfs al mijn gebruikte accounts en services zijn hetzelfde als toen ik de S7 Edge en S8 had. Op de Samsung-apps na heb ik letterlijk een kopie van wat ik toen had.

Er is wat aan de hand. Uit ervaring met de S8 lag het voornamelijk aan iets genaamd 'wake-locks.' Die werden slecht afgehandeld en dat kan verholpen worden met root. Vervolgens gaf youtuber LinusTechTips dit probleem ook aan. Om één of ander reden had hij altijd last van idle-drain op de Galaxy Note. Hij heeft er zelfs meerdere video's over gemaakt met tests (https://www.youtube.com/watch?v=n46s_iF_IV4). Het is een uiterst irritant probleem en is ook één van de twee hoofdredenen dat ik van Samsung afgestapt ben voor nu.

[tweaknico]

Precies wat ik bedoel.
het Android beheer & communicatie tussen Apps bepaald wanneer de kernel weer wat moet doen...
de wakelocks zijn het middel om dat te bereiken:
https://www.xda-developer...cks-android-without-root/

[holoduke51]

kernel bevatten voor een grotendeels drivers. Dat is voornamelijk de reden waarom fabrikanten sleutelen hieraan. Een nieuw camera protocol leidt in veel gevallen in kernel aanpassingen.
Core android is overigens voor het grootste gedeelte de Java runtime libs. Die staan helemaal los van de low level kernel os.

[CAPSLOCK2000]

Ja, de meeste Android apparatuur krijgt nooit een nieuwe kernel. Sterker nog, heel wat fabrikanten zijn blijven steken bij een of andere antieke kernel en installeren die ook op nieuwe apparaten. Deel van het probleem is dat die fabrikanten veel gebruik maken van closed source drivers die ze zelf niet kunnen/willen compileren of aanpassen. Ze hebben een binary blob uit het jaar 0 en die moet altijd blijven werken en daarom houden ze krampachtig vast aan de bijhorende kernel versie.

Het is eigen aan het driver model van Linux dat drivers nauw gebonden zijn aan een kernel en niet eenvoudig uitwisselbaar in binaire vorm. Dat zou je als nadeel kunnen zien, maar IMHO is dat een symptoom, niet de oorzaak van het probleem. Ik heb dan ook niet de ilussie dat het beter zou zijn als drivers wel binair uitwisselbaar zouden zijn. Fabrikanten zouden alsnog proberen om zo min mogelijk aan onderhoud te doen.

[caipirinha]

Het is gewoon een linux variant (soort van) dus kernel en het overige staan los van elkaar, gelukkig maar.
Zie het probleem ook niet echt mits de hardwareboer alles maar netjes up to date houdt.

[Nas T]

Geen wonder dat het updatebeleid zo'n drama is -_-
...
Ik bedoel, iedereen is nu overgeleverd aan de genade van hun fabrikant, maar die hebben natuurlijk zelf bar weinig belang bij langdurige OS-ondersteuning.

Het mooie is, dat Google op deze manier de schuld kan doorschuiven naar de fabrikanten, maar het had het ook zo kunnen inrichten, dat het updates door zou kunnen pushen, onafhankelijk van de fabrikanten.
Ik gebruik al jaren Sailfish, van Jolla en ben blij dat ik van dat geneuzel af ben. In 2012 kocht ik een Galaxy S3 (flagship) en halverwege 2013 werd duidelijk dat het updatebeleid ondermaats was. We zijn zo'n 7 jaar verder en er is niks veranderd.
Nokia heeft over Android ooit gezegd, dat het net is alsof je in de winter in je broek plast en dat blijkt hierdoor. Gelukkig is er een alternatief, al zijn er maar weinig mensen die de sprong willen wagen, maar ik blijf er in geloven omdat het waarmaakt wat Android en iOS niet lukt:

• Fatsoenlijk updatebeleid (iOS doet het ok, Android niet)
• Geen bloatware (bij Apple valt dat denk ik mee)
• Geen reclame in native apps
• Native apps zijn gratis.
• Native apps respecteren je privacy (al is dit bij iOS wel redelijk ok)
• Roottoegang is eenvoudig mogelijk

[Kenhas]

Is in mijn ogen niet enkel bij Android dat zoiets een probleem vormt maar met opensource in het algemeen. Je kan een bepaald programma goed vinden maar net niet goed genoeg. Je maakt een fork en wijzigt het. Dan is er iemand die andere functionaliteit beter vindt en een andere fork maakt. Na een tijdje is iedereen de weg kwijt in de verschillende versies van het oorspronkelijke.

Is er wel een licentie mogelijk waarbij wijzigingen aan kernel niet toegelaten zijn (of toch verplicht om de nieuwe kernel te gebruiken)?

[ikweethetbeter]

Is in mijn ogen niet enkel bij Android dat zoiets een probleem vormt maar met opensource in het algemeen.

Ja, dat is zo. Alleen zijn er bij Linux veel tweakers die de code reviewen, bij Android is dat niet het geval, en Samsung's versie van Android wordt door niemand buiten Samsung bekeken.

Je zou met certificaten een bepaalde kernel-versie kunnen afdwingen.

[CAPSLOCK2000]

Is in mijn ogen niet enkel bij Android dat zoiets een probleem vormt maar met opensource in het algemeen. Je kan een bepaald programma goed vinden maar net niet goed genoeg. Je maakt een fork en wijzigt het. Dan is er iemand die andere functionaliteit beter vindt en een andere fork maakt. Na een tijdje is iedereen de weg kwijt in de verschillende versies van het oorspronkelijke.

In theorie heb je gelijk, maar in praktijk is dat behoorlijk zeldzaam, het aantal gevallen in de afgelopen 10 jaar is op de vingers van 1 hand te tellen.

Android is daar uitzonderlijk in. Eerlijk gezegd zit het probleem vooral bij commerciele bedrijven die te veel aan de korte termijn denken en daarom hun aanpassingen nooit upstream sturen. Op lange termijn hebben ze daar vooral zichzelf mee omdat ze bij hun volgende apparaat of software alles opnieuw moeten doen, maar dat is niet het probleem van de projectmanager van de dag. Met een beetje pech wordt er dan een eiland gebouwd waar je nooit meer vanaf komt.

Toch heb ik nog steeds liever die situatie dan closed source software die je niet zelf kan repareren of verbeteren als dat nodig is.

[2green]

Dit is een terugkerend issue en je hebt echt vele handen nodig om ze te tellen.

Maillists staan er vol mee en dit is niet eens een issue dat upstream speelt. Is gewoon een fabrikant dat zijn eigen baksels inbouwt (tevens leverancier aan enkele overheden).

Upstream patchen is een pain in the ass en duurt laaaaang, snap het wel. Maar blijf dan met dergelijke hacks in userspace waar je als ontwikkelaar wat meer aan het handje genomen wordt. Of maak gebruik van je netwerk om dit soort patches te laten reviewen als dat echt niet lukt. Is echt schandalig laag niveau dit.

[CAPSLOCK2000]

En jij hebt de kennis om dat voor alle door jou gebruikte software te doen?

Gegeven genoeg tijd en/of geld wel. Als ik de tijd niet heb kan ik altijd iemand inhuren om het voor me te doen.

Maar waarom vraag je dat? Ik hoef toch niet alles zelf te kunnen repareren voordat het nuttig is dat je sommige zaken wel zelf kan repareren? Er zijn toch ook mensen die wel zelf een lekke band kunnen repareren maar niet zelf een motorblok vervangen?

[R4gnax]

Er zijn toch ook mensen die wel zelf een lekke band kunnen repareren maar niet zelf een motorblok vervangen?

In dit geval komt het neer op Jaap op de hoek (Samsung) die - al zegt hij het zelf, maar niemand gelooft het - vrij deftig de binnenband van z'n fiets kan plakken (userspace code)) en vervolgens in een helder moment bedenkt dat zo'n mooie flexibele band ook vast wel als vervanging voor de drijfriem van de motor in z'n auto (kernelspace) zal werken, ipv dat ie weer langs de garage moet. Spaart weer mooi wat pegels uit, toch?

[CivLord]

Maar dat maakt het dus vooral een theoretisch voordeel van open source.
Je vertrouwt er op dat iemand anders het wel voor je zal fixen.

[CAPSLOCK2000]

Hoezo is het dan theoretisch?
Ik doe het regelmatig, het is dus gewoon praktisch.

Natuurlijk kan ik niet alle problemen van de wereld oplossen. Net als bij alle problemen moet ik een afweging maken tussen hoeveel geld/tijd het kost en hoe groot het probleem is.

Gelukkig zijn er meestal inderdaad anderen die het probleem al hebben opgelost als het echt serieus is, maar ik hoef op niemand te vertrouwen.

Het belangrijkste is dat ik die overweging zelf kan maken. Als de auteur/leverancier niet meewerkt of niet genoeg haast maakt kan ik het zelf (laten) doen. Mijn keuze.

[blinchik]

Dat is dus geen probleem, maar een groot voordeel qua customisatie.

Mijn audi heeft lane assist. Heel handig bij het rijden, hij volgt de rijweg automatisch. Mijn vader vindt dit irritant, en heeft deze optie dus niet.

In de Windows wereld heb je deze keuze niet, maar ik vind het dus een enorm voordeel dat je een richting uit kan gaan die je wil.

[K-aroq]

Maar als je op die manier gaat werken wordt OSS nooit volwassen.

[beerse]

Het feit dat android een linux kernel gebruikt houdt in dat het bij linux ook speelt. En omdat de linux kernel veel breder gebruikt wordt dan android, houdt het in dat het daar nog veel 'erger' is. Al hoeft dat niet erg te zijn.

Bij linux distributies is het gebruikelijk dat er 'back-ports' zijn: updates op een bepaalde kernel-versie die ook als patch op oudere kernels worden toegepast.

En dat fabrikanten het innerlijk van android aanpassen is logisch: Zij harken de hardware bij elkaar en zullen er voor moeten zorgen dat de bijgaande firmware en drivers in hun android/linux implementatie/distributie zit. Zij hebben daar dan te maken met de licenties op de firmware en drivers die dan ook weer gekoppeld zijn aan bepaalde linux en android versies....

[ikweethetbeter]

Het feit dat android een linux kernel gebruikt houdt in dat het bij linux ook speelt. En omdat de linux kernel veel breder gebruikt wordt dan android, houdt het in dat het daar nog veel 'erger' is. Al hoeft dat niet erg te zijn.

Hoeveel Linux forks zijn er? En hoeveel van die forks worden gereviewd door een grote groep mensen? En op hoeveel PC's draaien die Linux varianten? Ik heb deze cijfers niet, maar stel dat er tientallen forks van actuele Linux versies zijn, en elke fork door tientallen (onafhankelijke) mensen gereviewd worden.

Bij elke Android versie heeft elke fabrikant waarschijnlijk al verschillende kernel forks per telefoon (per submodel / regio / hardwareset). Ik verwacht niet dat de Samsung kernel code buiten Samsung gereviewd wordt, maar elk model staat wel weer garant voor miljoenen verkochte exemplaren.

Daarom denk ik dat het probleem bij Android "erger" is dan bij Linux.

[Rudie_V]

Dit is natuurlijk het probleem van Android: fabrikanten wijzigen niet alleen de schil, het uiterlijk, maar ook het innerlijk,

Maar je moet je afvragen of het wenselijk en handig is om daarvoor de kernel zelf aan te passen, had het ook niet gekund door de toevoeging in kernel space te draaien?

[ikweethetbeter]

Dat zou mogelijk beter zijn geweest, maar ook dat wordt niet afgedwongen.

[mg794613]

Nee niet "probleem" "van" Android.
Probleem van Samsung.
Anders is "open source" een bug. En dat is het niet.

[toro]

Is het dan niet beter om het een soort van backdoor te noemen

Immers je verkrijgt root rechten door het te exploiten.

[nst6ldr]

Nee, want dat mag je alleen zo noemen als het een Amerikaans merk betreft.

Bitterheid terzijde, dit mes snijdt aan twee kanten: goed dat Samsung tot de orde wordt geroepen om onveilige praktijken, maar ik had liever dat een extern/third party beveiligingsonderzoeker dit had gedaan. Google heeft Android al dermate ver ingevorderd dat mensen tegenwoordig niet beter weten dan dat het een Google product is, dit bericht is stap één naar een Google dat effectief alle Android-toegepaste fabrikanten onder de duim heeft.

De volgende stap wordt dat Android One de enige vorm/image is die overblijft, en dan is het einde zoek. Hopelijk ontstaat er dan wel weer een vacuüm op de markt dat gevuld kan worden met een nieuw Europees OS. Tegen die tijd hoop ik dat o.a. Sailfish ver genoeg gevorderd is om afspraken te gaan maken met ontwikkelaars.

[Reactie gewijzigd door nst6ldr op 23 juli 2024 19:23]

[Verwijderd]

Wat is de toegevoegde waarde van die onafhankelijke derde partij als Google gewoon hun bevindingen hard kan maken?

[nst6ldr]

Dat staat letterlijk in m'n post: omdat Google hiermee het signaal afgeeft dat ze de koers van Android (een opensource project) bepalen. Natuurlijk doen ze dit op papier al, maar bovenstaand bericht is gewoon marketing om dit te bevestigen voor het publiek/de markt.

[Verwijderd]

Uhm nee. Google vraagt om het of niet te doen, of de aanpassingen upstream te sturen.

[ajolla]

En wie is dan die 'upstream'? Google? Of Linus misschien beter.
Ik vind het nogal een arrogante vertoning, waarschijnlijk om authoriteit te suggereren die er misschien helemaal niet is. Alsof er bij Samsung geen competente ontwikkelaars zouden zitten.
Google heeft een bug in Samsungs kernel gevonden en maakt er meteen een drama van om Samsung in het openbaar even te kakken te kunnen zetten. Mag ik nu aannemen dat er in Googles werk nooit een bug heeft gezeten?

[Verwijderd]

Upstream is natuurlijk gewoon de gedeelde AOSP source.

[Verwijderd]

Tsja, zo kan je van alles wel iets negatiefs maken. Blij dat Samsung tot de orde wordt geroepen, door wie het gebeurt interesseert me werkelijk niets.

Het gaat wat mij betreft om de boodschap, niet om de boodschapper.

[Gomez12]

Ik denk dat je opensource niet echt begrijpt.

De term zegt niets meer of minder dan dat de source open is. Het zegt niet dat jij er iets aan mag wijzigen, of dat je er geen eigenaar van zou kunnen zijn of weet ik veel wat voor ideeen je in je hoofd hebt.

[Streamert]

De volgende stap wordt dat Android One de enige vorm/image is die overblijft, en dan is het einde zoek.

Hoe blij zouden de mensen worden van een Android4all versie?! Android One maakt dat iedere telefoon begrijpelijk is en hetzelfde werkt. De eventuele skin mag je dan zelf aanpassen.

[nst6ldr]

Hoe blij zouden de mensen als ik worden van een Android4all versie?! Android One maakt dat iedere telefoon voor mij begrijpelijk is en hetzelfde werkt. De eventuele skin mag je dan zelf aanpassen.

Ik heb je post aangepast zodat hij wat meer in lijn der realiteit is. Minder variatie is nooit goed voor de consument.

[R4gnax]

Minder variatie is nooit goed voor de consument.

Minder variatie in de kernel, of liever gezegd; de kernel overlaten aan de experts en er niet zelf in zitten modderen, is wel degelijk goed. De staat van de kernel staat totaal, en dan ook totaal, los van de user interface en de algemene gebruikservaring.

Je relaas raakt dus kant noch wal.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:23]

[nst6ldr]

Heel vriendelijk bedankt, maar dat durf ik tegen te spreken. Afwijken van de kernel zal soms moeten als je bepaalde features wilt implementeren...

...en dat gaat niet als Google daar een ijzeren greep op heeft...

...en dus heeft Google alle fabrikanten onder de duim. Dat is exact waar ik op doel.

[R4gnax]

Heel vriendelijk bedankt, maar dat durf ik tegen te spreken. Afwijken van de kernel zal soms moeten als je bepaalde features wilt implementeren...

...en dat gaat niet als Google daar een ijzeren greep op heeft...

...en dus heeft Google alle fabrikanten onder de duim. Dat is exact waar ik op doel.

Google wil alle fabrikanten onder de duim houden?

Google probeert juist een stabiele ABI door te trekken voor de Android Linux Kernel, iets waar de Linux community al tijden tegen ageert omdat het closed-source drivers in de hand zou werken.
(Realiteit is dat sommige hardware vendors dat nu toch al afdwingen. En een ander deel officiële Linux support dan maar liever links laat liggen.)

Wat voor Android alleen wel het geval is, is dat met een stabiele ABI de kernel modulair gemaakt kan worden, om via een veilige wijze toevoegingen te maken om bijv. meer exotische closed-source vendor hardware drivers te ondersteunen zonder dat ondersteuning vooraf ingebakken hoeft te zijn, of er een custom kernel image gebrouwen hoeft te worden.

Dat biedt echt wel voordelen voor beide kanten van het verhaal. En het staat customization niet direct in de weg. Er is nog best wat mogelijk met zo'n model.

Wat leesvoer

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:23]

[CivLord]

De volgende stap wordt dat Android One de enige vorm/image is die overblijft, en dan is het einde zoek. Hopelijk ontstaat er dan wel weer een vacuüm op de markt dat gevuld kan worden met een nieuw Europees OS. Tegen die tijd hoop ik dat o.a. Sailfish ver genoeg gevorderd is om afspraken te gaan maken met ontwikkelaars.

Nee. Dit gaat niet om het aanpassen van Android, al dan niet met een eigen schil. Dit gaat om het aanpassen van de Linux-kernel waar Android op draait.

[Bor]

Een backdoor is feitelijk een opzettelijk aangebrachte manier om buiten detectie en andere beveiligingsmaatregelen om zaken te kunnen uitvoeren. Een bug die tot root rechten leidt is niet per definitie een backdoor in de meest gangbare definitie.

[Reactie gewijzigd door Bor op 23 juli 2024 19:23]

[yade]

Een backdoor die op een bug lijkt levert plausible deniability, en mensen die je beschuldigen voor het bewust aanbrengen van backdoors worden dan makkelijker weggezet als complotdenkers.

[ViTO_xp]

Het voornaamste doel van het vinden van exploits is uiteindelijk het verkrijgen van volledige controle (lees root rechten).

Een backdoor is het bewust aanbrengen (al dan niet verstopt in de code) van een achterdeur die je volledige controle geeft.

Van dat laatste lijkt me in dit geval geen sprake.

[F_J_K]

Bij mijn weten is de hele kernel 'gewoon' open source. https://android.googlesource.com/
Dan nee geen exploit o.i.d.

Desondanks kan een 'fork' maken heel vervelend uitpakken als Samsung het als meer dan tijdelijke maatregel zou doen. Wat hier dus fout lijkt te gaan.

Aan de andere kant vind ik het eigenlijk wel prettig dat er meer paren ogen kijken naar ook de kernel code. Dat maakt de kans op misbruik weer kleiner. Maar beter zou zijn als Google zelf het probleem dat Samsung schijnbaar zag sneller had opgepakt en/of na verificatie opneemt in de bron.

[Reactie gewijzigd door F_J_K op 23 juli 2024 19:23]

[Slavy]

Is dit alleen voor de A50 of bijvoorbeeld ook de A40?

[Kenhas]

uit de link in het artikel

his blog post discusses a bug leading to memory corruption in Samsung's Android kernel (specifically the kernel of the Galaxy A50, A505FN - I haven't looked at Samsung's kernels for other devices).

[Verwijderd]

Ondanks dat ze onderzoeker het niet getest heeft lijkt me op basis van de soort aanpassing verder best aannemelijk dat Samsung niet alleen voor de A50 met de kernel heeft lopen pielen.

[rko4u]

Dit toont maar weer aan dat Google geen Microsoft is. Waar Windows met een enorme compatibiliteit alles maar moet ondersteunen, voelen (vermoedelijk niet gehoorde) ontwikkelaars bij samsung het nodig om de kernel aan te passen en zo de mogelijkheden te krijgen die ze nodig hebben.

Het zou fijn zijn als Google zou samenwerken met Samsung.

[batjes]

Zeer waarschijnlijk zit hier wel de kern van het probleem. Fabrikanten voelen zich al heel snel genoodzaakt om ingrijpende wijzigingen door te voeren in Android om bepaalde functionaliteit werkend te krijgen voor hun omgeving/hardware. Wat niet op een vrij simpele manier kan. Op Android (Linux) moet je dan iets direct op de kernel bouwen of je mag in de libraries gaan graven.

De Linux kant valt vaak wel over bepaalde keuzes in Windows, maar op dit vlak is het daar toch wel wat beter geregeld.

[jvnknvlgl]

Bijzonder dat Google zich zo uitspreekt tegen Samsung, dat is nog niet eerder gebeurd. Hopelijk zetten ze hier een precedent mee en gaan manufacturers zich beter houden aan de lijn van de Linux-kernel, zoals Google ook probeert te doen: https://www.reddit.com/r/android/comments/ezrb1y/_/

[Reactie gewijzigd door jvnknvlgl op 23 juli 2024 19:23]

[Pietervs]

Zolang het geen consequenties heeft (bijvoorbeeld het weigeren van de Google-apps voor bepaalde types Samsung telefoons) denk ik niet dat het veel indruk zal maken, jammer genoeg.

[CivLord]

Dat kunnen ze nu doen, omdat nu blijkt dat het een beveiligingsprobleem heeft veroorzaakt.
Misschien is al eerder op de mogelijkheid gewezen, maar kregen ze toen te horen dat Google zich met z'n eigen zaken moest bemoeien.

[Fredi]

Tja, Samsung en software is dan ook niet altijd een goed huwelijk.

[rijnsoft]

Het is natuurlijk raar dat Google zich maar overal mee bemoeid. Niet alleen bestieren ze het Android platform, de Play Store, de hoofd Apps, etc. Ze gebruiken het om geld mee te verdienen, en de concurrentie maakt geen kans. Als software maker of adverteerder ben je aan ze overgeleverd. Als ze dan de concurrentie, die net als zij mobieltjes maken, ook nog eens gaan bekritiseren, wordt het wel heel raar. Ik heb al lang geleden geconcludeerd dat Google opgesplitst zou moeten worden.

[Ghxst]

Ben wel benieuwd of SafetyNet deze wijzigingen kan oppakken, wat daarmee uiteindelijk tot negatieve user experiences zou kunnen leiden om dat je bank app ineens niet meer werkt bijvoorbeeld.

[BikkelZ]

Ook rijkelijk frustrerend dat allerlei fabrikanten waaronder Nokia en Xiaomi lopen te fucken met bread and butter features zoals notificaties.

[abbringm]

Oh maar dan zet je er toch gewoon LineageOS op ...

Uhhh ... oh nee die is er niet voor de A50 , in tegenstelling tot de meeste andere gangbare modellen van Samsung. Hoe kan dat? Wat is er aan de hand met dit ding? Het is wel 1 van de meest verkochte toestellen van het moment namelijk en terecht gezien prijs/prestatie.

Dat de toevoegingen van fabrikanten je telefoon zelden beter of veiliger maken mag genoegzaam bekent zijn. Het blijft een raar fenomeen dat elke telefoon z'n eigen aangepaste operating systeem versie heeft. De meeste operating systemen detecteren je hardware bij installatie en zorgen dat daardoor iedereen dezelfde versie draait met hooguit wat verschil in welke ingebouwde hardware drivers worden gebruikt. Bij een telefoon blijkt vaak vooral de camera nogal te verschillen van model tot model. De andere verschillen zijn, alle hype then spijt, makkelijk af te vangen met wat feature toggles en drivers.

[NathanVerkerk]

Dit doet pijn om te horen als je net (3 maanden) een a50 heb als eerste samsung telefoon.