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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to