linux-kernel - Re: [RFC][PATCH] af_key: return error when meet errors on sendmsg() syscall

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: <20140512.011141.74073195599318391.davem@davemloft.net>
Date:	Mon, 12 May 2014 01:11:41 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	xufeng.zhang@...driver.com
Cc:	steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] af_key: return error when meet errors on
 sendmsg() syscall

From: Xufeng Zhang <xufeng.zhang@...driver.com>
Date: Fri, 9 May 2014 13:47:35 +0800

> Current implementation for pfkey_sendmsg() always return success
> no matter whether or not error happens during this syscall,
> this is incompatible with the general send()/sendmsg() API:
>   man send
>     RETURN VALUE
>       On success, these calls return the number of characters sent.
>       On error, -1 is returned, and errno is set appropriately.
> 
> One side effect this problem introduces is that we can't determine
> when to resend the message when the previous send() fails because
> it was interrupted by signals.
> We detect such a problem when racoon is sending SADBADD message to
> add SAD entry in the kernel, but sometimes kernel is responding with
> "Interrupted system call"(-EINTR) error.
> 
> Check the send implementation of strongswan, it has below logic:
>   pfkey_send_socket()
>   {
>   	...
>   	while (TRUE)
>   	{
>         	len = send(socket, in, in_len, 0);
> 
>   		if (len != in_len)
>   		{
>   			case EINTR:
>   				/* interrupted, try again */
>   				continue;
>   			...
>   		}
>   	}
>   	...
> }
> So it makes sense to return errors for send() syscall.      
> 
> Signed-off-by: Xufeng Zhang <xufeng.zhang@...driver.com>

I disagree.

If pfkey_error() is successful, the error will be reported in the AF_KEY
message that is broadcast, there is no reason for sendmsg to return an
error.  The message was sucessfully sent, there was no problem with it's
passage into the AF_KEY layer.

Like netlink, operational responses come in packets, not error codes.

However, if pfkey_error() fails, we must do pass back the original
error code because it's a last ditch effort to prevent information
from being lost.

That's why 'err' must be preserved when pfkey_error() returns zero.
--
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/