On Thu, Mar 31, 2011 at 2:37 PM, Chris Ball <c...@laptop.org> wrote: > Hi, > > On Thu, Mar 31 2011, Andrei Warkentin wrote: >> Plus what if you do intend to have a file system there? Other than >> complexity and non-obvious usage, I don't see >> anything gained by this. I wouldn't worry about ways of misusing this. >> As I've said, in the only case it matters (some embedded device >> booting from the boot partition), the user would have to gain root >> access, build a kernel giving access to the boot partitions and be >> able to boot into it. So a warning in Kconfig is sufficient. >> >> If you guys feel concerned, then we can add another Kconfig option >> that will allow write access to the boot partitions. > > I'm willing to come around to saying that the risk is acceptable, and > that people who overwrite /dev/mmcblk0b0 on their rooted Android phones > won't blame us (at least, not deservedly) for it. > > But I'm still concerned after your Kconfig options are added, because > I'm just not reassured by Kconfig options in principle, because of the > case where *the person who built the kernel* is not the same as the > *user who is running commands*. Imagine that CyanogenMod (or even > Qualcomm!) distributes a kernel with this Kconfig option turned on -- > because they don't realize how dangerous it is, perhaps, or because they > had a use for it during development -- to see where I'm coming from. > > Now, the presence of block devices that brick machines when overwritten > isn't a new phenomenon, so we've got a fair amount of precedence behind > us if we simply expose what we see and expect that users won't do > something unrecoverable. But I'm trying to think about if there's > anything we can do to *minimize* that risk, and have people know what's > going on before they do something they shouldn't. (I think I like Arnd's > suggestion of explicitly having "boot" in the device name rather than > just "b", because that does lend a feeling of "this partition is really > important".)
Yup I think having 'boot' in there (as in mmcblk0boot0) is a good idea. I also think having boot write support as a separate configuration option is also a good idea, so I'll add that in. I think that should help minimize the risk. A -- 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
