Handle ELFCLASS32 files for x86-64

Handle ELFCLASS32 files for x86-64

In the future we will use an x86-64 toolchain based on the "x32" ABI.
This uses ELFCLASS32 files for x86-64.  Prepare for this by supporting
such files now.  We do this by making the internal representation of
ELF files use ELFCLASS32 format unconditionally.  On reading ELFCLASS64
files, we convert the header formats to the 32-bit representations.

Since we do not yet have x32-based tools for NaCl, the only way to
test an ELFCLASS32 x86-64 file is construct one by hand using the
latest Linux assembler and linker in x32 mode.  I've done this for
a trivial all-assembly "Hello world" program.  We test that ncval
accepts this program and that sel_ldr executes it correctly.

BUG= http://code.google.com/p/nativeclient/issues/detail?id=349
TEST= trybots

R=bsy@google.com,kschimpf@google.com

Committed: http://src.chromium.org/viewvc/native_client?view=rev&revision=6911

[Mark Seaborn, 2011-10-05 22:02:49]

You can set BUG=http://code.google.com/p/nativeclient/issues/detail?id=349

[bsy, 2011-10-11 00:26:52]

one integer overflow bug.  one comment nit.

i'd like to take a little more time to read over it tomorrow, but just wanted to
send what i got so far.

http://codereview.chromium.org/8161004/diff/8001/src/trusted/service_runtime/...
File src/trusted/service_runtime/elf_util.c (right):

http://codereview.chromium.org/8161004/diff/8001/src/trusted/service_runtime/...
src/trusted/service_runtime/elf_util.c:288: if (php->p_vaddr + php->p_memsz >=
((uint64_t) 1U << addr_bits)) {
the sum can overflow since the add is done as uint32 before casting to uint64_t
and thus the check would not work.

http://codereview.chromium.org/8161004/diff/8001/src/trusted/service_runtime/...
src/trusted/service_runtime/elf_util.c:378: sizeof ehdr)
maybe a comment here that reading the size of the union is okay because we do
not expect an entire elf64 program to fit in a space smaller than sizeof ehdr.

[Roland McGrath, 2011-10-11 16:57:03]

Fixed.

[bsy, 2011-10-11 21:21:19]

more issues.  one is an integer overflow.

http://codereview.chromium.org/8161004/diff/18001/src/include/elf.h
File src/include/elf.h (right):

http://codereview.chromium.org/8161004/diff/18001/src/include/elf.h#newcode18
src/include/elf.h:18: * formats internally.  For compatibility with past
practice, we recognize
M-q to refill the paragraph? this line looks too long.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
File src/tools/validator_tools/ncstubout.c (right):

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:13: * instructions that are needed first,
and fix and test them.
if this tool isn't intended to be able to handle arbitrary ELF data, it would be
good to have a comment here.  there appears to be numerous weaknesses.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:92: for (index = 0; index <
header->e_shnum; index++) {
this relies of sizeof(int) > sizeof(Elf32_Half) which is true for all sane
configs.  if ever equal or less, this is an infinite loop.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:99: data + section->sh_offset,
section->sh_size);
section->sh_offset + section->sh_size are both uint32_t and on 32-bit machines
data + section->sh_offset + section->sh_size could overflow undetected in
CheckBounds, yielding a false pass.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:112: int index;
i usually try to avoid "index" as a variable name, since it's also a bsd-ism
function (legacy in posix.1-2001) for strchr.  not that we call index and
shadowing would generate compiler errors etc anyway.  of course, pre-existing
cut-n-paste etc.  sigh.  feel free to ignore.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:119: for (index = 0; index <
header->e_shnum; index++) {
same nit as above.  feel free to ignore.

http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
src/tools/validator_tools/ncstubout.c:126: data + section->sh_offset,
section->sh_size);
section->sh_offset + section->sh_size can wrap on a 32-bit machine as above.

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
File src/trusted/service_runtime/elf_util.c (right):

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:279: if (php->p_vaddr + php->p_memsz <
php->p_vaddr)
add braces plz.  (style)

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:421: image.ehdr.e_phnum =
ehdr.ehdr64.e_phnum;
might be big... (see below)

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:428: image.ehdr = ehdr.ehdr32;
(ditto)

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:444: * by Seek() the cast is safe (cf
bsy)
this comment is no longer valid, now that image.ehdr.e_phoff is an uint32_t and
never uint64_t.  (and it wasn't correct anyway; a bogus seek is okay only
insofar as the bogus values cause us to load some memory image that still get
validated, so the harm done is minimal -- arguably e_phoff bigger than max off_t
is an error that should be reported.)

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:475: if ((size_t) (*gp->vtbl->Read)(gp,
perhaps a comment here for
precondition: image.ehdr.e_phnum < SIZE_T_MAX / sizeof phdr64[0]
this is implied by image.ehdr.e_phum > NACL_MAX_PROGRAM_HEADES early exit above.

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:477: image.ehdr.e_phnum * sizeof
phdr64[0])
this should read one phdr64 at a time seeking to image.ehdr.e_phoff + cur_ph *
ehdr.ehdr64.e_phentsize and then reading sizeof phdr64[0], since the intent of
having e_phentsize is that new elf versions can grow the phdr entries and
loaders should handle it just fine, ignoring the extended data fields.

http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:523: if ((size_t) (*gp->vtbl->Read)(gp,
ditto wrt looping over seek/read for the case where image.ehdr.e_phentsize >
sizeof image.phdr[0].

[Roland McGrath, 2011-10-11 23:26:16]

On 2011/10/11 21:21:19, bsy wrote:
> http://codereview.chromium.org/8161004/diff/18001/src/include/elf.h#newcode18
> src/include/elf.h:18: * formats internally.  For compatibility with past
> practice, we recognize
> M-q to refill the paragraph? this line looks too long.

You can always be sure that none of my lines are over 80 characters.
M-q with fill-column at 70 changes one word in this paragraph, but
does not change that line.

> if this tool isn't intended to be able to handle arbitrary ELF data, it
> would be good to have a comment here.  there appears to be numerous
> weaknesses.

This has nothing to do with my changes.  If this file needs other cleanups,
that would be a separate change, and Karl should be consulted on the details.

>
http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
> src/tools/validator_tools/ncstubout.c:92: for (index = 0; index <
> header->e_shnum; index++) {
> this relies of sizeof(int) > sizeof(Elf32_Half) which is true for all sane
> configs.  if ever equal or less, this is an infinite loop.

There could never be a functioning configuration where int is 16 bits.
Anyway, this is not code I changed.

>
http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
> src/tools/validator_tools/ncstubout.c:99: data + section->sh_offset,
> section->sh_size);
> section->sh_offset + section->sh_size are both uint32_t and on 32-bit machines
> data + section->sh_offset + section->sh_size could overflow undetected in
> CheckBounds, yielding a false pass.

Not code I changed.

>
http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
> src/tools/validator_tools/ncstubout.c:112: int index;
> i usually try to avoid "index" as a variable name, since it's also a bsd-ism
> function (legacy in posix.1-2001) for strchr.  not that we call index and
> shadowing would generate compiler errors etc anyway.  of course, pre-existing
> cut-n-paste etc.  sigh.  feel free to ignore.

Ignored. ;-)

>
http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/n...
> src/tools/validator_tools/ncstubout.c:126: data + section->sh_offset,
> section->sh_size);
> section->sh_offset + section->sh_size can wrap on a 32-bit machine as above.

In this version of the code, sh_offset and sh_size are 64 bits.
At any rate, it's a preexisting situation in the old code.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:279: if (php->p_vaddr + php->p_memsz <
> php->p_vaddr)
> add braces plz.  (style)

Prevailing Google/Chromium/NaCl style omits braces for one-line cases.
But I changed it anyway.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:421: image.ehdr.e_phnum =
> ehdr.ehdr64.e_phnum;
> might be big... (see below)

This field has the same type (Elf32_Half == Elf64_Half == uint16_t) in both
structures.  I don't follow what you might be objecting to here.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:428: image.ehdr = ehdr.ehdr32;
> (ditto)

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:444: * by Seek() the cast is safe (cf
> bsy)
> this comment is no longer valid, now that image.ehdr.e_phoff is an uint32_t
and
> never uint64_t.  (and it wasn't correct anyway; a bogus seek is okay only
> insofar as the bogus values cause us to load some memory image that still get
> validated, so the harm done is minimal -- arguably e_phoff bigger than max
off_t
> is an error that should be reported.)

Removed the comment.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:475: if ((size_t) (*gp->vtbl->Read)(gp,
> perhaps a comment here for
> precondition: image.ehdr.e_phnum < SIZE_T_MAX / sizeof phdr64[0]
> this is implied by image.ehdr.e_phum > NACL_MAX_PROGRAM_HEADES early exit
above.

Added a comment.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:477: image.ehdr.e_phnum * sizeof
> phdr64[0])
> this should read one phdr64 at a time seeking to image.ehdr.e_phoff + cur_ph *
> ehdr.ehdr64.e_phentsize and then reading sizeof phdr64[0], since the intent of
> having e_phentsize is that new elf versions can grow the phdr entries and
> loaders should handle it just fine, ignoring the extended data fields.

It never worked this way here before, so such a change is unrelated to my
work here.  In reality, all extant ELF loaders just check e_phentsize for
the expected value and reject mismatches outright.  If that size ever did
change, it probably wouldn't be done this way.

>
http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:523: if ((size_t) (*gp->vtbl->Read)(gp,
> ditto wrt looping over seek/read for the case where image.ehdr.e_phentsize >
> sizeof image.phdr[0].

Ditto wrt being unrelated to what I'm changing here.
Different changes in different commits.

[bsy, 2011-10-11 23:59:38]

plz in the future reply via reply button on code review tool, since that
makes it easier to track which has been acted on etc.

On Tue, Oct 11, 2011 at 4:26 PM, <mcgrathr@chromium.org> wrote:

> On 2011/10/11 21:21:19, bsy wrote:
>
>> http://codereview.chromium.**org/8161004/diff/18001/src/**
>>
include/elf.h#newcode18<http://codereview.chromium.org/8161004/diff/18001/src/include/elf.h#newcode18>
>> src/include/elf.h:18: * formats internally.  For compatibility with past
>> practice, we recognize
>> M-q to refill the paragraph? this line looks too long.
>>
>
> You can always be sure that none of my lines are over 80 characters.
> M-q with fill-column at 70 changes one word in this paragraph, but
> does not change that line.
>
>
>  if this tool isn't intended to be able to handle arbitrary ELF data, it
>> would be good to have a comment here.  there appears to be numerous
>> weaknesses.
>>
>
> This has nothing to do with my changes.  If this file needs other cleanups,
> that would be a separate change, and Karl should be consulted on the
> details.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
tools/validator_tools/**ncstubout.c#newcode92<http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/ncstubout.c#newcode92>
>
>> src/tools/validator_tools/**ncstubout.c:92: for (index = 0; index <
>> header->e_shnum; index++) {
>> this relies of sizeof(int) > sizeof(Elf32_Half) which is true for all sane
>> configs.  if ever equal or less, this is an infinite loop.
>>
>
> There could never be a functioning configuration where int is 16 bits.
> Anyway, this is not code I changed.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
tools/validator_tools/**ncstubout.c#newcode99<http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/ncstubout.c#newcode99>
>
>> src/tools/validator_tools/**ncstubout.c:99: data + section->sh_offset,
>> section->sh_size);
>> section->sh_offset + section->sh_size are both uint32_t and on 32-bit
>> machines
>> data + section->sh_offset + section->sh_size could overflow undetected in
>> CheckBounds, yielding a false pass.
>>
>
> Not code I changed.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
tools/validator_tools/**ncstubout.c#newcode112<http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/ncstubout.c#newcode112>
>
>> src/tools/validator_tools/**ncstubout.c:112: int index;
>> i usually try to avoid "index" as a variable name, since it's also a
>> bsd-ism
>> function (legacy in posix.1-2001) for strchr.  not that we call index and
>> shadowing would generate compiler errors etc anyway.  of course,
>> pre-existing
>> cut-n-paste etc.  sigh.  feel free to ignore.
>>
>
> Ignored. ;-)
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
tools/validator_tools/**ncstubout.c#newcode126<http://codereview.chromium.org/8161004/diff/18001/src/tools/validator_tools/ncstubout.c#newcode126>
>
>> src/tools/validator_tools/**ncstubout.c:126: data + section->sh_offset,
>> section->sh_size);
>> section->sh_offset + section->sh_size can wrap on a 32-bit machine as
>> above.
>>
>
> In this version of the code, sh_offset and sh_size are 64 bits.
> At any rate, it's a preexisting situation in the old code.
>
>
>
my apologies.  misread sizes.


>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode279<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode279>
>
>> src/trusted/service_runtime/**elf_util.c:279: if (php->p_vaddr +
>> php->p_memsz <
>> php->p_vaddr)
>> add braces plz.  (style)
>>
>
> Prevailing Google/Chromium/NaCl style omits braces for one-line cases.
> But I changed it anyway.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode421<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode421>
>
>> src/trusted/service_runtime/**elf_util.c:421: image.ehdr.e_phnum =
>> ehdr.ehdr64.e_phnum;
>> might be big... (see below)
>>
>
> This field has the same type (Elf32_Half == Elf64_Half == uint16_t) in both
> structures.  I don't follow what you might be objecting to here.
>
>
>
sorry -- left over comment. was looking at e_phnum * sizeof phdr64[0] and
worried about overflow.  deleted comment there when i saw the check, but
forgot these two.


>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode428<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode428>
>
>> src/trusted/service_runtime/**elf_util.c:428: image.ehdr = ehdr.ehdr32;
>> (ditto)
>>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode444<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode444>
>
>> src/trusted/service_runtime/**elf_util.c:444: * by Seek() the cast is
>> safe (cf
>> bsy)
>> this comment is no longer valid, now that image.ehdr.e_phoff is an
>> uint32_t
>>
> and
>
>> never uint64_t.  (and it wasn't correct anyway; a bogus seek is okay only
>> insofar as the bogus values cause us to load some memory image that still
>> get
>> validated, so the harm done is minimal -- arguably e_phoff bigger than max
>>
> off_t
>
>> is an error that should be reported.)
>>
>
> Removed the comment.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode475<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode475>
>
>> src/trusted/service_runtime/**elf_util.c:475: if ((size_t)
>> (*gp->vtbl->Read)(gp,
>> perhaps a comment here for
>> precondition: image.ehdr.e_phnum < SIZE_T_MAX / sizeof phdr64[0]
>> this is implied by image.ehdr.e_phum > NACL_MAX_PROGRAM_HEADES early exit
>>
> above.
>
> Added a comment.
>
>
>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode477<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode477>
>
>> src/trusted/service_runtime/**elf_util.c:477: image.ehdr.e_phnum * sizeof
>> phdr64[0])
>> this should read one phdr64 at a time seeking to image.ehdr.e_phoff +
>> cur_ph *
>> ehdr.ehdr64.e_phentsize and then reading sizeof phdr64[0], since the
>> intent of
>> having e_phentsize is that new elf versions can grow the phdr entries and
>> loaders should handle it just fine, ignoring the extended data fields.
>>
>
> It never worked this way here before, so such a change is unrelated to my
> work here.  In reality, all extant ELF loaders just check e_phentsize for
> the expected value and reject mismatches outright.  If that size ever did
> change, it probably wouldn't be done this way.
>
>
>
then please change "<" on L511 to "!=" test, and update error message.

this code used to work that way once-upon-a-time.  not sure what happened.


>
> http://codereview.chromium.**org/8161004/diff/18001/src/**
>
trusted/service_runtime/elf_**util.c#newcode523<http://codereview.chromium.org/8161004/diff/18001/src/trusted/service_runtime/elf_util.c#newcode523>
>
>> src/trusted/service_runtime/**elf_util.c:523: if ((size_t)
>> (*gp->vtbl->Read)(gp,
>> ditto wrt looping over seek/read for the case where image.ehdr.e_phentsize
>> >
>> sizeof image.phdr[0].
>>
>
> Ditto wrt being unrelated to what I'm changing here.
> Different changes in different commits.
>
>
>
http://codereview.chromium.**org/8161004/<http://codereview.chromium.org/8161...
>



-- 
bennet s yee
i usually don't capitalize due to mild tendonitis

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[bsy, 2011-10-12 00:01:50]

http://codereview.chromium.org/8161004/diff/24001/src/trusted/service_runtime...
File src/trusted/service_runtime/elf_util.c (right):

http://codereview.chromium.org/8161004/diff/24001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:459: if (ehdr.ehdr64.e_phentsize <
sizeof(Elf64_Phdr)) {
s/</!=/

http://codereview.chromium.org/8161004/diff/24001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:511: if (image.ehdr.e_phentsize < sizeof
image.phdrs[0]) {
s/</!=/ if we don't loop over seek/read

[Roland McGrath, 2011-10-12 20:03:00]

On 2011/10/11 23:59:38, bsy wrote:
> plz in the future reply via reply button on code review tool, since that
> makes it easier to track which has been acted on etc.

That's what I did.

> then please change "<" on L511 to "!=" test, and update error message.
> 
> this code used to work that way once-upon-a-time.  not sure what happened.

Changed the tests.  There is no error message here that needs updating.
Did you mean the string associated with LOAD_PROG_HDR_SIZE_TOO_SMALL?

[bsy, 2011-10-12 20:12:37]

http://codereview.chromium.org/8161004/diff/24001/src/trusted/service_runtime...
File src/trusted/service_runtime/elf_util.c (right):

http://codereview.chromium.org/8161004/diff/24001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:459: if (ehdr.ehdr64.e_phentsize <
sizeof(Elf64_Phdr)) {
On 2011/10/12 00:01:50, bsy wrote:
> s/</!=/

i meant clicking on the comment text and then clicking on the "Reply" or "Done"
JavaScript "link".

http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
File src/trusted/service_runtime/elf_util.c (right):

http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:413: if (ehdr.ehdr64.e_ehsize <
sizeof(ehdr.ehdr64)) {
please change this < to !=

http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:461: *err_code =
LOAD_PROG_HDR_SIZE_TOO_SMALL;
this is no longer "TOO_SMALL" but "WRONG_SIZE"

http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
src/trusted/service_runtime/elf_util.c:513: *err_code =
LOAD_PROG_HDR_SIZE_TOO_SMALL;
ditto

[Roland McGrath, 2011-10-12 20:25:48]

On 2011/10/12 20:12:37, bsy wrote:
> i meant clicking on the comment text and then clicking on the "Reply" or
"Done"
> JavaScript "link".

That's what I did.

>
http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
> File src/trusted/service_runtime/elf_util.c (right):
> 
>
http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:413: if (ehdr.ehdr64.e_ehsize <
> sizeof(ehdr.ehdr64)) {
> please change this < to !=

Done.

>
http://codereview.chromium.org/8161004/diff/26001/src/trusted/service_runtime...
> src/trusted/service_runtime/elf_util.c:461: *err_code =
> LOAD_PROG_HDR_SIZE_TOO_SMALL;
> this is no longer "TOO_SMALL" but "WRONG_SIZE"

I made it LOAD_BAD_PHENTSIZE to follow LOAD_BAD_EHSIZE.

[bsy, 2011-10-12 20:37:09]

lgtm.  thx 4 putting up w/ my nits.