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

[Luis R. Rodriguez]

On Mon, Jul 14, 2014 at 02:37:50PM -0700, Kees Cook wrote:
> 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.

Yeah that is all module specific and I think it'd be overkill to add
something fw specific, even though we could share the same file descriptor
approach. Wonder if a more general kobject thing could be a good way
to scale this without having to add any more syscalls for the different
use cases.

> 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.

Makes sense.

  Luis
--
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/