All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.