netdev - Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af

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: <478F4C06.4040704@iki.fi>
Date:	Thu, 17 Jan 2008 14:37:26 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	David Miller <davem@...emloft.net>
CC:	herbert@...dor.apana.org.au, hadi@...erus.ca,
	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key

David Miller wrote:
> From: Timo_Teräs <timo.teras@....fi>
> Date: Thu, 17 Jan 2008 13:00:09 +0200
> 
>> IMHO, it's a lot better then losing >50% of entries and the end
>> of sequence message on big dumps. SPD and SADB are not that
>> volatile; in most of the cases the dump would be as good as an
>> atomic one.
> 
> I humbly disagree with you.  Interface behavior stability
> is more important.

Small SPDs/SADBs would still be dumped atomically. The patch
affects only the cases when the receive queue is getting full.

>> I'm not sure if there's other major applications that we should
>> be concerned about, but at least ipsec-tools racoon does not
>> expect to get atomic dumps (which btw, comes originally from BSD).
> 
> Racoon was written as an addon to the BSD stack by an IPV6/IPSEC
> project in Japan named KAME, it did not "come from BSD".  It was
> added to BSD.
> 
> There are also other BSD based IPSEC daemons such as the one written
> by the OpenBSD folks.

Yes. I meant that it was originally written to be used in BSD. The
Linux port came later. Sorry for the ambiguous wording.

> I don't think this is arguable at all.  We're not changing semantics
> over what we've done for 4+ years and applications might depend upon.
> It's for a deprecated interface, which makes any semantic changes that
> much less inviting.
> 
> You can argue all you want, but it will not change the invariants in
> the previous paragraph.

True. If no one else agrees with me, I'll drop it. I can always run
my own patched kernel.

I'd appreciate feedback on the xfrm changes. I'll try to make that
part usable patch against net-2.6.25 git tree next week.
--
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