From: Rich Felker <dalias@libc.org>
To: "J. Hanne" <musl@jf.hanne.name>
Cc: musl@lists.openwall.com
Subject: Re: [musl] CMSG_LEN macro
Date: Sun, 3 Oct 2021 09:35:47 -0400 [thread overview]
Message-ID: <20211003133546.GB2559@brightrain.aerifal.cx> (raw)
In-Reply-To: <20211003081459.34C1C2FC23EF@dd11108.kasserver.com>
On Sun, Oct 03, 2021 at 10:14:59AM +0200, J. Hanne wrote:
> Hi,
>
> thanks for your thoughts. The NLMSG macros also already gave me
> similar headache some time ago. I personally find both APIs
> counter-intuitive because they use the term "ALIGN", when they mean
> "PAD", so that the *following* item is aligned.
>
> I would suggest the following patch now:
>
> Do not use CMSG_ALIGN on struct cmsghdr, because:
> - This has no effect on any architecture anyway, because sizeof(struct cmsghdr) == 16 on all archs
> - Using it contradicts with CMSG_DATA, which does NOT apply any padding after struct cmsghdr
> - This is consistent with the NLMSG_* macros
> ---
> diff -uNr a/include/sys/socket.h b/include/sys/socket.h
> --- a/include/sys/socket.h 2021-01-15 03:26:00.000000000 +0100
> +++ b/include/sys/socket.h 2021-10-03 09:49:35.000000000 +0200
> @@ -358,8 +358,8 @@
> #define CMSG_FIRSTHDR(mhdr) ((size_t) (mhdr)->msg_controllen >= sizeof (struct cmsghdr) ? (struct cmsghdr *) (mhdr)->msg_control : (struct cmsghdr *) 0)
>
> #define CMSG_ALIGN(len) (((len) + sizeof (size_t) - 1) & (size_t) ~(sizeof (size_t) - 1))
Aside: this should be cleaned up too. It has a truely no-op cast (the
type is the same as the type of the expression) and gratuitously uses
~(x-1) instead of -x. But this could be a separate change.
(Note: implicit in my claim here is an assumption that size_t has rank
not less than that of int, but this is assumed everywhere and is a
condition on any ABI we would ever plausibly support.)
> -#define CMSG_SPACE(len) (CMSG_ALIGN (len) + CMSG_ALIGN (sizeof (struct cmsghdr)))
> -#define CMSG_LEN(len) (CMSG_ALIGN (sizeof (struct cmsghdr)) + (len))
> +#define CMSG_SPACE(len) (CMSG_ALIGN (len) + sizeof (struct cmsghdr))
> +#define CMSG_LEN(len) (sizeof (struct cmsghdr) + (len))
Looks ok I think.
> #define SCM_RIGHTS 0x01
> #define SCM_CREDENTIALS 0x02
> --
>
> By the way, the question which led me to all this stuff is: How do I
> get the payload length of a received cmsg. Neither the man page nor
> an Internet search gave me any satisfactory answer. So my best guess
> was "do some arithmetic with CMSG_LEN":
> payloadlen = cmsghdr->cmsg_len - CMSG_LEN(0);
> However, when double-checking with musl source code, the CMSG_ALIGN
> on struct cmsghdr made me doubt my approach. Now, I will stick to it
> - as long as nobody else has a better idea?
I would probably compute the address of the end of the cmsg and
subtract CMSG_DATA -- something like:
(unsigned char *)cmsg + cmsg->cmsg_len - CMSG_DATA(cmsg)
treating the length as untrusted if appropriate. This might be better
rearranged (so there's no question of overflow if cmsg_len is invalid)
as:
cmsg->cmsg_len - (CMSG_DATA(cmsg) - (unsigned char *)cmsg)
This avoids relying on a nonportable CMSG_LEN macro or assumptions
about it.
Rich
prev parent reply other threads:[~2021-10-03 13:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 10:13 J. Hanne
2021-09-03 13:12 ` Rich Felker
2021-09-05 17:27 ` Markus Wichmann
2021-10-03 8:14 ` J. Hanne
2021-10-03 13:35 ` Rich Felker [this message]
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=20211003133546.GB2559@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@jf.hanne.name \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).