linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Figa <t.figa@samsung.com>
To: Oliver Schinagl <oliver+list@schinagl.nl>
Cc: linux-arm-kernel@lists.infradead.org,
	Tomasz Figa <tomasz.figa@gmail.com>,
	linux@arm.linux.org.uk, arnd@arndb.de,
	Oliver Schinagl <oliver@schinagl.nl>,
	gregkh@linuxfoundation.org, linus.walleij@linaro.org,
	linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
	maxime.ripard@free-electrons.com, linux-sunxi@googlegroups.com
Subject: Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
Date: Mon, 17 Jun 2013 15:23:45 +0200	[thread overview]
Message-ID: <2650626.N0ZZQX0iR6@amdc1227> (raw)
In-Reply-To: <51BF0AD7.1070101@schinagl.nl>

On Monday 17 of June 2013 15:10:47 Oliver Schinagl wrote:
> On 17-06-13 14:51, Tomasz Figa wrote:
> > On Monday 17 of June 2013 12:36:47 Oliver Schinagl wrote:
> >> On 15-06-13 12:28, Tomasz Figa wrote:
> >>> Hi,
> >>> 
> >>> Some comments inline.
> >> 
> >> Thank you
> > 
> > You're welcome. :)
> > 
> >>> On Saturday 15 of June 2013 01:16:20 Oliver Schinagl wrote:
> >>>> From: Oliver Schinagl <oliver@schinagl.nl>
> >>>> 
> >>>> Allwinner has electric fuses (efuse) on their line of chips. This
> >>>> driver
> >>>> reads those fuses, seeds the kernel entropy and exports them as a sysfs
> >>>> node.
> 
> <snip>
> 
> >> I will change the comment, 'and 4 byte sized keys per SID' is probably
> >> better
> >> The array is 128 bits split into 32 bit words. Each 32 bit word consists
> >> of 8 bits (1 byte).
> >> So 4 * 4 = 16 bytes (SID_SIZE), is 128 bits.
> > 
> > What about:
> > 	/* There are 4 keys. */
> > 	#define SID_KEYS 4
> > 	/* Each key is 4 byte long (32-bit). */
> > 	#define SID_SIZE (SID_KEYS * 4)
> 
> I'll ommit the 'long (32-bit)' part but yeah that's probably enough.
> 
> <snip>
> 
> >>>> +
> >>>> +	if (offset >= SID_SIZE)
> >>>> +		goto exit;
> >>>> 
> >>> 		return 0; ...
> >> 
> >> I did say in the changelog I opted for goto over return. But since
> >> everybody keeps preferring returns (I personally like 'one single exit
> >> point much more' I have already changed it all over to many returns, who
> >> am I to argue :)
> > 
> > Well, single exit points makes sense (and is much nicer) when you have
> > something to do before exiting, take error paths as an example. But
> > jumping
> > just to return makes no sense, because when reading the code you must
> > scroll down to the label to check what actually happens.
> 
> But functions shouldn't be so large :p But that is the first reasonable
> reason I can live with :)
> 
> <snip>
> 
> >>>> +
> >>>> +	for (i = 0; i < SID_SIZE; i++)
> >>>> +		entropy[i] = sunxi_sid_read_byte(sid_reg_base, i);
> >>> 
> >>> You seem to read bytes into an array of ints. Your entropy data will
> >>> always have most significant 24-bits cleared. Is this behavior correct?
> >> 
> >> Yes, though I changed it so that entropy is an array of u8's, since
> >> that's what sunxi_sid_read_byte returns.
> >> 
> >>>> +	add_device_randomness(entropy, SID_SIZE);
> >>> 
> >>> Now I'm pretty sure that above is not the correct behavior. You are
> >>> adding
> >>> here first 16 bytes (=SID_SIZE) of entropy[], while it is an array of 16
> >>> ints (=4*SID_SIZE)...
> >> 
> >> Well technically, doesn't to compiler see that entropy is never larger
> >> then 8 bits and thus uses only 8 bits? uint8_atleast or something. But
> >> yeah, it's better to use the specified size to not waste 24 empty bits.
> > 
> > I mean, the loop fills the array with SID_SIZE ints, each with 3 zero
> > bytes and 1 byte of actual data, so you get:
> > 
> > S0 0x00 0x00 0x00 S1 0x00 0x00 0x00 ... S15 0x00 0x00 0x00
> 
> Ok, I get that
> 
> > but by calling add_device_randomness() with SID_SIZE as size argument, you
> > add only 16 first bytes of data from the array:
> > 
> > S0 0x00 0x00 0x00 S1 0x00 0x00 0x00 ... S3 0x00 0x00 0x00
> 
> That bit I'm not quite sure I understand:
> 
> We have an array of ints, { 0x00000000, 0x00000000, 0x00000000 .... }
> We read 1 byte and copy it to the array (x16) (say sid = 0xdeadbeef...)
> { 0x000000de, 0x000000ad, 0x000000be, ... }
> 
> Now we pass this array to add_randomness(array, 16). So add_randomness
> sees 16 ints in an array. So while there will be a lot of extra zero's,
> there still be 16 elements copied/processed, no?

The second argument of add_randomness is number of bytes, not number of 
elements in array, as far as I can tell.

Best regards,
Tomasz

> Otherwise, how does add_randomness() know it's dealing with bytes or
> ints? it just see's the pointer to an int array that is 16 long? Or what
> am I overlooking?
> 
> I did already change the array to be u8 big so it is only to help me
> understand.
> 
> > (little endianness assumed)
> > 
> > Best regards,
> > Tomasz
> > 
> > (for rest of comments I think it's enough said in Russell's and Maxime's
> > replies)
> 
> Yes it has :) thanks to all of you
> 
> Oliver

  reply	other threads:[~2013-06-17 13:23 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-14 23:16 [PATCH 0/2] v3 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-14 23:16 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-15  2:14   ` Andy Shevchenko
2013-06-15  9:34     ` Oliver Schinagl
2013-06-15 10:28   ` Tomasz Figa
2013-06-17 10:36     ` Oliver Schinagl
2013-06-17 11:25       ` Russell King - ARM Linux
2013-06-17 11:32         ` Oliver Schinagl
2013-06-17 11:51       ` Maxime Ripard
2013-06-17 12:04         ` Oliver Schinagl
2013-06-17 12:51       ` Tomasz Figa
2013-06-17 13:10         ` Oliver Schinagl
2013-06-17 13:23           ` Tomasz Figa [this message]
2013-06-17 13:47             ` Oliver Schinagl
2013-06-14 23:16 ` [PATCH 2/2] Add sunxi-sid to dts for sun4i and sun5i Oliver Schinagl
  -- strict thread matches above, loose matches on Subject: below --
2013-08-27 14:13 [PATCHv5 0/2] Driver for Allwinner sunxi Security ID oliver+list
2013-08-27 14:13 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses oliver+list
2013-08-27 15:42   ` Maxime Ripard
2013-06-17 20:59 [PATCH 0/2] v4 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-17 20:59 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-17 21:06   ` Tomasz Figa
2013-06-17 22:58   ` Greg KH
2013-06-24  9:29     ` Maxime Ripard
2013-06-24 16:04       ` Greg KH
2013-06-24 17:11         ` Oliver Schinagl
2013-06-24 18:15           ` Greg KH
2013-06-24 21:21             ` Oliver Schinagl
2013-06-24 21:46               ` Greg KH
2013-06-26  8:32                 ` Oliver Schinagl
2013-06-26 17:51                   ` Greg KH
2013-07-05  7:24                     ` Oliver Schinagl
2013-07-06 19:36                       ` Greg KH
2013-07-07  0:17                         ` Greg KH
2013-06-26  9:10                 ` Russell King - ARM Linux
2013-06-26 17:51                   ` Greg KH
2013-06-24 21:04         ` Maxime Ripard
2013-06-26  9:22         ` Geert Uytterhoeven
2013-06-26 17:49           ` Greg KH
2013-06-18  5:41   ` Andy Shevchenko
2013-06-02 14:58 [PATCH 0/2] v2 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-02 14:58 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-02 15:09   ` Russell King - ARM Linux
2013-06-02 15:21     ` Oliver Schinagl
2013-06-06 19:16   ` Andy Shevchenko
2013-06-10 21:43     ` Oliver Schinagl
2013-06-11 10:51       ` Andy Shevchenko
2013-05-17 13:35 [PATCH 0/2] Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-05-17 13:35 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-05-17 13:45   ` Arnd Bergmann
2013-05-17 18:54     ` Oliver Schinagl
2013-05-17 21:18   ` Maxime Ripard
2013-05-18 17:19     ` Oliver Schinagl
2013-05-19 15:22       ` Maxime Ripard
2013-05-24 21:50       ` Oliver Schinagl
2013-05-25 12:22         ` Maxime Ripard
2013-05-25 19:25           ` Oliver Schinagl
2013-05-26  9:35             ` Maxime Ripard
2013-05-23  7:56   ` Linus Walleij
2013-05-23  8:10     ` Oliver Schinagl
2013-05-23  8:20       ` Linus Walleij
2013-05-23 14:58       ` Maxime Ripard
2013-05-23 15:05         ` Oliver Schinagl
2013-05-23 15:27           ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2650626.N0ZZQX0iR6@amdc1227 \
    --to=t.figa@samsung.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=linux@arm.linux.org.uk \
    --cc=maxime.ripard@free-electrons.com \
    --cc=oliver+list@schinagl.nl \
    --cc=oliver@schinagl.nl \
    --cc=tomasz.figa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).