linux-kernel - Re: [PATCH 3/4] UAPI: Fix endianness conditionals in linux/raid/md

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]

Message-ID: <20130312124331.221fcc15@notabene.brown>
Date:	Tue, 12 Mar 2013 12:43:31 +1100
From:	NeilBrown <neilb@...e.de>
To:	David Howells <dhowells@...hat.com>
Cc:	torvalds@...ux-foundation.org, linux-arch@...r.kernel.org,
	sfr@...b.auug.org.au, Joakim.Tjernlund@...nsmode.se, arnd@...db.de,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 3/4] UAPI: Fix endianness conditionals in
 linux/raid/md_p.h

On Wed, 06 Mar 2013 20:47:51 +0000 David Howells <dhowells@...hat.com> wrote:

> In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be compared
> against __BYTE_ORDER in preprocessor conditionals where these are exposed to
> userspace (that is they're not inside __KERNEL__ conditionals).
> 
> However, in the main kernel the norm is to check for "defined(__XXX_ENDIAN)"
> rather than comparing against __BYTE_ORDER and this has incorrectly leaked
> into the userspace headers.
> 
> The definition of struct mdp_superblock_s in linux/raid/md_p.h is wrong in this
> way.  Note that userspace will likely interpret the ordering of the fields
> incorrectly as the big-endian variant on a little-endian machines - depending
> on header inclusion order.
> 
> [!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
> be better to fix the ordering of events_hi, events_lo, cp_events_hi and
> cp_events_lo in struct mdp_superblock_s / typedef mdp_super_t.

Thanks David - looks good to me.
Changing the ordering of fields isn't really an option at this stage - over
10 years too late :-(.
I think any user-space tools that use this data structure have their own copy
of the include file.

Acked-by: NeilBrown <neilb@...e.de>

Thanks,
NeilBrown


> 
> Signed-off-by: David Howells <dhowells@...hat.com>
> cc: Neil Brown <neilb@...e.de>
> cc: linux-raid@...r.kernel.org
> ---
> 
>  include/uapi/linux/raid/md_p.h |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h
> index ee75353..fe1a540 100644
> --- a/include/uapi/linux/raid/md_p.h
> +++ b/include/uapi/linux/raid/md_p.h
> @@ -145,16 +145,18 @@ typedef struct mdp_superblock_s {
>  	__u32 failed_disks;	/*  4 Number of failed disks		      */
>  	__u32 spare_disks;	/*  5 Number of spare disks		      */
>  	__u32 sb_csum;		/*  6 checksum of the whole superblock        */
> -#ifdef __BIG_ENDIAN
> +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
>  	__u32 events_hi;	/*  7 high-order of superblock update count   */
>  	__u32 events_lo;	/*  8 low-order of superblock update count    */
>  	__u32 cp_events_hi;	/*  9 high-order of checkpoint update count   */
>  	__u32 cp_events_lo;	/* 10 low-order of checkpoint update count    */
> -#else
> +#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
>  	__u32 events_lo;	/*  7 low-order of superblock update count    */
>  	__u32 events_hi;	/*  8 high-order of superblock update count   */
>  	__u32 cp_events_lo;	/*  9 low-order of checkpoint update count    */
>  	__u32 cp_events_hi;	/* 10 high-order of checkpoint update count   */
> +#else
> +#error unspecified endianness
>  #endif
>  	__u32 recovery_cp;	/* 11 recovery checkpoint sector count	      */
>  	/* There are only valid for minor_version > 90 */


Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)