critical WPA2 vulnerabilities afoot, see KRACK attacks (discussion @ /r/KRaCK, HN, /r/netsec, Slashdot)

CSR

From WikiDevi
Jump to: navigation, search

Timeline[edit]

  • Handset/mobile Wi-Fi chips & Wi-Fi IP was acquired by Samsung on 2012.
Automotive/IoT Wi-Fi chips remained at CSR.

Wi-Fi chips[edit]

UniFi family[edit]

UF1000 family (130nm)

  • UniFi UF1050 (aka "UniFi-1 Portable") - 802.11bg, SDIO/SPI
UniFi-1 Consumer - 802.11abg

UF6000 family (65nm)

  • CSR6026 - (UniFi-3) 802.11bgn (non HT40), host interfaces: 4-bit and 1-bit SDIO, SD SPI, CSPI; 65nm
  • CSR6027 - (UniFi-3) same as CSR6026, with SMS4 encryption hardware for WAPI security in China
  • CSR6028 (UF6028) - 802.11abgn
  • CSR6030 - (UniFi-4) 802.11bgn (non-HT40), host interfaces: 4-bit and 1-bit SDIO, SD SPI, CSPI; 65nm CMOS
  • CSR9000 - 802.11bgn (non HT40), bluetooth, FM RX/TX

(a)bgn[edit]

Chips used
Chipset
Interface PHY modes MIMO config Reference
designs
First seen
(FCC)
Notes Adapters ESystems pdf
CSR6026 SDIO 2.0 /
SPI / ...
bgn 1x2:1 0 devices 0 devices
CSR6027 SDIO 2.0 /
SPI / ...
bgn 1x2:1 HW SMS4 0 devices 0 devices
CSR6030 SDIO 2.0 /
SPI / ...
bgn 1x2:1 2013-03-06 HW SMS4 3 devices 0 devices

Driver[edit]

  • Driver for CSR60xx was remove from driver/staging after kernel 3.10
staging: csr: remove driver
This driver is not being updated as the specifications are not able to be gotten from CSR or anyone else. 
Without those, getting this driver into proper mergable shape is going to be impossible. 
So remove the driver from the tree.

If the specifications ever become available, this patch can be reverted and the driver fixed up properly.

Notes[edit]

  • Seems like CSR6030 and probably other previous chips use XAP Processors
  • Chip IDs extracted froms source code (looks like there is some confusing between branding and id in different parts of code):
...
    {FALSE, 0xf0ff, 0x1001, 0x01},          /* UF105x R01 */
    "UF105x",
    "UniFi-1",
...
    {FALSE, 0xf0ff, 0x2001, 0x02},          /* UF2... R02 */
    "UF2...",
    "UniFi-2",
...
    {FALSE, 0xf0ff, 0x3001, 0x02},          /* UF2... R03 */
    "UF2...",
    "UniFi-3",
...
    {FALSE, 0x00ff, 0x0022, 0x07},          /* UF60xx */
    "UF60xx",
    "UniFi-4",
...
    {FALSE, 0x00ff, 0x0023, 0x08},          /* UF.... */
    "UF....",
    "UF.... (5)",
...
 /* Device id */
#define SDIO_MANF_ID_CSR              0x032a

#define SDIO_CARD_ID_UNIFI_1          0x0001
#define SDIO_CARD_ID_UNIFI_2          0x0002
#define SDIO_CARD_ID_UNIFI_3          0x0007
#define SDIO_CARD_ID_UNIFI_4          0x0008
#define SDIO_CARD_ID_WIFI_HYDRA       0x0019
....
  • Extracts from "CSR101x Processor Core" discussion :
...
Nissim is correct that the PIO controller is an 8051 variant, which is an 8-bit processor. The core used for the host application is a lower power version of the core that is used in all of CSR's Bluetooth chips. The core has been modified slightly by CSR over time.
...
Jeff, Nissim is correct, the interface to the core and the peripherals is through the APIs that are documented and released as part of the xIDE tools. There's no commercially available tools that would allow you direct register level access to the underling RISC MCU. The MCU is a variant of XAP processor, which has been used in all CSR BlueCore and uEnergy devices. 
...

Patents[edit]