Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 12月, 2006 3 次提交
  3. 12 10月, 2006 1 次提交
  5. 29 9月, 2006 1 次提交
  7. 23 9月, 2006 15 次提交
  9. 09 8月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  13. 30 6月, 2006 1 次提交
  15. 23 3月, 2006 1 次提交
    • J
      [PATCH] WE-20 for kernel 2.6.16 · 711e2c33
      由 Jean Tourrilhes 提交于 
      	This is version 20 of the Wireless Extensions. This is the
completion of the RtNetlink work I started early 2004, it enables the
full Wireless Extension API over RtNetlink.

	Few comments on the patch :
	o totally driver transparent, no change in drivers needed.
	o iwevent were already RtNetlink based since they were created
(around 2.5.7). This adds all the regular SET and GET requests over
RtNetlink, using the exact same mechanism and data format as iwevents.
	o This is a Kconfig option, as currently most people have no
need for it. Surprisingly, patch is actually small and well
encapsulated.
	o Tested on SMP, attention as been paid to make it 64 bits clean.
	o Code do probably too many checks and could be further
optimised, but better safe than sorry.
	o RtNetlink based version of the Wireless Tools available on
my web page for people inclined to try out this stuff.

	I would also like to thank Alexey Kuznetsov for his helpful
suggestions to make this patch better.
Signed-off-by: NJean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      711e2c33
  17. 21 3月, 2006 2 次提交
    • S
      [NET]: Convert RTNL to mutex. · 6756ae4b
      由 Stephen Hemminger 提交于 
      This patch turns the RTNL from a semaphore to a new 2.6.16 mutex and
gets rid of some of the leftover legacy.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6756ae4b
    • S
      [NET] core: add RFC2863 operstate · b00055aa
      由 Stefan Rompf 提交于 
      this patch adds a dormant flag to network devices, RFC2863 operstate derived
from these flags and possibility for userspace interaction. It allows drivers
to signal that a device is unusable for user traffic without disabling
queueing (and therefore the possibility for protocol establishment traffic to
flow) and a userspace supplicant (WPA, 802.1X) to mark a device unusable
without changes to the driver.

It is the result of our long discussion. However I must admit that it
represents what Jamal and I agreed on with compromises towards Krzysztof, but
Thomas and Krzysztof still disagree with some parts. Anyway I think it should
be applied.
Signed-off-by: NStefan Rompf <stefan@loplof.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b00055aa
  19. 10 2月, 2006 1 次提交
  21. 10 11月, 2005 2 次提交
  23. 30 8月, 2005 3 次提交
  25. 29 6月, 2005 2 次提交
  27. 19 6月, 2005 3 次提交
  29. 04 5月, 2005 3 次提交
    • D
      [XFRM/RTNETLINK]: Decrement qlen properly in {xfrm_,rt}netlink_rcv(). · 0f4821e7
      由 David S. Miller 提交于 
      If we free up a partially processed packet because it's
skb->len dropped to zero, we need to decrement qlen because
we are dropping out of the top-level loop so it will do
the decrement for us.

Spotted by Herbert Xu.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f4821e7
    • D
      [NETLINK]: Fix infinite loops in synchronous netlink changes. · 09e14305
      由 David S. Miller 提交于 
      The qlen should continue to decrement, even if we
pop partially processed SKBs back onto the receive queue.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09e14305
    • H
      [NETLINK]: Synchronous message processing. · 2a0a6ebe
      由 Herbert Xu 提交于 
      Let's recap the problem.  The current asynchronous netlink kernel
message processing is vulnerable to these attacks:

1) Hit and run: Attacker sends one or more messages and then exits
before they're processed.  This may confuse/disable the next netlink
user that gets the netlink address of the attacker since it may
receive the responses to the attacker's messages.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.
c) Restrict/prohibit binding.

2) Starvation: Because various netlink rcv functions were written
to not return until all messages have been processed on a socket,
it is possible for these functions to execute for an arbitrarily
long period of time.  If this is successfully exploited it could
also be used to hold rtnl forever.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.

Firstly let's cross off solution c).  It only solves the first
problem and it has user-visible impacts.  In particular, it'll
break user space applications that expect to bind or communicate
with specific netlink addresses (pid's).

So we're left with a choice of synchronous processing versus
SOCK_STREAM for netlink.

For the moment I'm sticking with the synchronous approach as
suggested by Alexey since it's simpler and I'd rather spend
my time working on other things.

However, it does have a number of deficiencies compared to the
stream mode solution:

1) User-space to user-space netlink communication is still vulnerable.

2) Inefficient use of resources.  This is especially true for rtnetlink
since the lock is shared with other users such as networking drivers.
The latter could hold the rtnl while communicating with hardware which
causes the rtnetlink user to wait when it could be doing other things.

3) It is still possible to DoS all netlink users by flooding the kernel
netlink receive queue.  The attacker simply fills the receive socket
with a single netlink message that fills up the entire queue.  The
attacker then continues to call sendmsg with the same message in a loop.

Point 3) can be countered by retransmissions in user-space code, however
it is pretty messy.

In light of these problems (in particular, point 3), we should implement
stream mode netlink at some point.  In the mean time, here is a patch
that implements synchronous processing.  
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a0a6ebe