Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel]arstechnica confirmstp-link router lockdown

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel]arstechnica confirmstp-link router lockdown

[dpreed]

There are many processor architectures that have different instruction memories for different functional units. 

SoCs often have multiple functional units on the same die. For radios that allows for a pipeline. You can limit what an EPROM will accept with a crypto signature.

This is common stuff.

-----Original Message-----
From: "David Lang" <david@lang.hm>
Sent: Mon, Mar 14, 2016 at 3:04 pm
To: dpreed@reed.com
Cc: "Wayne Workman" <wayne.workman2012@gmail.com>, "bufferbloat-fcc-discuss" <bufferbloat-fcc-discuss@lists.redbarn.org>, cerowrt-devel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel]arstechnica confirmstp-link router lockdown

On Mon, 14 Mar 2016, dpreed@reed.com wrote:

> An external "limit-exceeding signal detector" could also be very inexpensive, 
> if it did not need to do ADC from the transmitted signal, but could get access 
> to the digital samples and do a simple power measurement.

I agree with this, but have concerns about how you can lock down part of the 
firmware and not all of it.

You still have the problem of telling the chip/algorithm which set of rules to 
enforce, and updating it when the requirements change.

David Lang

Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[Jonathan Morton]

> On 15 Mar, 2016, at 05:47, dpreed@reed.com wrote:
> 
> SoCs often have multiple functional units on the same die. For radios that allows for a pipeline. You can limit what an EPROM will accept with a crypto signature.
> 
> This is common stuff.

As an example of this, AMD’s APUs and GPUs require several different firmware blobs to bring up their 3D capabilities.  The on-board BIOS supplies only what is necessary for basic SVGA framebuffer mode, which the operating system can use as a stopgap until the drivers are installed.

In Linux, these firmware blobs are identified by the IP block’s codename.  Most APUs and GPUs require a SUMO or SUMO2 blob to bring up the RAMDACs, and a separate GPU-specific blob (VERDE for my 7770) for the graphics engine itself, which takes up a much larger portion of the die.

I’m not sure whether these blobs are signed in AMD’s system, but they could be.  Their APUs have a Cortex-A5 based “secure processor” which could in principle be tied into the firmware-loading process, and probably has its own secure ROM.  A Cortex-M microcontroller core and ROM to do the job on a GPU would be tiny.

 - Jonathan Morton

Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[David Lang]

On Mon, 14 Mar 2016, dpreed@reed.com wrote:

> But it will take working with both the FCC and the chip vendors, and the home 
> access point vendors with a common purpose and agenda. That agenda needs to be 
> to find the minimum lock that will satisfy the FCC, and a sufficiently cheap 
> implementation that, along with the cost saving on design certification, it is 
> cheaper to make a router that is otherwise open, than to make one whose 
> certification depends on review of all the code in the router.

This should never require review of all the code in the router. At most it 
should require review of the firmware code for the wifi chip.

Linux has had this sort of thing in the past, look at the ISDN code that 
required certification to operate.

> This is a common design pattern. The DAA for phones is now purchasable as a 
> single module, FCC precertified, so one can make any kind of cordless phone be 
> certifiable, merely by using that part. That part is more expensive than one I 
> could design myself, but it saves on certification cost, because the rest of 
> the phone or modem doesnt need certification, so one can innovate.

The problem is how much stuff gets stuffed in this certified component. Cell 
phones, with their 'baseband processor' are a good example of too much 
functionality being in the certified component.

We want to get more access to what's currently in the wifi chipset firmware, not 
have it all locked down more.

David Lang

Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[David Lang]

On Mon, 14 Mar 2016, Jonathan Morton wrote:

>> On 14 Mar, 2016, at 16:02, dpreed@reed.com wrote:
>>
>> The WiFi protocols themselves are not a worry of the FCC at all. Modifying 
>> them in software is ok. Just the physical emissions spectrum must be 
>> certified not to be exceeded.
>>
>> So as a practical matter, one could even satisfy this rule with an external 
>> filter and power limiter alone, except in part of the 5 GHz band where radios 
>> must turn off if a radar is detected by a specified algorithm.
>>
>> That means that the radio software itself could be tasked with a software 
>> filter in the D/A converter that is burned into the chip, and not bypassable. 
>> If the update path requires a key that is secret, that should be enough, as 
>> key based updating is fine for all radios sold for other uses that use 
>> digital modulation using DSP.
>>
>> So the problem is that 802.11 chips don't split out the two functions, making 
>> one hard to update.
>
> To put this another way, what we need is a cleaner separation of ISO Layers 1 
> (physical) and 2 (MAC).

The problem is that everything (not just in wifi chips, think about 'software 
defined networking/datacenter) is moving towards less separation of the 
different layers, not more. The benefits of less separation are far more 
flexibility, lower costs, and in some cases, the ability to do things that 
weren't possible with the separation.

Any position that requires bucking this trend is going to have a very hard time 
surviving.

David Lang

Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[Jonathan Morton]

> On 14 Mar, 2016, at 16:02, dpreed@reed.com wrote:
> 
> The WiFi protocols themselves are not a worry of the FCC at all. Modifying them in software is ok. Just the physical emissions spectrum must be certified not to be exceeded.
> 
> So as a practical matter, one could even satisfy this rule with an external filter and power limiter alone, except in part of the 5 GHz band where radios must turn off if a radar is detected by a specified algorithm.
> 
> That means that the radio software itself could be tasked with a software filter in the D/A converter that is burned into the chip, and not bypassable. If the update path requires a key that is secret, that should be enough, as key based updating is fine for all radios sold for other uses that use digital modulation using DSP.
> 
> So the problem is that 802.11 chips don't split out the two functions, making one hard to update.

To put this another way, what we need is a cleaner separation of ISO Layers 1 (physical) and 2 (MAC).

The FCC is concerned about locking down Layer 1 for RF compliance.  We’re concerned with keeping Layer 2 (and upwards) open for experimentation and improvement.

These are compatible goals, at the fundamental level, but there is a practical problem with existing implementations which mix the layers inappropriately.

 - Jonathan Morton

Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[dpreed]

As a software guy who can solder SMT chips and design PCBs, and a licensed amateur radio operator, let me add a couple observations.

The FCCs concern is not to lock up all software on  routers. All they call for is that at certification time and in users hands, radio emissions are restricted  to the rules of Part 15 operation.

So one can manufacture a router that can be certified, but with the ability to operate outside the legal 2.4 GHz channel and 5 GHz channels, and power limits and that quirky radar protection rule locked in via some difficult to break lock. It needn't be a perfect lock... If it requires the ability to solder or unsolder SMT chips, or spending $1000 for parts and services per device, that could satisfy. After all, just R-SMA connectors were sufficient for antenna mod prevention to be certified.

The WiFi protocols themselves are not a worry of the FCC at all. Modifying them in software is ok. Just the physical emissions spectrum must be certified not to be exceeded.

So as a practical matter, one could even satisfy this rule with an external filter and power limiter alone, except in part of the 5 GHz band where radios must turn off if a radar is detected by a specified algorithm.

That means that the radio software itself could be tasked with a software filter in the D/A converter that is burned into the chip, and not bypassable. If the update path requires a key that is secret, that should be enough, as key based updating is fine for all radios sold for other uses that use digital modulation using DSP.

So the problem is that 802.11 chips don't split out the two functions, making one hard to update.

Router vendors should like having this feature, in the standard chipsets, actually. Why? Because it makes their own products easier to certify, the same way a secure microkernel makes security properties easier to certify, in, say, L4. And because the rules about channels and power are different in each national market. Who wants to submit all their source code to each country's regulator?

So I personally would be frustrated that I would not be able to mod any router to operate under Ham rules(part 97 allows hams to operate in much of, but not all of, the two 802.11 bands with equipment we can make modify and operate with only self-certification, and the operator following Amateur operating rules, which are different, but allow 802.11 outside the unlicensed bands also, at higher power, too). But that matters less, because I can solder and validate my transmitters.

Perhaps there is common ground to be found. Dave Taht and I made the first move on this, with Dave's DC meeting with the FCC.

But it will take working with both the FCC and the chip vendors, and the home access point vendors with a common purpose and agenda. That agenda needs to be to find the minimum lock that will satisfy the FCC, and a sufficiently cheap implementation that, along with the cost saving on design certification, it is cheaper to make a router that is otherwise open, than to make one whose certification depends on review of all the code in the router.

This is a common design pattern. The DAA for phones is now purchasable as a single module, FCC precertified, so one can make any kind of cordless phone be certifiable, merely by using that part. That part is more expensive than one I could design myself, but it saves on certification cost, because the rest of the phone or modem doesnt need certification, so one can innovate.

Hope this helps. Happy to advise, and also help get the FCC on board when there is a need to. Before that, I'd suggest convo with Atheros, Broadcom, Marvell, etc. Or even Intel, which may want it for its WiFi embedded businesses.