From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Sun, 04 Sep 2011 15:56:04 +1000
Subject: [U-Boot] [RFC][PATCH] Generate CRC of structure of Global Data
 for standalone apps
In-Reply-To: <20110903121320.3CC82140ABD4@gemini.denx.de>
References: <1315048903-23217-1-git-send-email-graeme.russ@gmail.com>
	<20110903121320.3CC82140ABD4@gemini.denx.de>
Message-ID: <4E6312F4.6090404@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Wolfgang,

On 03/09/11 22:13, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <1315048903-23217-1-git-send-email-graeme.russ@gmail.com> you wrote:

[snip]

I know that this patch is essentially dead given the fact that standalone
applications should not access gd directly, but a few points for future
reference....

>> The CRC is generated by:
>>  - Pre-processing common.h (which includes global_data.h after all the
>>    board, arch and SoC defines are set)
>>  - Searches for a chunk of text delimited by 'typedef struct global_data {'
>>    and '} gd_t;'
>>  - Strips all blank lines and whitespaces (pre-processor already took care
>>    of comments)
>>  - Pipes the result through 'tools/gencrc32header/gencrc32header'
> 
> Sorry, but I don't consider this an even halfway robust or reliable
> method. Minor changes to the text formatting, changes to remove for
> example the typedef, renames of fields or appending additional fields
> will all break this, while tere will actually be no problems with the
> code.

The CRC could be calculated just on the struct members, but my sed-fu is
not that good. If it was done that way, the only way the CRC would change
is by either:

 1) Members being added
 2) Members being removed
 3) Members being moved around
 4) Members type being changes(*)
 5) Members being renamed

Comments and white spaces have no impact on the CRC as they are stripped.
(*)For CRC calculateion, member types are reduced to their ANSI C
equivalent unless typedef'd, so some member type changes will not trigger a
CRC change

Now apart from #5, we would want a new CRC for any of those modifications,
and how likely is #5 without some other change to gd along the way?

> THis is a level of make-believe security that is fragile, and I doubt
> if it's really useful, or needed.

Not needed as long as only core U-Boot code accessed gd

> It's a nice idea, but the problem it addresses is mostly a theoretical
> one - has anybody seen any actual bug reports that this has ever been
> a real problem?

Don't know - As I said in the commit message, this came about from idle
curiosity about the relationship between gd and XF_VERSION

As an aside, maybe we could expose gd members to standalone applications
via getenv - create psuedo environment variables that are actually tied to
gd members? But then again, I really do not know if standalone applications
*ever* use gd, but getenv may be a nice safe way of exporting gd to
standalone applications

Regards,

Graeme