linux-ext4 - Re: e2fsprogs: How to get rid of the ext2

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Aug 2018 17:16:50 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: e2fsprogs: How to get rid of the ext2_types.h

On Tue, Aug 21, 2018 at 09:53:53AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Aug 21, 2018 at 02:14:44PM +0200, Lukas Czerner wrote:
> > 
> > The reason why I want to get rid of it is that the API should be
> > platform independent (it is not in this case). And it is causing us to
> > use some hacking in the spec file if we want to building a package for
> > multilib systems.

Hi Ted,

sorry I just noticed your reply after I sent my patch.

> 
> When you say "not platform independent" do you mean that there are
> cases where a particular function parameter is 32-bit versus 64-bit?
> Or that there are cases where the *size* is the same, but it might be
> a "long" versus an "int" across different platforms?
> 
> And is the problem that you want to use the same package for the RPM
> equivalent of "libext2fs-dev" across on a 32-bit and 64-bit multilib
> system?
> 
> And where is it that we are not platform-independent?

The issue is in the header files ext2_types.h and blkid_types.h and
those are going to differ depending on architecture. See:

...
#if (@SIZEOF_INT@ == 2)
typedef        unsigned int    __u16;
#else
#if (@SIZEOF_SHORT@ == 2)
typedef        unsigned short  __u16;
...

but in e2fsprogs we only create one ext2_types.h which can't really be
shared with 32-bit and 64-bit platforms. The fix is rather easy, we just
rename the header file to appropriate name (ext2_types-i386.h for
example) and create a wrapper header that will include the right one for
the right arch.

I'd just like to see if and how can we clean this up because I do feel
that it's not exactly right.

> 
> > First of all let me ask why should we be using those __u.. __s.. types
> > when we could be using types from stdint.h the fact is that we're
> > already including it in the ext2_types.h anyway and no one seems to be
> > complaining.
> 
> Part of it is bcause e2fsprogs predates C99.  The other is that what
> was considered more important was that we were consistent with
> asm/types.h, which is actually what we do on Linux systems:
> 
> % ./config/parse-types.sh 
> checking for __uNN types... using <asm/types.h>
> % cat asm_types.h 
> #define __S8_TYPEDEF __signed__ char
> #define __U8_TYPEDEF unsigned char
> #define __S16_TYPEDEF __signed__ short
> #define __U16_TYPEDEF unsigned short
> #define __S32_TYPEDEF __signed__ int
> #define __U32_TYPEDEF unsigned int
> #define __S64_TYPEDEF __signed__ long long
> 
> These types were taken directly from /usr/include/asm/types.h, because
> we want very much to be consistent with the kernel types:
> 
> if echo '#include <asm/types.h>' | $CPP - 2> parse-types.log | \
> 	sed -f sed.script | grep '^#' > asm_types.h; then
> 	echo "using <asm/types.h>"
> else
> 	echo "using generic types"
> fi
> 
> So this implies that on Fedora / RHEL either asm/types.h doesn't
> exist, or it is not consistent on different platforms?

Not sure how did you come to this conclusion, but no asm/types.h is not
the problem. On linux most of the blkid_types.h should really be
irrelevant since we should be using linux/types.h, but we're not even
consistent in that.

-Lukas

> 
>        	     	    	       	  	    - Ted