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: <200804152001.58528.tomasz@grobelny.oswiecenia.net>
Date:	Tue, 15 Apr 2008 20:01:58 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

Dnia Tuesday 15 of April 2008, Gerrit Renker napisaƂ:
> | | What happens if application is compiled with dccp_packet_info
> | | containing only one field (priority) and kernel containing two fields
> | | (for example priority and later added expiry time)? Wouldn't that
> | | implementation make extensions to dccp_packet_info impossible?
> |
> | Had not looked at it from this point of view. So you are suggesting
> |
> | 	if (msg->msg_control != NULL && msg->msg_controllen >= sizeof(*dcp))
> | 		dcp = (struct dccp_packet_info *)msg->msg_control;
> |
> | instead? Agreed, point #1 to change in the patch.
>
> No, the above is nonsense. If the application uses an earlier version of
> the API, then it needs to be recompiled, there is no way it could pretend
> to have an adequate size.
>
That would effectively stop development of any policy. And it's not about 
pretending the structure has different size, it's just about using only the 
data that is provided by the application (even though it may be incomplete).

> So my take is that still the '==' is correct. But maybe this is a known
> problem?
>
I can't see a problem with copying smaller struct to bigger one. It would work 
like that:
1. set default values for in-kernel structure,
2. copy min(msg_control, sizeof(struct dccp_packet_info)) bytes from userspace 
structure to the kernel one.

In that sense the code above is in fact wrong but the idea alone should be ok.
-- 
Regards,
Tomasz Grobelny
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ