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