netdev - Re: [RFC PATCH] ila: Resolver mechanism

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] [day] [month] [year] [list]

Date:	Fri, 1 Jul 2016 00:02:00 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Tom Herbert <tom@...bertland.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, kernel-team@...com,
	haoxuany@...com
Subject: Re: [RFC PATCH] ila: Resolver mechanism

On 06/30/16 at 12:41pm, Tom Herbert wrote:
> This is not yet complete, we would still need to some controls
> to rate limit number of resolution requests and a means to track
> pending requests. I'm posting this as RFC because it seems like
> this might be part of a general mechanism to a perform address
> resolution in userspace and I would appreciate comments with
> regard to that.

I wouldn't mind having the rate limiting done as generic route
attribute so it could be applied to non-ILA routes as well.

> 
> diff --git a/include/uapi/linux/lwtunnel.h b/include/uapi/linux/lwtunnel.h
> index a478fe8..d880e49 100644
> --- a/include/uapi/linux/lwtunnel.h
> +++ b/include/uapi/linux/lwtunnel.h
> @@ -9,6 +9,7 @@ enum lwtunnel_encap_types {
>  	LWTUNNEL_ENCAP_IP,
>  	LWTUNNEL_ENCAP_ILA,
>  	LWTUNNEL_ENCAP_IP6,
> +	LWTUNNEL_ENCAP_ILA_NOTIFY,
>  	__LWTUNNEL_ENCAP_MAX,
>  };

Neat.

> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index 262f037..271215f 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -144,6 +144,9 @@ enum {
>  	RTM_GETSTATS = 94,
>  #define RTM_GETSTATS RTM_GETSTATS
>  
> +	RTM_ADDR_RESOLVE = 95,
> +#define RTM_ADDR_RESOLVE RTM_ADDR_RESOLVE
> +

I realize this is currently only kernel->user but let's plan ahead.
Each RTM_ group should start aligned to 4 with types specified in
the order new, del, get, set. RTM_ADDR_RESOLVE probably maps best
to NEW in terms of behaviour. See the magic around 'kind' in
rtnetlink_rcv_msg().