| 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: Mon, 1 Dec 2014 06:53:38 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Willem de Bruijn <willemb@...gle.com>
Cc: Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next 2/3] net-timestamp: allow reading recv cmsg on
errqueue with origin tstamp
On Sun, Nov 30, 2014 at 7:22 PM, Willem de Bruijn <willemb@...gle.com> wrote:
> From: Willem de Bruijn <willemb@...gle.com>
>
> Allow reading of timestamps and cmsg at the same time on all relevant
> socket families. One use is to correlate timestamps with egress
> device, by asking for cmsg IP_PKTINFO.
>
> on AF_INET sockets, call the relevant function (ip_cmsg_recv). To
> avoid changing legacy expectations, only do so if the caller sets a
> new timestamping flag SOF_TIMESTAMPING_OPT_CMSG.
>
> on AF_INET6 sockets, IPV6_PKTINFO and all other recv cmsg are already
> returned for all origins. only change is to set ifindex, which is
> not initialized for all error origins.
>
> In both cases, only generate the pktinfo message if an ifindex is
> known. This is not the case for ACK timestamps.
>
> The difference between the protocol families is probably a historical
> accident as a result of the different conditions for generating cmsg
> in the relevant ip(v6)_recv_error function:
>
> ipv4: if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP) {
> ipv6: if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
>
> At one time, this was the same test bar for the ICMP/ICMP6
> distinction. This is no longer true.
>
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
>
> ----
>
> Changes
> v1 -> v2
> large rewrite
> - integrate with existing pktinfo cmsg generation code
> - on ipv4: only send with new flag, to maintain legacy behavior
> - on ipv6: send at most a single pktinfo cmsg
> - on ipv6: initialize fields if not yet initialized
>
> The recv cmsg interfaces are also relevant to the discussion of
> whether looping packet headers is problematic. For v6, cmsgs that
> identify many headers are already returned. This patch expands
> that to v4. If it sounds reasonable, I will follow with patches
>
> 1. request timestamps without payload with SOF_TIMESTAMPING_OPT_TSONLY
> (http://patchwork.ozlabs.org/patch/366967/)
> 2. sysctl to conditionally drop all timestamps that have payload or
> cmsg from users without CAP_NET_RAW.
> ---
> Documentation/networking/timestamping.txt | 12 +++++++++++-
> include/uapi/linux/net_tstamp.h | 3 ++-
> net/ipv4/ip_sockglue.c | 22 ++++++++++++++++++++--
> net/ipv6/datagram.c | 21 +++++++++++++++++++--
> 4 files changed, 52 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
> index 1d6d02d..b08e272 100644
> --- a/Documentation/networking/timestamping.txt
> +++ b/Documentation/networking/timestamping.txt
> @@ -122,7 +122,7 @@ SOF_TIMESTAMPING_RAW_HARDWARE:
>
> 1.3.3 Timestamp Options
>
> -The interface supports one option
> +The interface supports the options
>
> SOF_TIMESTAMPING_OPT_ID:
>
> @@ -145,6 +145,16 @@ SOF_TIMESTAMPING_OPT_ID:
> stream sockets, it increments with every byte.
>
>
> +SOF_TIMESTAMPING_OPT_CMSG:
> +
> + Support recv() cmsg for all timestamped packets. Control messages
> + are already supported unconditionally on all packets with receive
> + timestamps and on IPv6 packets with transmit timestamp. This option
> + extends them to IPv4 packets with transmit timestamp. One use case
> + is to correlate packets with their egress device, by enabling socket
> + option IP_PKTINFO simultaneously.
> +
I haven't tested yet, but where in the code is the check for
IP_PKTINFO being requested? I may have missed it.
> +
> 1.4 Bytestream Timestamps
>
> The SO_TIMESTAMPING interface supports timestamping of bytes in a
> diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
> index ff35402..edbc888 100644
> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -23,8 +23,9 @@ enum {
> SOF_TIMESTAMPING_OPT_ID = (1<<7),
> SOF_TIMESTAMPING_TX_SCHED = (1<<8),
> SOF_TIMESTAMPING_TX_ACK = (1<<9),
> + SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
>
> - SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_TX_ACK,
> + SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_CMSG,
> SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
> SOF_TIMESTAMPING_LAST
> };
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index 59eba6c..640f26c 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -399,6 +399,22 @@ void ip_local_error(struct sock *sk, int err, __be32 daddr, __be16 port, u32 inf
> kfree_skb(skb);
> }
>
> +static bool ipv4_pktinfo_prepare_errqueue(const struct sock *sk,
> + const struct sk_buff *skb,
> + int ee_origin)
> +{
> + struct in_pktinfo *info = PKTINFO_SKB_CB(skb);
> +
> + if ((ee_origin != SO_EE_ORIGIN_TIMESTAMPING) ||
> + (!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_CMSG)) ||
> + (!skb->dev))
> + return false;
> +
> + info->ipi_spec_dst.s_addr = ip_hdr(skb)->saddr;
Is this the source addr chosen by the initial routing decision when
the packet was sent, or is it the final source addr on the way out?
If the latter, is this an information leak when network namespaces are
in use?
--Andy
--
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