linux-kernel - Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]

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]

Message-ID: <15256.1174429573@redhat.com>
Date:	Tue, 20 Mar 2007 22:26:13 +0000
From:	David Howells <dhowells@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, herbert.xu@...hat.com,
	linux-kernel@...r.kernel.org, hch@...radead.org,
	arjan@...radead.org, dhowells@...hat.com
Subject: Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3] 

Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
> fixed one day as its useful to find out the sizeof message pending when
> combined with MSG_PEEK

Hmmm...  I hadn't considered that.  I assumed MSG_TRUNC not to be useful as
arbitrarily chopping bits out of the request or reply would seem to be
pointless.

> - RXRPC_MIN_SECURITY_LEVEL reads into rx->min_sec_level and then if it is
> invalid reports an error but doesn't restore the valid level

Fixed.

> - Why does rxrpc_writable always return 0 ?

Good point.  That's slightly tricky to deal with as output messages don't
remain queued on the socket struct itself.  Hmmm...

One thing I'd like to be able to do is pass the sk_buffs I've set up to UDP
directly rather than having to call the UDP socket's sendmsg.  That'd eliminate
a copy.  But I decided to get it working right first, then look at cute
optimisations like that.

Such a thing would also be useful for the AFS filesystem: it could pass skbuffs
it has preloaded to AF_RXRPC, which would then hand them on to UDP.

> - rxrpc_process_soft_ACKs doesn't itself limit and check acns->nAcks is
> always below RXRPC_MAXACKS, as this is a stakc variable it ought to be
> paranoid about it. I think its ok from the caller check but its very hard
> to prove...

nAcks is a uint8_t.  If that can exceed RXRPC_MAXACKS (255) then I suspect I'll
have more pressing worries.  I could put a check in there, but the compiler
would give me a warning:-/

> It needs a lot more eyes/review due to the complexity and network
> exposure though - not your fault, whoever designed RXRPC's 8)

It's not an entirely insane protocol:-) Actually, part of the problem is Linux
itself.

David
-
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/