[meta-freescale] [PATCH 0/1] arm: imx: fsl_otp: make fuses (OTP memory) read-only

[Jon Nettleton]

On Sat, Nov 8, 2014 at 9:58 AM, Chris Tapp <opensource at keylevel.com> wrote:
>
> On 8 Nov 2014, at 02:03, Nikolay Dimitrov <picmaster at mail.bg> wrote:
>
>> Hi Alexander,
>>
>> The driver allows to be enabled/disabled by a configuration option, so
>> it's a responsibility of your engineering team to properly configure
>> the software for development, manufacturing and production purposes, as
>> there's no "one size fits all" solution for this option.
>>
>> And I think it would be a unwise decision just to cripple the driver
>> because there is potential for misuse the driver. If so, we have to
>> disable also all device files and sysfs entries that allow raw access
>> to physical memory, physical disks, cpu frequency, thermal device,
>> power supply voltages, as all of these can screw-up the product (either
>> by deleting data or by frying a component on the board). And we have to
>> forbid kitchen knives :).
>>
>> I like Eric's idea with sysfs unlock entry. It's also possible to have
>> different sysfs "read" and "write" files' permissions, to provide
>> privilege separation.
>>
>> I also understand your confusion of the answers received on LKML and
>> here, but you should already know that each FOSS tribe has its own
>> customs. What's good for the kernel itself doesn't make it instantly
>> good for actual systems/product integration, so it's normal to have
>> groups with different goals to react differently on the same topic.
>
> As has already been mentioned, it is the responsibility of a project to ensure that any product is suitably protected.
>
> I can image a customer would be really unhappy if their system (e.g. Smart TV) could be destroyed by a bit of malware !
>

Yes but many of the boards aren't necessarily being used for locked
down consumer products.  Many people are using these devices as
learning devices and are trusting the code provided by the
manufacturer.  I think it makes sense for public software to try and
provide the most sane configuration.  It is trivial to make this a
kernel config option that is disabled by default, add a write_enabled
sysfs node, and even have it spit out a warning when you enable the
write_enabled sysfs node.  If we do all those things and somebody
bricks their board then I would not have a bad conscience.

Anybody that has the skill or reason to use the fuses properly will
have no problem following steps to enable this functionality.