IppatsuBlog

This is my new laptop: a Dell Studio 15 1557 with a Intel i7 720QM CPU.

Short review

Here’s a very short review. First, the cons:

• There are no LEDs on the keyboard. No LED for caps lock, no LED for HD activity, nothing;
• by default the function keys (F1..F12) work as multimedia key (switch off WiFi, mute, volume up and so on), but this setting can be changed in the BIOS;
• there is no numeric keypad. Usually on 15” laptops using the Fn key some keys can be used as numeric keypad, but this is not the case: there is simply no way to have a numeric keypad. This baffled me and it is annoying, especially on Windows. On the italian keyboard layout there is no “~” or “È” key, so we type them using the numeric keypad and tapping Alt+0126 or Alt+0200. Since there is no numeric keypad I have to copy&paste those characters. I’ll look for an explanation from Dell;
• the fast CPU and graphic card mean a lot of heat: the system idles at 50 °C and can easily reach 70 °C under stress.

Pros:

• the chassis is sturdy;
• the touchpad supports multitouch, allowing for some cool gestures when using Windows;
• the HD is huge (500GB);
• the i7 CPU is as fast as it can get on laptops, looking at 8 columns for CPU load in the task manager gives a warm fuzzy feeling (the i7 720QM is a quad-core CPU with hyperthreading, so  the OS thinks that there are 8 CPUs);
• the graphic card isn’t the fastest one available for laptops, but still I was able to play Mirror’s Edge with high settings;
• I can virtualize Windows XP (and use IBM DB2 on it) on Windows Vista while browsing with Firefox and chatting and installing OpenOffice and still the average CPU load is at 30%;
• the DDR3 RAM is fast;
• did I say that it is fast?

Linux on Dell Studio 15 1557

I wanted to install Linux on it, my distro of choice being Kubuntu 9.10 Karmic Koala, but plain Ubuntu should run flawlessy too. The good news is that all the hardware is supported: WiFi, SD reader, ATI card, audio, everything. The bad news is that you have to fiddle a little to make it work. Here’s some gotchas:

1. Don’t install any proprietary driver while using the Live CD. The Broadcom STA driver, needed to make the wireless work, made my system freeze. And if it freezes while it’s modifying the partition table you’ll be very, very sorry. Just install the system without doing anything fancy.
2. The wireless card is reported by lspci as 05:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01). If you have internet access via Ethernet just use the Hardware Drivers manager to install the Broadcom STA wireless driver. If you don’t have internet access use Synaptic (on Ubuntu) or KPackageKit (on Kubuntu) or apt-cdrom (everywhere) to add the installation cd-rom as software source and then use the Hardware Drivers manager.
3. To make the audio work edit as root /etc/modprobe.d/alsa-base.conf and add this line:

   options snd-hda-intel model=dell-m6

   and then execute:

   sudo alsa force-reload

And that’s it, enjoy your Linux :)

(Not so) fun fact: when rebooting the system the first time, after installing Kubuntu, the system didn’t boot, even the BIOS screen didn’t show up. It just beeped four times and then turned off. Dell’s manual says that “four beeps = possible motherboard damage”, which just doesn’t make sense. However I tried again after a couple of minutes and it worked. I don’t know why and I hope it doesn’t happen again.

A Agosto 2007 Luis Miras, lead vulnerability researcher della Intrusion, ha tenuto un interessante speech al convegno BlackHat 2007: Other Wireless: New ways to get Pwned (PDF). L’idea di Miras era molto semplice: ci sono dati trasmessi via etere “insospettabili” che possano rappresentare un rischio per la sicurezza? La risposta banalmente era sì: tutto ciò che viene digitato sulle tastiere wireless può essere intercettato da qualche curiosone di passaggio. Miras presentò dei replay attack e poco altro: tastiere e mouse wireless comunicano usando un protocollo crittato che non aveva avuto la possibilità di reversare.

Per poter effettuare l’attacco replay ha dovuto creare una periferica wireless personalizzata. Questo non è particolarmente difficile in quanto pressoché tutti i dispositivo di questo genere sono composti da tre parti: un semplice microcontrollore, una piccola eeprom e un trasmettitore. Il dongle ricevente è molto simile, con un ricevitore al posto del trasmettitore. Inoltre per l’utilizzo negli Stati Uniti questi dispositivi devono essere approvati dall’FCC: il risultato è che cercando il numero di serie di un prodotto è possibile spesso ricavare gli schematici della sua architettura.

Qualche giorno fa Max Moser e Philipp Schrödel di Dreamlab Technologies e remote-exploit.org hanno pubblicato un articolo che spiega il funzionamento del protocollo e come sia possibile sniffare le connessioni in modo estremamamente semplice.

Analizzando il protocollo hanno scoperto che caratteri come shift e alt sono inviati non crittati al ricevente wireless. La crittazione usata nell’invio di ogni carattere è uno XOR del valore del carattere con un byte ricavato da un motore casuale inizializzato con un singolo byte durante l’handshake tra la periferica wireless e la stazione ricevente connessa al computer. Sniffando l’handshake è quindi possibile intercettare facilmente tutti i tasti premuti sulla tastiera. In realtà questo non è necessario, poichè ci sono solo 256 possibili chiavi di crittazione, per cui sniffando i tasti crittati e usando gli stessi metodi statistici utilizzati per “rompere” il cifrario di Cesare, è possibile determinare la chiave corretta intercettando solo 20-50 caratteri.

I ricercatori hanno anche pubblicato un video dove mostrano il loro programma proof-of-concept sniffare e crackare la comunicazione di tre diverse tastiere. Con delle piccole antenne non dovrebbe essere difficile sniffare le comunicazioni della tastiera anche oltre il suo circa metro e mezzo di raggio di comunicazione.

Potete usare RSA a 4096 bit per usare via SSH il vostro PC, ma è tutto inutile se poi la chiave viene banalmente letta dal primo venuto abbastanza malizioso (un motivo in più per usare SSH passwordless).

Ma se usate una tastiera con filo, non pensiate di essere al sicuro (e c’è anche chi è in grado di montare questi gingilli all’interno di un laptop).

[via midnightresearch]

C’è stata una piccola tempesta nei vari blog/siti 2.0/del.icio.us/newswine (…) relativo alla supposizione che *ubuntu possa portare a un logoramento prematuro degli hard disk.

Tutto è partito da un post di linux-hero (opportunamente amplificato da digg.com) che faceva riferimento al bug #104535 di Ubuntu: il riassunto del bug è che quando viene collegato alla batteria Ubuntu attiverebbe delle impostazioni che portano a un continuo arresto e riavvio dell’hard disk, cosa che da una parte aumenta l’autonomia del sistema, dall’altra causa uno stress meccanico che può accorciare la vita utile dell’hard disk.

Inizialmente il caos ha regnato e tutti hanno iniziato a incolpare Ubuntu della rottura del proprio hard disk. In realtà le cose sono un po’ più complicate di così (come ha segnalato Matthew Garrett — sviluppatore per Debian e lead developer per Ubuntu). Per sapere se il fantomatico bug vi affligge eseguendo il comando:

grep ENABLE_LAPTOP_MODE /etc/default/acpi-support

se vi viene restituito “false” allora non correte alcun pericolo.

laptop_mode è una variabile con cui si comunica al kernel Linux che si intendono attivare alcuni comportamenti che portano a un “miglioramento” del comportamento del sistema sui laptop (ad esempio bufferizzando le scritture su disco e scrivendole a burst, diminuendo così gli accessi all’hd e allungando conseguentemente la durata della batteria).

Tale variabile si può impostare modificando il file /etc/default/acpi-support . Il problema nasce dal fatto che quando viene alimentato dalla batteria, Ubuntu esegue il file /etc/acpi/power.sh , che contiene tra le altre cose il codice:

function laptop_mode_enable {...$HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null

$HDPARM -B 1 /dev/$drive 2>/dev/null

}

Se vengono avviati, questi comandi cambiano le impostazioni del risparmio energetico dell’hard disk. Il primo comando riduce il tempo di spindown, cioè il tempo che deve passare dall’ultimo accesso prima che l’hard disk smetta di ruotare. Il valore di default, che si può leggere nel file /etc/default/acpi-support , è di appena 12 secondi. Questo continuo fermarsi e ripartire causa stress meccanico all’hard disk, accorciandone la vita utile. Il secondo comando invece imposta la politica di ACPI per l’hard disk al valore più aggressivo (eseguite man hdparm per ulteriori informazioni).

Ma questa funzione viene richiamata solo da un’altra funzione:

if [ x$ENABLE_LAPTOP_MODE = xtrue ]; then
    (sleep 5 && laptop_mode_enable)&
fi

Questo vuol dire che se la variabile ENABLE_LAPTOP_MODE allora verrà richiamata la funzione laptop_mode_enable riportata sopra. Di default, come si può controllare sempre nel file /etc/default/acpi-support , tale variabile è impostata a false, per cui l’odiatissimo codice che corrode gli hard disk non verrà abilitato.

Questo vuol dire che di default Ubuntu non modifica le impostazioni di risparmio energetico, e coloro che hanno osservato un aumento del valore di load_cycle_count (visualizzabile con sudo smartctl -A /dev/sda dove sda potrebbe cambiare e essere hda, hdb,… o sdb, sdc…) sono “vittime” delle impostazioni aggressive per il risparmio energetico impostate nel bios o nel firmware presente sui laptop. Ubuntu, di default, non modifica alcunché per questo aspetto.

Come osserva Matthew Garret, si potrebbe affermare che Ubuntu dovrebbe forzare politiche che non portino all’usura dell’hardware, ma del resto si suppone che il produttore del portatile ne sappia più degli sviluppatori di Linux su cosa quell’hardware possa o non possa fare.