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

Re: [Cerowrt-devel] [Make-wifi-fast] [bufferbloat-fcc-discuss] 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: [Cerowrt-devel] [Make-wifi-fast] [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: [Cerowrt-devel] [Make-wifi-fast] [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: [Cerowrt-devel] [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

[David Lang]

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: [Cerowrt-devel] [Make-wifi-fast] [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