linux-kernel - RE: [PATCH] give elf_check_arch() a chance for checking endian mismatch

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] [day] [month] [year] [list]

Date:	Sun, 23 Mar 2008 17:41:11 +0800
From:	"Roy Lee" <roylee17@...il.com>
To:	<Valdis.Kletnieks@...edu>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] give elf_check_arch() a chance for checking endian mismatch

> -----Original Message-----
> From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu]
> Sent: Sunday, March 23, 2008 1:06 PM
> To: Roy Lee
> Cc: linux-kernel@...r.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 :)

--
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/