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  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, 10 Mar 2014 15:30:01 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eparis@...hat.com
Cc:	ebiederm@...ssion.com, sgrubb@...hat.com, rgb@...hat.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-audit@...hat.com, akpm@...ux-foundation.org
Subject: Re: [RFC][PATCH] audit: Simplify by assuming the callers socket
 buffer is large enough

From: Eric Paris <eparis@...hat.com>
Date: Fri, 07 Mar 2014 17:52:02 -0500

> The second user Eric patched, audit_send_list(), can grow without bound.
> The number of skb's is going to be the size of the number of audit rules
> that root loaded.  We run the list of rules, generate an skb per rule,
> and add all of them to an skb_buff_head.  We then pass the skb_buff_head
> to a kthread so that current will be able to read/drain the socket.
> There really is no limit to how big the skb_buff_head could possibly
> grow.  This doesn't necessarily absolutely have to be lossless but it
> can actually quite reasonably be a whole lot of data that needs to get
> sent.  I know of no way to deliver unbounded lengths of data to the
> current task via netlink without blocking on more space in the socket.
> Even if the socket rmem was MAX_INT, how can we deliver more?  The rule
> size is unbounded.  How do I get an unbounded amount of data onto this
> side of the socket when I have to generate it all during the request...

This is what netlink dumps  are for.  It is how we are able to dump
routing tables with millions of routes to userspace.

By using normal netlink requests and netlink_unicast() for this, you
are ignoring an entire mechanism in netlink designed specifically to
handle this kind of situation.

Netlink dumps track state and build one or more SKBs (as necessary),
one by one, to form the reply.  It implements flow control, state
tracking for iteration, optimized SKB sizing and allocation, etc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists