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

[Alexander Holler <holler@ahsoftware.de>]

Am 08.11.2014 03:03, schrieb Nikolay Dimitrov:
> 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.

Sorry to disappoint you, but I'm currently just a hobbyist. ;)

> 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 :).

Hmm, maybe I should repeat that this driver is about ONE TIME 
PROGRAMMABLE memory. So all your comparisons are (imho) totally wrong.

YOU ONLY HAVE ONE SHOT to set one of these values to whatever value you 
want. And if you get it wrong, the HW might be unusable afterwards. Not 
to speak about all the things which can go wrong and might write to one 
of these files, changing the (hopefully correct) values such that the HW 
is dead afterwards too.

> 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.

I'm not confused, at least not in regard what you want to suggest. Of 
course, I'm totally confused about the fact that almost nobody else 
before has critized that write functionality of this driver, also I'm 
already used to the fact that I'm unable to understand many things which 
are happing in todays world. But nobody is perfect. ;)

But there is absolutely no reason to include this ONE TIME FUNCTIONALITY 
into any kernel meant for the public, especially as it is very 
dangerous. And for sure not without any content veryfication and some 
other means to make sure the value one wants to put ONCE into that ONE 
TIME MEMORY isn't wrong.

That's why I just refuse to change my patch in order to add write 
functionality. I don't want to do (imho) foolish things just because 
someone else tells me to do them. I'm no Lemming.

At least not without adequate compensations. ;)

Regards,

Alexander Holler