From patchwork Mon Jun 18 09:40:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Per Ekman X-Patchwork-Id: 165439 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from maxx.maxx.shmoo.com (maxx.shmoo.com [205.134.188.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "maxx.shmoo.com", Issuer "CA Cert Signing Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 8DC6FB70FD for ; Mon, 18 Jun 2012 19:41:12 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 8F82F9D3B2; Mon, 18 Jun 2012 05:41:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFhw3a4MGFoC; Mon, 18 Jun 2012 05:41:08 -0400 (EDT) Received: from maxx.shmoo.com (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 40FA89D289; Mon, 18 Jun 2012 05:41:04 -0400 (EDT) X-Original-To: mailman-post+hostap@maxx.shmoo.com Delivered-To: mailman-post+hostap@maxx.shmoo.com Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id D0C069D289 for ; Mon, 18 Jun 2012 05:41:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5EtrOaGHuIP for ; Mon, 18 Jun 2012 05:40:59 -0400 (EDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by maxx.maxx.shmoo.com (Postfix) with ESMTPS id D14C09D280 for ; Mon, 18 Jun 2012 05:40:58 -0400 (EDT) Received: by lagv3 with SMTP id v3so4555549lag.17 for ; Mon, 18 Jun 2012 02:40:56 -0700 (PDT) Received: by 10.112.9.106 with SMTP id y10mr6132695lba.65.1340012456764; Mon, 18 Jun 2012 02:40:56 -0700 (PDT) Received: from boblet.hd-wireless.se (c-89-160-114-225.cust.bredband2.com. [89.160.114.225]) by mx.google.com with ESMTPS id hz16sm26328970lab.6.2012.06.18.02.40.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 02:40:55 -0700 (PDT) From: Per Ekman To: hostap@lists.shmoo.com Subject: Re: BYTE_ORDER References: <87pq94slcq.fsf@hd-wireless.se> <20120616174233.GA11870@w1.fi> Date: Mon, 18 Jun 2012 11:40:55 +0200 In-Reply-To: <20120616174233.GA11870@w1.fi> (Jouni Malinen's message of "Sat, 16 Jun 2012 20:42:33 +0300") Message-ID: <87d34xufdk.fsf@hd-wireless.se> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 X-BeenThere: hostap@lists.shmoo.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: HostAP Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hostap-bounces@lists.shmoo.com Errors-To: hostap-bounces@lists.shmoo.com Jouni Malinen writes: > On Tue, Jun 12, 2012 at 03:36:37PM +0200, pek@kth.se wrote: >> Whats the story with the *BYTE_ORDER macros? > > Long history and multiple different places where these could be set.. > >> crypto/md4-internal.c checks BYTE_ORDER, is this a bug? >> It is unclear to me if this is ever defined in the general case. > > This is defined by endian.h (from C library).. Is endian.h guaranteed to define BYTE_ORDER (or even exist)? > Could be cleaner to change that to use __BYTE_ORDER to match with the > eap_peer/ikev2.c use or move to WORDS_BIGENDIAN which is used in some > more places. The reason I ask is that when porting to a new environment it's not obvious that endian.h is a requirement (since it is conditionally included in common.h). Just looking at common.h makes it look like you just define __BYTE_ORDER and be on your way but grepping the code makes me think that I should define BYTE_ORDER, _BYTE_ORDER and __BYTE_ORDER, which feels somewhat ad-hoc (and I guess it is). >> driver_atheros.c can define _BYTE_ORDER (but doesn't use it). It doesn't >> feel like this file should diddle around with these macros at all. > > Old hack.. > >> It seems to the uninitiated that __BYTE_ORDER is the macro that all code >> is intended to use since common.h defines it. Is this correct? > > Well, not necessarily.. This is a question of whether to use the > __BYTE_ORDER from system headers (with possible compatibility code from > common.h) or to move something specific to hostap.git (like > WORDS_BIGENDIAN). I'm not aware of places where the current > implementation would not work, but well, it could certainly be cleaned > up. It would clearly work as long as the person doing the porting was sufficiently enlightened :) WORDS_BIGENDIAN sounds much nicer to me. From 8f4fe87ec97a8f4501f29885e09008794f15338f Mon Sep 17 00:00:00 2001 From: Per Ekman Date: Mon, 18 Jun 2012 11:26:38 +0200 Subject: [PATCH] Replace references to _*BYTE_ORDER with WORDS_BIGENDIAN --- src/crypto/md4-internal.c | 6 +++--- src/eap_peer/ikev2.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/crypto/md4-internal.c b/src/crypto/md4-internal.c index cd5e6ca..a3afc29 100644 --- a/src/crypto/md4-internal.c +++ b/src/crypto/md4-internal.c @@ -196,9 +196,7 @@ MD4Transform(u32 state[4], const u8 block[MD4_BLOCK_LENGTH]) { u32 a, b, c, d, in[MD4_BLOCK_LENGTH / 4]; -#if BYTE_ORDER == LITTLE_ENDIAN - os_memcpy(in, block, sizeof(in)); -#else +#ifdef WORDS_BIGENDIAN for (a = 0; a < MD4_BLOCK_LENGTH / 4; a++) { in[a] = (u32)( (u32)(block[a * 4 + 0]) | @@ -206,6 +204,8 @@ MD4Transform(u32 state[4], const u8 block[MD4_BLOCK_LENGTH]) (u32)(block[a * 4 + 2]) << 16 | (u32)(block[a * 4 + 3]) << 24); } +#else + os_memcpy(in, block, sizeof(in)); #endif a = state[0]; diff --git a/src/eap_peer/ikev2.c b/src/eap_peer/ikev2.c index fcf4712..d663d78 100644 --- a/src/eap_peer/ikev2.c +++ b/src/eap_peer/ikev2.c @@ -73,7 +73,7 @@ static int ikev2_derive_keys(struct ikev2_responder_data *data) pos += IKEV2_SPI_LEN; os_memcpy(pos, data->r_spi, IKEV2_SPI_LEN); #ifdef CCNS_PL -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifndef WORDS_BIGENDIAN { int i; u8 *tmp = pos - IKEV2_SPI_LEN; -- 1.7.0.4