From: "Roy Lee" <roylee17@gmail.com>
To: <Valdis.Kletnieks@vt.edu>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] give elf_check_arch() a chance for checking endian mismatch
Date: Sun, 23 Mar 2008 17:41:11 +0800 [thread overview]
Message-ID: <001701c88cca$0b7c3130$22749390$@com> (raw)
In-Reply-To: <25483.1206248760@turing-police.cc.vt.edu>
> -----Original Message-----
> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Sunday, March 23, 2008 1:06 PM
> To: Roy Lee
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] give elf_check_arch() a chance for checking endian
> mismatch
>
> On Thu, 20 Mar 2008 03:03:30 +0800, Roy Lee said:
>
> (Sorry for late reply, catching up finally)
>
> > I'd like to warn for endianess mismatch, or unsupported feature(
> > hardware float point support) when loading an ELF file.
>
> > - if (loc->elf_ex.e_type != ET_EXEC && loc->elf_ex.e_type !=
> ET_DYN)
> > - goto out;
> > if (!elf_check_arch(&loc->elf_ex))
> > goto out;
> > + if (loc->elf_ex.e_type != ET_EXEC && loc->elf_ex.e_type !=
> ET_DYN)
> > + goto out;
>
> It would seem to me that if it isn't an ET_EXEC or ET_DYN, the question of
> whether it passes elf_check_arch() would be rather moot? In any case, you
> don't get to actually *warn* for it, because you end up with a 'goto out'
> in either case, and elf_check_arch is a pretty small macro on most archs.
>
Endianness mismatch is not uncommon for bi-endian processors if their user
didn't
carefully choose their tool-chain or missing flags during compilation.
It makes sense to add some logics for checking and issuing warning when this
happens.
Without changing the order of elf_check_arch(), even if the loaded file is
an
ET_EXEC or ET_DYN, wrong endianness result in misinterpretation of
'elf_ex.e_type', and
end up skipping elf_check_arch() in which we implement endianness checking
as well as
other ABI checking logics.
Changing the order of elf_check_arch() should not break current logics on
most archs.
If the loaded file isn't an ET_EXEC, ET_DYN or even not an ELF at all,
it has great chance to return false in the elf_check_arch() since the loaded
file will not satisfy their checking logic. Even if that's not the case, the
postponed
checking of ET_EXEC and ET_DYN will still redirect the flow to 'goto out'.
> Also, if you change the order there, do you want to also change the order
> in load_elf_interp(), where the equivalent test is done?
>
Yes, I forgot to add them :)
prev parent reply other threads:[~2008-03-23 9:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 19:03 [PATCH] give elf_check_arch() a chance for checking endian mismatch Roy Lee
2008-03-23 5:06 ` Valdis.Kletnieks
2008-03-23 9:41 ` Roy Lee [this message]
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='001701c88cca$0b7c3130$22749390$@com' \
--to=roylee17@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
/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