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: Windows password security audit tool. GUI, reports in PDF.

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

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

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.

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?

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

       	     	    	       	  	    - Ted