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  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]
Date:	Tue, 24 Jun 2008 10:02:42 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>, acme@...hat.com
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Monday 23 of June 2008, Gerrit Renker napisaƂ:
> | > We could still encode the parameters in the policy ID, by splitting the
> | > bitmask, e.g. the low 24 bits to encode parameters, and the high 8 bits
> | > to encode the policies using the same combination of parameters.
> |
> | Yes, technically we could do it this way. Encoding accepted parameters in
> | policy ID would provide applications with means to check whether certain
> | parameters are supported. But should we mix two IMO distinct concepts
> | (policy behaviour and accepted parameters) in one bitfield? I'd rather
> | have them separated.
>
> Yes having them separate gives a clearer semantics. But it comes at a price
> - to retrieve the parameters, we need an extra function or lookup table.
>
An additional bitfield in dccp_qpolicy_operations should do it when it comes 
to storing that information. When it comes to retrieving see next point...

> Maybe there is an elegant solution which allows to encode the required
> parameters while keeping the semantics clear?
>
What about something like:
	setsockopt(sockfd, DCCP_SOCKOPT_QPOLICY_ID, DCCPQ_POLICY_PRIO);
to choose policy (exactly as it is now) and a new function to ensure that the 
kernel understands parameters:
	setsockopt(sockfd, DCCP_SOCKOPT_QPOLICY_PARAMS, DCCP_SCM_PRIORITY | 
DCCP_SCM_TIMEOUT);

The second call would return an error if the kernel does not know anything 
about DCCP_SCM_TIMEOUT (or a choosen policy does not support it). This would 
have the additional benefit (over similar getsockopt) that the kernel will be 
able to optimize its behaviour knowning the set of parameters that will be 
used.

What do you think about such an interface?
-- 
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