[Milkymist-devel] NOR corruption analysis 3/4, a subtle gotcha

[Xiangfu Liu]

Hi

please update your reflash_m1.sh. the new version reflash_m1.sh have fix wrong lockflash command.
   https://raw.github.com/milkymist/scripts/master/scripts/reflash_m1.sh

we can also use
  ./reflash_m1.sh --lock-flash for lock the rescue partition without reflash images.

thanks Werner

On 10/14/2011 09:54 AM, Xiangfu Liu wrote:
> On 10/13/2011 02:37 AM, Werner Almesberger wrote:
> ...
>> Table 7 has the correct wording: "[...], all of the Block lock bits
>> that are set are cleared in parallel." Interestingly, section 10.1
>> calls the command "Clear Block Lock Bits".
>>
>> Practical implications of this:
>>
>> - UrJTAG has a subtle failure mode in the sense that explicitly
>>    unlocking a block or writing a block (with hard-coded implicit
>>    unlock) will unlock the entire NOR.
>>
>> - if Flickernoise unlocks any NOR blocks during an update and
>>    doesn't lock everything that's meant to be read-only afterwards,
>>    this would also remove the protection.
>>
>
> Hi
>
> good news is: there is no 'unlock' used in flickernoise(rtems driver)
>
>> - the protection we get is a little weaker than expected, because
>>    any random occurrence of the two-byte unlock sequence could unlock
>>    the NOR, after which it would be vulnerable to regular NOR
>>    corruption. This may still be a very unlikely event, though.
>>
>> - the process for setting up the M1rc3 being shipped should be
>>    checked if the lock bits are really set at the end. At least my
>>    version of reflash_m1.sh issues the "lockflash" before the last
>>    "flashmem".
>
> bad news is: if this is true all M1rc3 is unlocked :(