Linux bluetooth development
 help / color / mirror / Atom feed
From: Ravi Kumar Veeramally <ravikumar.veeramally@linux.intel.com>
To: Szymon Janc <szymon.janc@tieto.com>,
	Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH_v3 3/3] android/pan: Handle connection and control state notifications
Date: Wed, 13 Nov 2013 12:11:54 +0200	[thread overview]
Message-ID: <5283506A.4090105@linux.intel.com> (raw)
In-Reply-To: <1726751.Pm6h7gxZKd@uw000953>


On 11/13/2013 11:59 AM, Szymon Janc wrote:
> Hi,
>
>>>> +
>>>> +	switch (opcode) {
>>>> +	case HAL_EV_PAN_CONN_STATE:
>>>> +		handle_conn_state(buf);
>>>> +		break;
>>>> +	case HAL_EV_PAN_CTRL_STATE:
>>>> +		handle_ctrl_state(buf);
>>>> +		break;
>>>> +	default:
>>>> +		DBG("Unhandled callback opcode=0x%x", opcode);
>>>> +		break;
>>>> +	}
>>>>    }
>>> What I don't like about this is that you're not pushing the data length
>>> to the handler functions. If you did that the handler functions could:
>>>
>>> 	if (len < sizeof(*ev))
>>> 		return;
>>>
>>> Instead of return we could also just abort - what's the general policy
>>> on the HAL side regarding invalid data from the daemon? How does this
>>> relate to the work Szymon is doing to add proper checks for the IPC
>>> data? Is that only for the daemon side?
>>>
>>> Are we missing similar checks in other HALs too?
>>     Yes, we are not doing similar checks in other HALs
>> (hal-bluetooth/a2dp/hid/) too.
>>     Very few places in hal-bluetooth length is passing but validation is
>> not done.
>>     I will fix them all and send you the patch.
> As mentioned in my RFC, messages have very similar format and can be checked
> in single place using some common macros. I'm now working on addressing Johan
> comments in that RFC. As suggested I'm going to use tables of handlers instead
> switch-case and this should also allow to refactor current code to avoid
> switch-cases we currently have. Services will simply register own tables of
> handlers for service they implement. Idea is that check will be done in common
> place and then handlers will have form of  void handle_foo(struct foo *ev) with
> guarantee that passed command/event is memory size valid.
>
> Plan is to make this generic code use both by hal and daemon.
>
> So, I'm not sure if it makes much sense to fix passing buf+len to all handlers
> we have now.
>
> If you have other ideas for this please comment.
>
   Ok, good to know.
  Johan: Can you now apply my left over patch?

  Thanks,
  Ravi.

  reply	other threads:[~2013-11-13 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13  9:25 [PATCH_v3 1/3] android: Fix opcode parameter type from uint16_t to uint8_t Ravi kumar Veeramally
2013-11-13  9:25 ` [PATCH_v3 2/3] android/pan: Add notify method to PAN notifications Ravi kumar Veeramally
2013-11-13  9:25 ` [PATCH_v3 3/3] android/pan: Handle connection and control state notifications Ravi kumar Veeramally
2013-11-13  9:33   ` Johan Hedberg
2013-11-13  9:46     ` Ravi Kumar Veeramally
2013-11-13  9:59       ` Szymon Janc
2013-11-13 10:11         ` Ravi Kumar Veeramally [this message]
2013-11-13 11:16           ` Johan Hedberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5283506A.4090105@linux.intel.com \
    --to=ravikumar.veeramally@linux.intel.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=szymon.janc@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox