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: <54C866D5.4070708@gmail.com>
Date:	Wed, 28 Jan 2015 12:34:29 +0800
From:	Fan Du <fengyuleidian0615@...il.com>
To:	David Laight <David.Laight@...LAB.COM>
CC:	'Fan Du' <fan.du@...el.com>,
	"steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm
 netlink msg on 64bits host

于 2015年01月27日 17:46, David Laight 写道:
> From: Fan Du
>> structure like xfrm_usersa_info or xfrm_userpolicy_info
>> has different sizeof when compiled as 32bits and 64bits
>> due to not appending pack attribute in their definition.
>
> Don't 'pack' the structure, just ensure that all the fields
> are fixed sized and on their natural boundary.

Is that simple??

The layout is exactly the same between 32bits and 64bits, only difference
is the last cache line padding, because even if last cache line is not fully
occupied, but at least use even bytes, not odd bytes. I think this relates
to cache HW behaviour, not how the structure is naturally aligned or not.
Actually, the structure members is aligned indeed.

#### 64bits
struct xfrm_usersa_info {
     struct xfrm_selector       sel;                  /*     0    56 */
     struct xfrm_id             id;                   /*    56    24 */

     /* XXX last struct has 3 bytes of padding */

     /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
     xfrm_address_t             saddr;                /*    80    16 */
     struct xfrm_lifetime_cfg   lft;                  /*    96    64 */
     /* --- cacheline 2 boundary (128 bytes) was 32 bytes ago --- */
     struct xfrm_lifetime_cur   curlft;               /*   160    32 */
     /* --- cacheline 3 boundary (192 bytes) --- */
     struct xfrm_stats          stats;                /*   192    12 */
     __u32                      seq;                  /*   204     4 */
     __u32                      reqid;                /*   208     4 */
     __u16                      family;               /*   212     2 */
     __u8                       mode;                 /*   214     1 */
     __u8                       replay_window;        /*   215     1 */
     __u8                       flags;                /*   216     1 */

     /* size: 224, cachelines: 4, members: 12 */
     /* padding: 7 */
     /* paddings: 1, sum paddings: 3 */
     /* last cacheline: 32 bytes */
};


#### 32bits
struct xfrm_usersa_info {
     struct xfrm_selector       sel;                  /*     0    56 */
     struct xfrm_id             id;                   /*    56    24 */

     /* XXX last struct has 3 bytes of padding */

     /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
     xfrm_address_t             saddr;                /*    80    16 */
     struct xfrm_lifetime_cfg   lft;                  /*    96    64 */
     /* --- cacheline 2 boundary (128 bytes) was 32 bytes ago --- */
     struct xfrm_lifetime_cur   curlft;               /*   160    32 */
     /* --- cacheline 3 boundary (192 bytes) --- */
     struct xfrm_stats          stats;                /*   192    12 */
     __u32                      seq;                  /*   204     4 */
     __u32                      reqid;                /*   208     4 */
     __u16                      family;               /*   212     2 */
     __u8                       mode;                 /*   214     1 */
     __u8                       replay_window;        /*   215     1 */
     __u8                       flags;                /*   216     1 */

     /* size: 220, cachelines: 4, members: 12 */
     /* padding: 3 */
     /* paddings: 1, sum paddings: 3 */
     /* last cacheline: 28 bytes */
};

> Possibly add a compile-time check that the structure is
> of the expected size.
>
> 	David
>


-- 
No zuo no die but I have to try.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ