netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jiri Klimes" <klimes@centrum.cz>
To: <davem@davemloft.net>
Cc: <kaber@trash.net>, <netdev@vger.kernel.org>
Subject: Re: XFRM structures binary compability
Date: Fri, 16 Jan 2009 14:40:02 +0100	[thread overview]
Message-ID: <200901161440.3616@centrum.cz> (raw)
In-Reply-To: <20090114.145552.71463842.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Wed, 14 Jan 2009 14:55:52 -0800 (PST)

>From: Patrick McHardy <kaber@trash.net>
>Date: Mon, 12 Jan 2009 15:41:59 +0100
>
>> klimes@centrum.cz wrote:
>> > What causes my trouble is "xfrm_usersa_info" which is padded with 7 bytes at the end in 64-bit,
>> > so that the whole structure is 224 bytes in 64bit application against 220 bytes in 32bit (just 3-byte padding).
>> > An explicit 7-byte padding in the structure would cure the case, IMHO.
>>
>> That would break on 32 bit because userspace binaries compiled
>> with the old layout would send "short" messages. I'd suggest
>> to explicitly use the smaller value for the xfrm_msg_min checks
>> (i.e. replace sizeof by numerical constant).
>
>I'll commit the following and queue it up for -stable.
>
>Thanks.
>
>xfrm: For 32/64 compatability wrt. xfrm_usersa_info
>

David, I'm afraid the fix is not correct.
xfrm_msg_min is not used just for length check, but mainly to find start of the netlink attributes.
Therefore the patch will work for the case with no attributes. However it won't work properly in case
attributes are used (which is in most cases).
So, I suggest to revert the patch.

Alas, we have no other info about length of xfrm structures except for sizeof() that is unfortunately
different for 32- and 64-bit.

I see no solution to obtain 32/64-bit compatibility without impacting anybody :-(
My first proposal (padding structures explicitly) would bring 32/64 compatibility, but break existing
user applications. Nevertheless I'm afraid that any other solution (e.g. storing the length of the struct
directly in the message) would need to change the structures, causing backward compatibility break.
Either way, making a change (breaking backward compatibility) or letting things as they are (accepting
32/64-bit incompatibility), the status should be documented somewhere (man pages?).

BTW, xfrm_userpolicy_info is the same story as xfrm_usersa_info. xfrm_userpolicy_info is 164 bytes long on 32-bit.
However it has 168 bytes on 64-bit (4 byte pad at the end).

Regards,
Jiri Klimes



  reply	other threads:[~2009-01-16 13:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200901091324.3936@centrum.cz>
     [not found] ` <200901091325.24572@centrum.cz>
     [not found]   ` <200901091326.18260@centrum.cz>
     [not found]     ` <200901091327.25342@centrum.cz>
     [not found]       ` <200901091328.6816@centrum.cz>
     [not found]         ` <200901091329.27638@centrum.cz>
     [not found]           ` <200901091330.17816@centrum.cz>
     [not found]             ` <200901091331.18342@centrum.cz>
2009-01-12 13:54               ` XFRM structures binary compability klimes
2009-01-12 14:41                 ` Patrick McHardy
2009-01-14 22:55                   ` David Miller
2009-01-16 13:40                     ` Jiri Klimes [this message]
2009-01-17 11:27                       ` Herbert Xu
2009-01-27  5:14                         ` David Miller
2009-01-18  7:13                       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200901161440.3616@centrum.cz \
    --to=klimes@centrum.cz \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).