linux-kernel - Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses

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]

Message-ID: <20130617112459.GD2718@n2100.arm.linux.org.uk>
Date:	Mon, 17 Jun 2013 12:25:00 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Oliver Schinagl <oliver+list@...inagl.nl>
Cc:	Tomasz Figa <tomasz.figa@...il.com>,
	linux-arm-kernel@...ts.infradead.org, arnd@...db.de,
	gregkh@...uxfoundation.org, Oliver Schinagl <oliver@...inagl.nl>,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	andy.shevchenko@...il.com, maxime.ripard@...e-electrons.com
Subject: Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses

On Mon, Jun 17, 2013 at 12:36:47PM +0200, Oliver Schinagl wrote:
> On 15-06-13 12:28, Tomasz Figa wrote:
>> What is this version thingy?
>>
>> Is there a versioning scheme defined for this driver? Do you expect it to
>> be changed every modification of this driver?
>>
>> I don't see any point of having such thing in a project with a version
>> control system, where you have all change history.
> Well we export something to userspace, while trivial there is the  
> possibility it changes over time. Say A40 which outputs 256 bits instead  
> of the current 128 bits. That would validate a bump in version number.  
> It's purely so the user can be aware of differences in the driver. So  
> maybe DRV_A[BP]I_VERSION would be better?

What is better to do is to export such things as properties, or
design the API in such a way that the length of the ID is reportable.

However, it's actually quite easy to do if you only care about the
number of bytes - you just arrange for the read() function to return
the number of bytes read.  So in the case of 128 bits available, that's
16 bytes, so a read() of the sysfs attribute with a buffer of (say)
256 bytes should report only 16 bytes read.

If it were to become 256 bytes later, then the read() would return
32 bytes read.  So there's no need for any new APIs to do this.

Also, this is over-complicated:

+       for (i = 0; i < size; i++) {
+               if ((pos + i) >= SID_SIZE || (pos < 0))
+                       break;
+               buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);
+       }

Maybe:
	if (pos < 0 || pos >= SID_SIZE)
		return 0;
	if (size > SID_SIZE - pos)
		size = SID_SIZE - pos;

	for (i = 0; i < size; i++)
		buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);

	return size;
--
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/