linux-kernel - Re: [PATCH 1/1] Blackfin OTP Char Driver: add writing support of OTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Oct 2008 06:44:16 -0400
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Jiri Slaby" <jirislaby@...il.com>
Cc:	"Bryan Wu" <cooloney@...nel.org>, sam@...nborg.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Blackfin OTP Char Driver: add writing support of OTP

On Mon, Oct 13, 2008 at 06:35, Jiri Slaby wrote:
> On 10/13/2008 12:07 PM, Mike Frysinger wrote:
>>> But is this OK to you:
>>> PROCESS 1                       PROCESS 2
>>> lock
>>>  set allow_writes
>>> write
>>>   check allow_writes
>>>   be interrupted
>>>                                whatever
>>>                                unlock
>>>                                    unset allow_writes
>>>                                sleep
>>>   mutex lock
>>>   the processing...
>>
>> i dont see a problem here.  there is no loss of data, hardware
>> failure, software crashes, etc...  in other words, there is no
>> misbehavior.
>
> I see no purpose of allow_writes then. Why is it there? I don't need to call
> memlock if anybody else did and I raced with him. Also when somebody else
> unlocks after finishing of writes I can start failing in the middle of my writes
> -- this doesn't have anything to do with locking, but with the design, the one
> global variable.

the write bit is per-device, not per-process. so the fact you've
narrowed down a race condition to two instructions doesnt matter, the
behavior is the same.  one process can unlock the hardware while
another process (which did not unlock) now has access.  or vice versa.
 the lock is to prevent in inadvertent writes.  considering such
inadvertent writes could make the processor unbootable, it's a simple
safety measure which is quite common when dealing with storage
technology like this (just look at some of the other drivers in the
char subdir).  an application that wants to write must first enable
write access, do the write, and then disable write access.  the
scenario you describe isnt a realistic use case, so no point in
accounting for it.  OTP writes are very rare outside of development if
they occur at all (which is why there's a Kconfig option to just
disable it completely).
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/