netdev - Re: [PATCH net-next 0/6] A step closer to RFC 6458 compliancy

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: <84A786A6-D242-4DC6-8FC4-573A91A88311@lurchi.franken.de>
Date:	Wed, 18 Jun 2014 14:43:31 +0200
From:	Michael Tuexen <Michael.Tuexen@...chi.franken.de>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Vlad Yasevich <vyasevich@...il.com>,
	Geir Ola Vaagland <geirola@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: Re: [PATCH net-next 0/6] A step closer to RFC 6458 compliancy

On 18 Jun 2014, at 10:42, David Laight <David.Laight@...LAB.COM> wrote:

> From: Vlad Yasevich
>> On 06/17/2014 11:36 AM, David Laight wrote:
>>> From: Of Geir Ola Vaagland
>>>> These patches are part of my master thesis project. I have been searching for discrepancies between
>>>> the socket API specificiation in RFC 6458 and the current Linux SCTP implementation. The following
>>>> patches are my humble attempts at getting somewhat closer to compliancy.
>>> 
>>> I've just been reading RFC 6458 - HTF did it get past the editors and
>>> then published in its current form?
>>> Lots of the structures have implied padding.
> ...
>> I've argued the padding issue, but the editor stance is that it's implementation
>> dependent.
> 
> It wouldn't be as bad if the RFC said that the structure contained the
> fields that followed (as is typical of the posix definitions),
> but instead it gives a definition of the structure.
That would have been a possibility, but it was never suggested.
As far as I know, C does not guarantee the memory layout for structs,
except for the sequence of the components. So a compiler might add
some padding at any place. When implementing this, you need to take
care of this (and your job might be simpler, since you might only
work with a specific set of compilers).
In FreeBSD we also added some padding to some structures since they
"evolved" during the lifetime of of the internet draft and we wanted
to preserve some compatibility.
I agree, that one must take care of the implied padding and I will double
check how this is handled in FreeBSD. Not sure...

Best regards
Michael
> 
> That isn't implementation friendly at all.
> 
> 	David
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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