Gert Doering <g...@greenie.muc.de> writes:

> Hi,
>
> On Sat, Jun 10, 2017 at 06:16:13PM +0200, Jeremie Courreges-Anglas wrote:
>> Loaded symbols for /usr/libexec/ld.so
>> #0  write_tun_header (tt=0x1ddd4e1900, buf=0x1d336921c5 "E", len=84) at 
>> tun.c:1661
>> 1661            if (iph->ip_v == 6)
>> (gdb)
>> 
>> buf points to an odd address.
>
> That's a single-byte access...?  Nothing to be aligned here.
>
> On FreeBSD, ip_v is defined as such:
>
>  * Structure of an internet header, naked of options.
>  */
> struct ip {
> #if BYTE_ORDER == LITTLE_ENDIAN
>         u_char  ip_hl:4,                /* header length */
>                 ip_v:4;                 /* version */
> #endif
> #if BYTE_ORDER == BIG_ENDIAN
>         u_char  ip_v:4,                 /* version */
>                 ip_hl:4;                /* header length */
> #endif
> ...
>
> ... so whatever it is, it's part of a single uchar at the very 
> beginning of that header...  strange.

OpenBSD:

struct ip {
#if _BYTE_ORDER == _LITTLE_ENDIAN
        u_int     ip_hl:4,              /* header length */
                  ip_v:4;               /* version */
#endif
#if _BYTE_ORDER == _BIG_ENDIAN
        u_int     ip_v:4,               /* version */
                  ip_hl:4;              /* header length */
#endif
...

u_char -> u_int.  Dunno if it matters to the compiler, I can take a look
later.

> OTOH, the compiler might assume 16bit-alignment here and use a 16bit-
> access to get the first word, then bit-shift (someone who understands
> sparc64 assembly around to check?) - in this case, the following 
> change should help:
>
>
> old:
>     if (iph->ip_v == 6)
>
> new:
>     if (OPENVPN_IPH_GET_VER(*buf) == 6)
>
> this is an existing macro which takes an int argument, shifting and
> masking the right bits, and since *buf is "uint8_t *buf", this should
> both be correct and alignment-ignorant.  

See my proposed patch, also in this thread.  I merely copy/pasted the
NetBSD code.

> It might be less efficient than accessing the bit field - but then, it's 
> the same work to do, so hopefully the compiler is smart enough to compile 
> it to the same instructions.

master (32 bits access):
0x0000000000081844 <write_tun_header+100>:      ld  [ %i1 ], %g1
0x0000000000081848 <write_tun_header+104>:      sethi  %hi(0xf0000000), %g2
0x000000000008184c <write_tun_header+108>:      sethi  %hi(0x60000000), %g3
0x0000000000081850 <write_tun_header+112>:      and  %g1, %g2, %g1
0x0000000000081854 <write_tun_header+116>:      cmp  %g1, %g3

patched:
0x0000000000081844 <write_tun_header+100>:      ldub  [ %i1 ], %g1
0x0000000000081848 <write_tun_header+104>:      srl  %g1, 4, %g1
0x000000000008184c <write_tun_header+108>:      cmp  %g1, 6

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Attachment: signature.asc
Description: PGP signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to