[bcn-pm] Workshop de Raspberry Pi

[xdrudis]

On Tue, Apr 30, 2013 at 01:52:51PM -0700, Salvador Fandino wrote:
> 
> No solo para arrancar, los drivers graficos siguen sir ser libres. Dijeron que los liberaban pero en realidad solo publicaron una capa muy simple que implementa una especie de RPC que delega todo en un BLOB que se carga en la GPU. Osea que no hay forma de estudiar el codigo, ni de corregir bugs y no hablemos ya de las implicaciones de seguridad de todo esto.
> 
> Desde el punto de vista del software libre, la arquitectura ARM es deprimente...
> 


Exacte. La ARM, la Intel i l'AMD. No n'hi ha cap de bona, però tampoc
són totes iguals. El que passa és que hi ha alguns processadors que
poden funcionar sense programari privatiu (sempre que no facis servir
acceleració 3D, acceleració de codecs de video o algunes
funcionalitats) i n'hi ha que sense programari privatiu no arrenquen.
Els que poden funcionar sense programari privatiu pot ser que el
portin incrustat, però l'única manera d'evitar això seria maquinari
obert.

Els bootloaders (BIOS, UEFI, x-loader, uboot...) no només carreguen el
sistema operatiu, li passen el control i surten del mig. Això és el
que jo em pensava fa temps. Però segueixen controlant el sistema tota
l'estona. Els processadors actuals porten mesures de control remot
(Intel TXT, Intel AMT, Intel vPro, AMD DASH, ARM TrustZone, etc.).  Un
ordinador realment controlat per l'usuari no pot implementar DRM i un
de teledirigit té força avantatges (pel fabricant, els editors de
continguts i els serveis d'intel·ligència, :( ).

Fa 20 anys, des del 80386SL i 486 hi ha un mode de funcionament de la
CPU que es diu System Management Mode que és fora del control del
sistema operatiu (si la CPU s'inicialitza així) igual com el sistema
operatiu és fora del control de les aplicacions. La BIOS, UEFI o el
programari incrustat del sistema (a la EPROM de la placa mare, al
propi SOC o al bootloader) estableix el codi que ha d'executar en
SMM. Aquest codi té accés a tota la memòria, CPU i perifèrics,
s'executa quan el maquinari o el sistema operatiu genera interrupcions
especials (SMI) i el sistema operatiu o les aplicacions no tenen accés
a aquesta memòria. És esencialment un hipervisor transparent
(transparent quan funciona), i s'ha fet servir per a control
d'energia, ventiladors, emulació de maquinari, gestió remota, i
rootkits. Per a processadors ARM amb TrustZone hi ha els mecanismes
per a fer el mateix. La funcionalitat maliciosa del codi SMM al
programari incrustat al SOC o placa mare està bàsicament limitada pel
pressupost de desenvolupament del fabricant. Però n'hi ha que anuncien
que el servei tècnic pot entrar remotament al sistema, mirar què hi ha
o reinstal·lar el que sigui, encara que el windows s'hagi penjat o el
PC estigui apagat (WakeOnLAN). Els que no ho anuncien tenen la mateixa
infraestructura al processador que ho permet, ves a saber si la fan
servir o com.

Llavors si vols vídeo o 3D no t'escapes de programari privatiu amb
accés a tota la memòria i tal. Si pots viure sense vídeo o 3D llavors
depén del processador. Em sembla que els Texas Intruments (PandaBoard,
GTA04 ...)  els Freescale i.MX6 (UDOO, SabreLite, NitrogenX) tenen
arrencada sense blobs però gràfics/video privatius. Em costa de seguir
perquè hi ha un fotimer de fabricants i models, i els desenvolupadors
de programari lliure també van avançant amb enginyeria inversa, però
molts projectes lliures carreguen codi privatiu quan no hi ha
alternativa i no en fan molta propaganda, també en sec els fabricants
que eren molt tancats comencen a obrirse (Tegra), etc.