x Tutti
Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV.
Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro.
Possibile che non vi entra in testa questa cosa tanto semplice ?
NON è possibile, ed infatti siamo tutti completamente d'accordo su questa cosa. Su cosa fanno i Lock Bits mi pare che QP col suo ultimo intervento abbia piantato una pietra miliare, penso che non sia più necessario spiegare altro.
Possibile che non capite che se bloccate nel vero senso della parola la cancellazione del micro tramite programmatore poi lo potete buttare via se dovete aggiornarlo ? Una volta esistevano i micro OTP (One Time Programming) che si programmavano solo una volta, sono spariti non appena la flash è scesa a costi accettabili perché era veramente assurdo dover sostituire il micro per fare un update del software.
Anche questo è chiarissimo ed io avrò scritto parecchie volte che non aspiro a realizzare il micro bloccato per sempre, sarei stupido!
Quindi nessuno nega tutto questo, e questo era il senso delle mie affermazioni precedenti. La questione che sto ponendo e su cui orami quasi tutti sono d'accordo è che:
- L'utente standard di Arduino programma un microcontrollore o mediante IDE o mediante AVRDUDE e, nella stragrandissima maggioranza dei casi, NON è in condizione di attivare/disattivare parametri.
- Se gli consegni un micro programmato per lavorare in standalone e con i lock bit settati per la protezione in lettura (non vuoi che possa copiare il firmare) e scrittura (non vuoi che lo possa sovrascrivere accidentalmente) e lui lo collega al suo Arduino via ISP, per vedere se è vero
, cosa ottiene?
a - effettivamente non riesce a leggere
b - però riesce a scrivere e fa la czzt e perde il firmware (lasciamo stare se è sciocco o meno)
e tutto questo senza fare niente di particolare, perché? perché ArduinoISP e AVRDUDE (che poi è la stessa cosa...) hanno abilitato di default il chip_erase.
Cioè TUTTO si riduce ad una sola cosa: per me è ridicolo dare la possibilità di proteggere un micro mediante programmazione e poi impostare gli strumenti ordinari di manipolazione in modo tale che la protezione venga spazzata via anche se l'utente NON lo desidera (qui non parliamo di programmatori nel senso stretto del termine, tipo il Dragon). E' come se io esco di casa, metto 4 mandate di chiave di sicurezza e poi lascio la chiave attaccata alla porta. IO NON HO DETTO CHE LA PORTA NON SI CHIUDE con questo sistema, ma solo che il sistema è inutile perché la chiave è attaccata alla porta
.
Chiudo dicendo che tutta sta discussione non si sarebbe mai fatta se semplicemente si fosse mantenuto il chip erase disabilitato di default. In questo caso l'utente standard NON sarebbe stato messo in condizioni di poter sbagliare involontariamente, mentre quello più evoluto avrebbe potuto a suo piacimento attivare l'opzione chip_erase e cancellarlo.