Re: [PATCH] mmc: boot partition ro lock support

[J Freyensee <james_p_freyensee@linux.intel.com>]

On 10/22/2011 11:38 PM, Chris Ball wrote:
> Hi Sebastian,
>
> On Sat, Oct 22 2011, Sebastian Rasmussen wrote:
>> Hi!
>>
>>> What we're worried about is someone issuing the perm read-only command,
>>> and not realizing that it really means that they can never ever write
>>> any more changes to their eMMC -- it's a one-time fuse
>>
>> I can see why you are worried that people may brick their devices.
>> How about only adding the read-only-until-power-cycled command?
>
> I think that makes sense.  I'd be curious to hear if anyone thinks we
> shouldn't even add that command, perhaps on grounds that "the kernel
> shouldn't be enthusiastic about locking itself out of future access to
> a device" or similar.  As you say, the ioctl interface would still work.

The only reason why I could think you would want a command like that is 
if the kernel goes viral on a normal user on say, a cell phone.  Then 
this would be more of defensive mechanism that would be tripped.

I think if a hacker/kernel-modifier bricks their device, then that was 
their risk, but for a normal user (which makes up the majority of 
Android phones in which Android is the majority smart phones out there), 
it should be hard to brick a device.

Jay

>
>>> I'd rather leave it to specialized manufacturing equipment.
>>
>> Sure, but then again permanent read-only commands seem to be
>> able to be sent by writing a userspace tool that issues a ioctl(fd, 0xb3, ...)
>> using the generic command interface by John Calixto mentioned by
>> Andrei. I assume that what reassures you in this case is
>> that CAP_SYS_RAWIO is required and perhaps also obscurity?
>
> Yes, that's right -- running a userspace program that you explicitly
> downloaded from somewhere and compiled is more intentional than
> wondering what a kernel argument or sysfs node does and trying it.
> (Maybe I'm special, but I often use kernel arguments and sysfs nodes
> without reading their code or finding the best documentation for them
> first, when trying to get something to work.)
>
> Thanks,
>
> - Chris.


-- 
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation