netdev - RE: [7/8,RFC] CAIF Protocol Stack

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]

Date:	Fri, 9 Oct 2009 14:37:43 +0200
From:	Sjur Brændeland <sjur.brandeland@...ricsson.com>
To:	"Stefano Babic" <stefano.babic@...ic.homelinux.org>
Cc:	<netdev@...r.kernel.org>,
	"Kim Lilliestierna XX" <kim.xx.lilliestierna@...ricsson.com>
Subject: RE: [7/8,RFC] CAIF Protocol Stack

Hi Stefano.
Thank you very much for looking into this!
I find this as very valuable feedback.

Stefano Babic wrote:
> I discovered there is a production bug in the Makefile and the setup
> of the extract function in cfcnfg_get_packet_funcs() is inconsistent. 
> Indeed, I traced the address of the extract function and I can find
> that the address does not point to cfpkt_extract(), as I assumed. 
> 
> The problem is due to the usage of the define CAIF_USE_SKB. This is
> used in caif_layer.h, but some files (net/caif/*) are compiled with
> the macro defined, while the drivers (drivers/net/caif/*) not.  
> Rather I did not get an "oops", because a valid pointer was
> set....but to the wrong function ! 
> I have also seen that CAIF_USE_SKB is not used in
> cfpkt_get_packet_funcs, and this generates a problem if CAIF_USE_SKB
> is not set, because the "fromnative" and "tonative" functions are
> always set, even if they do not belong to the structure.   

Well done finding this! I have corrected this as suggested in the new patch-set.

> 
> IMHO should be possible to get rid of the usage of CAIF_USE_SKB in
> the structure definition (in caif_layer.h) and to provide always the
> same structure definition in both case. I would prefer to set the
> values of cfpkt_fromnative and cfpkt_tonative to NULL, instead of
> reducing the size of the structure.    

Agree, and done.
> 
> I am not sure I understood the meaning of using this structure,
> because at the moment the setup is fixed and I cannot find any point
> in code where the structure is assigned to another set of functions.
> Probably you arrange to have multiple choices in future, I can
> suppose.    
> 

The choices are decided compile time from Kconfig.

> What about to pass directly the pointer to the structure instead of
> copying returning its value ? It seems not necessary to me, I changed
> cfpkt_get_packet_funcs in this direction.  

I haven't done this yet, but it seems reasonable.

> 
> Meanwhile, it seems some bytes are sent now to the physical interface.
> 
> <caif_chropen:797, TRACE> [caif_chropen:797] WAIT FOR CONNECT
> RESPONSE <caif_chropen:820, TRACE> caif_open: connect timed out 
> 
> However, I get no connection, but probably this is another problem....
> 

Do you have a (ST-)Ericsson modem talking CAIF connected?
The correct behavior is to wait for the CONNECT_RESPONSE, and time out.

BR/Sjur Brændeland
--
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