netdev - Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F

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

Date:	Mon, 28 Oct 2013 20:43:06 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	jiri@...nulli.us, vyasevich@...il.com, netdev@...r.kernel.org,
	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, thaller@...hat.com, stephen@...workplumber.org
Subject: Re: [patch net-next] ipv6: allow userspace to create address with
 IFLA_F_TEMPORARY flag

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Tue, 29 Oct 2013 00:31:58 +0100

> I wonder why NetworkManager rewrote IPv6 router discovery but not IPv4
> DHCP client stuff. It could have been a good moment to introduce something
> like PROT_DHCP sockets. Maybe it is not too late... ;)

Note that you don't even need to put the DHCP protocol core into the
kernel to fix the promiscuous problem.  You just have to use the
current kernel interfaces correctly.

It used to be the case a very long time ago that you couldn't even
receive broadcast UDP datagrams on a socket until an address was
configured on it.

So everyone turns on promiscuous mode and uses RAW sockets or
AF_PACKET.

Stupid?  yes.

But now the kernel will receive broadcast UDP datagrams just fine even
if there are no ipv4 addresses assigned yet.

I did a mock-up simple ipv4 DHCP client implementation just to test it
out, and it did work just fine.  Unfortunately, I can't find it at the
moment, I hope I didn't just delete it in frustration. :-)

> My current idea to handle this, is that a kernel boot parameter is
> provided to stop the generation of link-local addresses and that we kick
> off address configuration from user-space at early as the secret key is
> provided, which may well be from the initramfs. I'll send a RFC as soon
> as I can find some time to clean it up and have it actually tested.

I guess I'm ok with this, as I can't come up with any reasonable
alternative scheme.
--
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