Re: [PATCH] wireless: fixup genregdb.awk for remove of antenna gain from wireless-regdb

[Kees Cook]

On Mon, Jul 14, 2014 at 2:33 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Mon, Jul 14, 2014 at 2:13 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> On Mon, Jul 14, 2014 at 2:08 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
>>> On Wed, Jul 2, 2014 at 7:30 AM, John W. Linville <linville@xxxxxxxxxxxxx> wrote:
>>>> On Wed, Jul 02, 2014 at 02:19:36AM +0200, Luis R. Rodriguez wrote:
>>>>> On Tue, Jul 01, 2014 at 04:17:54PM -0400, John W. Linville wrote:
>>>>> > Since "wireless-regdb: remove antenna gain" was merged in the
>>>>> > wireless-regdb tree, this script has been incompatible with the
>>>>> > 'official' regulatory database.  Let's fix it up.
>>>>> >
>>>>> > Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
>>>>> > ---
>>>>> > I think the dfs_cac stuff is still broken, since it does not account
>>>>> > for the starting offset of the flags.
>>>>>
>>>>> Indeed, but that also breaks other stuff too, because the DFS CAC stuff
>>>>> is optional it means the flags can now start at different locations, it
>>>>> also means that we need to distinguish a flag from a CAC.
>>>>>
>>>>> Here's a complex example we should test for as an example now:
>>>>>
>>>>> country US: DFS-FCC
>>>>>       (2400 - 2450 @ 40), (100 mW)
>>>>>       (2450 - 2500 @ 0), (100 mW), DFS, AUTO-BW
>>>>>       (5170 - 5250 @ 80), (100 mW), DFS, AUTO-BW, NO-OUTDOOR
>>>>>       (5250 - 5330 @ 0), (20), (60000), DFS, AUTO-BW
>>>>>       (5735 - 5835 @ 80), (30)
>>>>>       (57240 - 63720 @ 2160), (40)
>>>>>
>>>>> The changes below seem to address it. I think awk is too fragile to
>>>>
>>>> Your patch looks almost exactly like what I was thinkg to do.
>>>
>>> OK I'll resend and update the Kconfig entry to ensure folks are aware
>>> of the issues discussed and our resolution on requiring folks deal
>>> with issue on the awk parser.
>>>
>>>>> scale well and keep us sane. A C parser exists but right now it
>>>>> ignores the DFS CAC. Having a parser is nice as it allows us to
>>>>> modify the db.txt on the fly, however parser still requires a bit
>>>>> of an update in code. If we wanted to avoid the parser all together
>>>>> we could just merge a CRDA reader at build time and require a
>>>>> a regulatory.bin file for reading instead of the db.txt. If we
>>>>> had support for that then its really only one step further from
>>>>> having full CRDA functionality upstream on the kernel, ie letting
>>>>> us read the file at run time rather than just build time. If we
>>>>> are to follow the steps from udev with its firmware loader helper
>>>>> we might as well merge CRDA upstream, in fact we could just use
>>>>> request_firmware_direct() for the reader, what remains questionable
>>>>> to me is the signing stuff, but if we already have support module
>>>>> signing checks it doesn't seem far fetched to be able to have
>>>>> request firmware verify a signature on a file, which probably
>>>>> ain't such a bad idea anyway. If we did this we'd have two options:
>>>>>
>>>>> 1) regulatory.bin reader at build time to build the static regulatory domains
>>>>> 2) the same reader code can use request the file at run time via
>>>>>    request_firmware_direct() and if we added signature verification
>>>>>    it can replace CRDA
>>>>>
>>>>> We'd eliminate the ASCII representation completely from the build picture
>>>>> and peg a regulatory.bin firmware to each kernel then. Thoughts?
>>>>
>>>> I'll have to digest this -- needs some more discussion, for sure.
>>>
>>> Some more on this. I stumbled upon Takashi Iwai's November 2012
>>> firmware_class Takashi Iwai's signature check series [0] [1]. His
>>> second iteration didn't get merged but there weren't any particular
>>> NACKs on the threads -- upon following up with him it would seem the
>>> way to move this forward though is to integrate this somehow with Kees
>>> Cook's work on LSM. I have yet to do that but at least by looking at
>>
>> I've got LSM hooks built to check incoming firmware. It should be
>> trivial to add signature checks to that. For Chrome OS, that would be
>> redundant since we use dm-verity to check file contents. All Chrome OS
>> needs to know is where the firmware came from. Here's the current
>> tree:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=fw-restrict
>
> Awesome! Base do a quick glance it seems Android also uses this,
> dm-verity [0] uses public keys as well so it would indeed also provide
> authenticity / integrity checks which would indeed make firmware
> signature checks redundant, the only requirement however is you'd
> require the checks on the partition, and I do suspect not all
> distributions will want to go down this path. If we can extend the LSM
> hooks to give the option for signatures on firmware we'd enable
> distributions to pick and choose a strategy. Can we let LSM hooks then
> figure out if a digital signature is superfluous if dm-verity is being
> used ? I suspect there may be some cases where a module / part of the
> kernel may want to *force* the presence of a signature check but I
> don't think that this is a requirement for all use cases.

I'm not sure what the best approach is for this. I added the
finit_module syscall to provide a similar interface for kernel module
loading, but the module signing happens in a separate path. I think
it'd be nice to move things around a little on the module signing path
so it was all exposed via LSM, and then install a sig-checking LSM.
(Which may or may not also require stacked LSMs, a project that is
being worked on as well.)

Note also that we may need something like this for kexec too.

I will send out the fw validation series now...

-Kees

>
> [0] https://source.android.com/devices/tech/security/dm-verity.html
>
>   Luis



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/