Files

Codex a9e3c2f461 Dokumentiere Philips-TV-Speicherdiagnose und Patch-Engineering

2026-08-26 19:56:27 +02:00

18 KiB

Raw Permalink Blame History

eMMC-Analyse – Philips 43PUS7394/12

Stand: 2026-08-25. Alle Geräteabfragen waren lesend. Der Grundbericht wurde aus lokal gesicherten Artefakten erstellt; der unten hervorgehobene Storaged-Nachtrag stammt aus einer späteren rein lesenden Live-Abfrage des bereits vorhandenen Android-Eventlogs.

Ergebnis in einem Satz

BEWIESEN: Zwei voneinander unabhängige Android-/Philips-Pfade berichten für Lifetime A/B jeweils 0x0a, also das höchste noch nicht überschrittene JEDEC-Band 90–100 % der geschätzten Lebensdauer verbraucht. Der Android-Eventlog enthält außerdem storaged_emmc_info: [emmc 5.1,1,10,10]; die geräteeigene Tagdefinition ordnet dies eindeutig als eMMC 5.1, PRE_EOL_INFO=0x01, Lifetime A 0x0a, Lifetime B 0x0a zu. 0x01 bedeutet für den Reserveblockindikator Normal. Die Rohbytes, CID, CSD, Hersteller und Modell bleiben gesperrt. Hoher Lifetime-Bucket und normaler PRE_EOL-Wert sind gleichzeitig möglich und bilden unterschiedliche Gesundheitsachsen; zusammen belegen sie weiterhin keinen unmittelbar bevorstehenden Ausfall.

Nachtrag: unabhängiger Android-Storaged-Wert

Die rein lesende Abfrage des vorhandenen Eventpuffers lieferte:

01-01 01:00:17.642  2644  2644 I storaged_emmc_info: [emmc 5.1,1,10,10]

Die auf genau diesem Gerät installierte Event-Tag-Definition lautet:

2733 storaged_emmc_info (mmc_ver|3),(eol|1),(lifetime_a|1),(lifetime_b|1)

Damit sind Feldreihenfolge und Werte BEWIESEN. AOSPs Android-12- storaged_info.cpp liest dafür rev, pre_eol_info und life_time aus dem MMC-sysfs und fällt bei Bedarf auf EXT_CSD-Debugfs zurück; der Kernel erzeugt die sysfs-Werte aus den entsprechenden EXT_CSD-Feldern. Dieser Storaged-Pfad ist von Philips' persistenter Property unabhängig. Die Übereinstimmung beider Lifetime-Werte schließt deshalb die frühere Hauptunsicherheit „möglicherweise nur veralteter Philips-Cache“ für diesen Boot praktisch aus. Der vollständige EXT_CSD-Rohdump bleibt dennoch nicht zugänglich.

Primärquellen:

Beweiskette

BEWIESEN

Der Boot-Log enthält die Ausgabe der nativen Philips-Komponente:
```
D eMMCLifeReader: eMMC life time 0x0a 0x0a
```
Die persistente Eigenschaft enthält aktuell denselben Wert:
```
persist.odm.tpv.sys.emmc_lifetime = 0x0a 0x0a
```
Die dazugehörige Init-Definition startet /system/bin/emmclifereader als root, oneshot. Der Dienst ist nach dem Boot erwartungsgemäß stopped.
Philips' OnBootLogger liest die Property, zerlegt sie in zwei Werte und übermittelt beide separat als dev_lt_a="a" und dev_lt_b="a".
TVStorageMonitorService.getEmmcLifetime() liest dieselbe Property. Die Bytecode-Analyse zeigt, dass dieser konkrete Warndienst nur den Text nach dem letzten x auswertet, also den zweiten Wert (Typ B). Er ordnet 0x0a selbst der Stufe 90%-100% device lifetime used zu.

SEHR WAHRSCHEINLICH, aber nicht vollständig direkt verifizierbar

Die zeitliche Boot-Ausgabe des eMMCLifeReader, seine privilegierte One-shot-Init-Definition, die anschließend identische persistente Property und zwei unabhängige Philips-Verbraucher bilden eine starke Kette dafür, dass der native Reader die eMMC-EXT_CSD-Felder beim Boot liest und die Property befüllt. Die lokal gesicherte SELinux-Policy schließt einen weiteren Teil der Kette: /system/bin/emmclifereader trägt tpvdebug_exec, und ein typetransition init ... tpvdebug_exec process tpvdebug führt den von Init gestarteten Prozess in die Domain tpvdebug. Diese Domain darf TPV-Properties setzen. Die konkrete Property-Zuordnung, der native Schreibcode und der vom Reader geöffnete Kernelpfad bleiben aber unsichtbar. Deshalb ist die Herkunft aus EXT_CSD SEHR WAHRSCHEINLICH, nicht unabhängig BEWIESEN.

JEDEC-/Herstellerinterpretation

Die Felder DEVICE_LIFE_TIME_EST_TYP_A (EXT_CSD-Byte 268) und Typ B (Byte 269) geben eine herstellerspezifisch ermittelte, mittlere Abnutzung relativ zur maximal geschätzten Lebensdauer an. Eine KIOXIA-Fachinformation reproduziert die Tabelle aus JEDEC JESD84-B51: 0x0a bedeutet 90–100 % verbraucht, 0x0b erst „maximale geschätzte Lebensdauer überschritten“. Kingston erläutert zusätzlich, dass die Werte nur in 10-%-Bändern berichtet werden und je ein Feld unterschiedliche Speicherarten/-Konfigurationen repräsentiert.

Quellen:

0x0a ist daher nicht „10 % Zustand“ und auch keine Belegungsanzeige. Es ist das Band 90–100 % der vom eMMC-Controller geschätzten Schreib-/Löschlebensdauer. Der genaue Punkt innerhalb dieses Bandes ist nicht bestimmbar.

PRE_EOL_INFO ist ein davon getrennter Indikator für verbrauchte Reserveblöcke. Die KIOXIA-Unterlage zum Bad-Block-Management ordnet EXT_CSD-Byte 267 zu: 0x01 normal, 0x02 Warnung (80 % der Reserveblöcke verbraucht) und 0x03 dringend. Der direkte sysfs-Read bleibt der Shell durch SELinux verwehrt; der unabhängige Storaged-Boot-Event exportiert jedoch eol=1. Für diesen Boot ist PRE_EOL_INFO=0x01 deshalb BEWIESEN. Wichtig: Dieser Wert wurde unabhängig gemessen; er wird nicht aus 0x0a/0x0a abgeleitet.

Identität und Kapazität

Das interne Gerät ist eindeutig eine eMMC 5.1 als mmcblk0 am MediaTek-Host 1006d000.MSDC0; /data liegt auf mmcblk0p37. Der Zugriff auf cid, name, manfid, oemid, serial, CSD und die rohe Blockgröße wird durch Rechte/SELinux verweigert. Hersteller, Modell und Seriennummer können daher nicht seriös bestimmt werden. Eine Android-/Philips-Oberfläche berichtet rund 8 GB nutzbaren internen Speicher; das ist keine Rohkapazitätsangabe der eMMC. Die vollständige statische Partitionstabelle summiert sich bereits auf 14.809 MiB (14,462 GiB) und spricht deshalb stark für eine nominelle 16-GB-eMMC. Die exakte Rohsektorzahl ließ sich am Blockgerät weiterhin nicht unabhängig prüfen.

Exakte DAC-/SELinux-Barrieren

Die lokal gesicherten Audit-, Dateikontext- und Policy-Daten trennen die Barrieren präzise:

Ziel	Unix-/DAC-Zustand	beobachtete SELinux-Barriere	Ergebnis
`/dev/block/mmcblk0`	`brw------- root root`, Major:Minor `179:0`	ein geeigneter Blockdevice-Zieltyp wäre zusätzlich erforderlich	Shell scheitert bereits an DAC; Rohgröße und -inhalt NICHT VERIFIZIERBAR
`/sys/block/mmcblk0/device/life_time`	sysfs-Knoten vorhanden	`shell:s0 -> sysfs:s0` `{ read }` verweigert; Policy gewährt Shell nur `getattr` auf generischem sysfs	Rohwert NICHT VERIFIZIERBAR
`/sys/block/mmcblk0/device/pre_eol_info`	sysfs-Knoten vorhanden	dieselbe AVC-Barriere	direkter Shell-Read gesperrt; Wert `0x01` über unabhängigen Storaged-Event BEWIESEN
CID/CSD/`manfid`/`oemid`/`serial`	sysfs-Knoten vorhanden	konkrete `{ read }`-AVCs gegen `sysfs:s0`	Identität NICHT VERIFIZIERBAR
`/sys/kernel/debug/mmc0/mmc0:0001/ext_csd`	Debugfs-Pfad und Datei durch Audit direkt belegt	`storaged:s0 -> debugfs_mmc:s0` `{ read }` verweigert, obwohl Prozess UID root besitzt; Shell wird schon an `mmc0` abgewiesen	Inhalt NICHT VERIFIZIERBAR
`/system/bin/emmclifereader`	Systemdatei, von Init als root gestartet	Shell erhält an `tpvdebug_exec:s0` weder `getattr` noch `read`; Init wechselt beim Start nach `tpvdebug`	äußere Reader-Kette BEWIESEN, Implementierung NICHT VERIFIZIERBAR
`/sys/fs/ext4/mmcblk0p37/*`	Health-Knoten wie `errors_count` und `lifetime_write_kbytes` vorhanden	alle direkten Leseversuche `Permission denied`	interne EXT4-Historie NICHT VERIFIZIERBAR

Die verfügbare Vendor-Policy gewährt dumpstate am Typ debugfs_mmc nur Verzeichnissuche, nicht den benötigten Datei-Read. Sie erlaubt dumpstate zugleich Zugriffe auf andere, generisch gelabelte Debugfs-Bereiche. Ein erfolgreicher Binder-/DMA-Buf-Debugfs-Dump sagt daher nichts über MMC-Zugriff aus. Der reale storaged-AVC beweist zusätzlich, dass Unix-UID 0 die SELinux-Type-Enforcement-Regel nicht überstimmt.

Prozess- und Rechtematrix

Prozess	UID / Domain	Speicherfunktion	belegte Grenze	Einordnung
`emmclifereaderd`	Init: root/system; Policy-Transition nach `u:r:tpvdebug:s0`	einmaliger Philips-Life-Time-Reader	Prozess beim Bugreport bereits beendet; Binary/Property-Schreibcode nicht lesbar	äußere Kette BEWIESEN; EXT_CSD als Rohquelle SEHR WAHRSCHEINLICH; genau dieser Debugfs-Pfad PLAUSIBEL
`storaged` PID 2644	root / `u:r:storaged:s0`	Android-I/O-Statistik und Boot-Healthpfad	Debugfs-Read wird durch AVC blockiert; dennoch publiziert der sysfs-/Fallback-Pfad eMMC 5.1, EOL 1, A/B 10/10	Eventwerte und Blockade BEWIESEN
TPV `storagedcapture` PID 2613	root / `u:r:tpvdebug:s0`	periodische Storage-/UID-I/O-Erfassung	sogar `getattr` auf `/proc/uid_io/stats` wird abgewiesen	root allein genügt nicht, BEWIESEN
`vold` PID 1442	root / `u:r:vold:s0`	Mount-, fscrypt- und Volumeverwaltung	kein EXT-CSD-/PRE_EOL-Export; der sichtbare `e2fsck` galt nur dem adoptierten `dm-4`	interner eMMC-Healthwert NICHT VERIFIZIERBAR
`installd` PID 2630	root / `u:r:installd:s0`	Quota-/Paket-Speicherverwaltung	erkennt `/data`-Mount, liefert keine MMC-Healthdaten	logische Speicherfunktion BEWIESEN, Hardwarezustand unbekannt
`system_server` PID 3007	system / `u:r:system_server:s0`	StorageManager und DeviceStorageMonitor	logische Schwellwerte, keine Rohregister	Belegung BEWIESEN, eMMC-Rohzustand nicht
`TVStorageMonitorService` PID 5636	system / `u:r:system_app:s0`	liest TPV-Property regelmäßig und klassifiziert Typ B	nur Property-Verbraucher	Zuordnung BEWIESEN, keine unabhängige Messung
Standard-`dumpstate` PID 21293	shell / `u:r:dumpstate:s0`	Bugreport-Sammlung	leeres Kernel-Log, keine `IDumpstateDevice`-HAL, kein Board-Dump	privilegierte Lücke BEWIESEN
TPV `ddg` / `tpv_top_service`	root / `u:r:dumpstate:s0`	OEM-Diagnosedaemons	im Artefakt kein eMMC-Health-Export	Fähigkeit dazu NICHT VERIFIZIERBAR
TPV `errlogservice`	system / `u:r:hal_tv_errlogservice_default:s0`	OEM-Fehlerlogdienst	`lshal debug` endet mit `FAILED_TRANSACTION`	Inhalt NICHT VERIFIZIERBAR

Die AOSP-Historie enthält inzwischen einen Storaged-Fix mit genau derselben AVC-Zeile und demselben Pfad. Der Commit erklärt den Zugriff als veralteten Storaged-Init-Control-File-Pfad und beseitigt ihn, statt storaged pauschal MMC-Debugfs-Rechte zu geben. Das bestätigt die technische Einordnung des Audits als reale SELinux-Sperre, beweist aber nicht, dass Philips' emmclifereader denselben Pfad verwendet. Quelle: AOSP storaged: Fix SELinux denial with debugfs_mmc.

Fehler- und Korruptionslage

BEWIESEN ist, dass die direkt zugänglichen Android-Logs zeigen:

keinen EXT4-fs error, Buffer I/O error, blk_update_request, ENOSPC oder fehlgeschlagenen Update-Engine-Vorgang;
einen einzelnen Icing-Fehler Array storage bad crc in einem App-Index;
erfolgreichen aktuellen Dateisystembetrieb: /data ist rw eingehängt und das vom Auftrag ausdrücklich verlangte dumpsys diskstats meldete einen [512B Data Write]-Latenztest. Dieser interne 512-Byte-Test ist die dokumentierte Transparenz-Ausnahme und wurde nicht wiederholt.

Der isolierte Icing-CRC-Fehler belegt einen beschädigten Indexdatensatz, ordnet die Ursache aber nicht dem eMMC-Medium zu. Softwareabbruch, unvollständiger Schreibvorgang und Medienfehler sind damit nicht unterscheidbar.

Wesentliche Einschränkung: dmesg, Kernel-Log, EXT_CSD, errors_count, first_error_time, last_error_time und lifetime_write_kbytes sind dem ADB-Shell-Kontext verwehrt. Deshalb bedeutet „keine zugänglichen I/O-Fehler gefunden“ ausdrücklich nicht, dass Kernel oder eMMC nie Fehler registriert haben. Der Nichtfund ist nur BEWIESEN innerhalb des sichtbaren Diagnosefensters; die vollständige historische Fehlerlage ist NICHT VERIFIZIERBAR.

Evidenzbewertung

Aussage	Stufe	Begründung
Philips' nativer Reader meldete beim Boot `0x0a 0x0a`	BEWIESEN	native Boot-Logzeile
Property und Telemetrie enthalten beide A/B-Werte `0x0a`	BEWIESEN	Property, OnBootLogger, `dev_lt_a/b`
Beide Werte bedeuten 90–100 % Lebensdauer verbraucht	BEWIESEN	JEDEC-reproduzierende Herstellerunterlagen und Philips-Zuordnung
TVStorageMonitor bewertet Typ B als 90–100 % verbraucht	BEWIESEN	DEX-Analyse und wiederholter Laufzeitlog
Init startet den Reader als root in der SELinux-Domain `tpvdebug`	BEWIESEN	Init-RC, File-Context und Policy-`typetransition`
Android Storaged meldet eMMC 5.1, PRE_EOL `0x01`, A/B `0x0a/0x0a`	BEWIESEN	Boot-Event plus lokale Felddefinition; AOSP-Code ordnet sysfs/EXT_CSD zu
Philips-Property spiegelt den aktuellen Hardwarewert dieses Boots	SEHR WAHRSCHEINLICH	unabhängiger Storaged-Wert stimmt für A/B exakt überein; Philips-Binary bleibt gesperrt
Reader verwendet genau den beobachteten Debugfs-Pfad	PLAUSIBEL	passendes Gerät und EXT-CSD-Pfad vorhanden; kein Reader-Open-Audit
`PRE_EOL_INFO=0x01` (Normal)	BEWIESEN	`storaged_emmc_info` und geräteeigene Event-Tagdefinition
CID, CSD, Hersteller und Modell	NICHT VERIFIZIERBAR	direkte sysfs-/Debugfs-Reads werden verweigert; kein OEM-Export
Keine MMC-/EXT4-Fehler im sichtbaren Textfenster	BEWIESEN	exakte Volltextsuche; alle vier automatischen Treffer fachlich verworfen
Historisch keine MMC-/EXT4-Fehler	NICHT VERIFIZIERBAR	Kernel-Log, PStore und EXT4-Zähler fehlen
eMMC fällt unmittelbar aus	NICHT VERIFIZIERBAR	`0x0a` ist ein grobes Band; PRE_EOL ist noch normal, Fehlerzähler fehlen
eMMC ist gesund	nicht haltbar	beide Lebensdauerfelder stehen bereits im höchsten noch nicht überschrittenen Band

Ergänzung aus dem vollständigen Bugreport

Der vollständige Bugreport bestätigt Property, OnBootLogger und die wiederholte TVStorageMonitorService-Auswertung. Zusätzlich enthält er einen Boot-Audit des Android-Dienstes storaged:

root 2644 storaged: avc: denied { read }
path="/sys/kernel/debug/mmc0/mmc0:0001/ext_csd"
scontext=u:r:storaged:s0
tcontext=u:object_r:debugfs_mmc:s0

Damit ist der vorhandene EXT_CSD-Knoten für das konkrete Gerät mmc0:0001 direkt belegt. Der Audit beweist aber auch, dass selbst ein Prozess mit Linux-UID root nicht genügt: SELinux blockiert die storaged-Domain. Für eine Direktmessung wäre ein autorisierter OEM-/Engineering-Kontext mit passender Policy nötig.

Der gespeicherte Haupttext des Bugreports enthält keinen ausgeschriebenen PRE_EOL_INFO-Wert; die später rein lesend abgefragte Eventlog-Ringpuffer- Ausgabe enthält ihn jedoch als eol=1. Die Kernel-Log-Sektion ist wegen klogctl-Fehler leer, und dumpstate meldet No IDumpstateDevice implementation; ein Philips-/TPV-Board-Dump wurde nicht erzeugt. In allen verfügbaren Textartefakten wurden keine MMC-Timeouts, CRC-/ECC-Fehler, Controller-Resets, Block-I/O-Fehler, EXT4-/Journal-Fehler oder Read-only-Remounts gefunden. Die Treffer mit „I/O error“ waren TLS-/Netzwerk- Fehler. Das ist nur eine Aussage zum verfügbaren Diagnosefenster, kein Gesundheitsbeweis.

AOSP dokumentiert IDumpstateDevice als optionale, vom OEM zu implementierende HAL. Der OEM bestimmt, welche Boarddaten sie in einen Standard-Bugreport aufnimmt; die Implementierung benötigt regelmäßig passende SEPolicy-Regeln. Das Fehlen der HAL auf diesem Build erklärt daher konkret, weshalb dumpstate keinen privilegierten TPV-Health-Dump nachliefert. Quelle: AOSP: Scoped vendor logging / IDumpstateDevice.

Die Beweiskette ist damit unabhängig doppelt: Android Storaged berichtet eMMC 5.1/EOL 1/A 10/B 10, während Philips separat A/B 0x0a/0x0a persistiert und auswertet. Nur der genaue native Philips-Readerpfad und der vollständige EXT_CSD-Rohdump bleiben unlesbar.

Weitere Details: Bugreport-Analyse. Die vollständige lokale Rechte-/Prozessmatrix ist nicht veröffentlicht; die technische eMMC-/Kernel-Auswertung steht in Tiefe eMMC-/Kernel-Forensik.

Rohdaten

raw/emmc/emmc-identity-and-access.txt
raw/emmc/emmc-property-init-and-bootlog.txt
raw/emmc/emmc-filesystem-health-access.txt
raw/emmc/usagelogger.apk

Legitimer nächster Beweisweg

Für die Speicherwarnungsursache ist keine Privilegieneskalation nötig. Für die noch offene eMMC-Ausfallprognose wäre der risikoärmste, technisch vollständige Weg ein autorisierter Philips/TPV-Service- oder Engineering-Export, der ausschließlich lesend liefert:

EXT-CSD-Bytes 267, 268 und 269 sowie den vollständigen EXT-CSD-Dump zur forensischen Gegenprüfung der bereits exportierten Werte;
CID/CSD und Herstellerkennung;
EXT4-Zähler für mmcblk0p37;
Kernel-/PStore-Zeilen zu mmc0, mmcblk0, ext4 und jbd2;
Reader-Zeitstempel und Rückgabestatus, um einen persistenten Altwert sicher auszuschließen.

Geeignete legitime Mittel sind ein signierter, exakt passender OEM-Servicebuild, ein Philips/TPV-Werkstatttool oder eine zukünftige Firmware mit korrekt implementiertem IDumpstateDevice. Ebenfalls ungefährlich wäre die lokale statische Analyse einer offiziell bezogenen passenden Firmware. Root-Exploit, Bootloader-Entsperrung, Recovery oder Flashen sind dafür weder erforderlich noch angemessen.

18 KiB Raw Permalink Blame History Unescape Escape