Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Waldemar,

On Fri, Aug 27, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> I assume that user will know that the 16 digit pin is requred, so
> should be enough to let the user type 16 digit in an agent I guess.
> Usually a service that requires high security will generate right pin
> code.

I don't think "the user should know" is enough here, so we may need to
think about ways that we could relay this info to the agent (maybe a
special adapter property or an extra parameter in the PIN request agent
callback).

> Originaly the high security level was planned to require max pin code
> lenght as I know.

That's correct, however the UI side hasn't really been considered so
far.

In general about the patches, I suspect it'll take a bit longer than
usual to get them in since the code you're touching is one of the most
sensitive ones with respect to breakage. We've finetuned it multiple
times over the last few years to get rid of IOP issues, security
vulnerabilities and to make sure all qualification tests pass. Another
reason for an expected delay is that you're introducing changes to the
kernel interface and that always requires some extra reviewing.

So how well have you tested the patches? I.e. how confident are you that
you're not introducing any regressions? Scenarios that would need to be
tested before an upstream merge are (and I'm probably forgetting several
of them):

- legacy pairing acceptor & initiator
- security mode 3 acceptor & initiator
- ssp acceptor & initiator
- renewed link key handling for both debug and normal keys
- security level upgrading (i.e. connect first to a low security socket
  and then over the same ACL to a higher security socket)
- complete and partial failure scenarios for all of the above

Additionally all these test should be done against several different
controllers due to differences in HCI interface behavior (event
ordering, error codes, etc). In that list I'd include at least one CSR,
and one Broadcom adapter and any other adapters from other manufacturers
that you can get hold of.

So how many of these tests do you already have covered? I'm not very
comfortable with pushing the patches upstream before most of the above
scenarios have been tested and verified not to introduce any
regressions.

Johan