Blog BN′B

BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-8

saltuzzo | 12 January, 2018 14:58

Part 8: Embedded Processor Systems - System On a Chip (SoC), System In a Package (SIP)
The Core Processor of Embedded System Configurations

"We are drowning in information but starved in knowledge:" - John Naisbitt

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017)
Part 5 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued - The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 IPv4 & IPv6 Protocols - Network, Transport & Application Continued - The CRC-32 and Checksums (Nov 27, 2017)

Quick review to set the atmosphere for Part 8
From the previous Internet of Things Part-1 through Part- 7:

  • The atmosphere has been set for the Internet operation overview in parts 1 through 6.
  • The Ethernet physical protocol is the most used for communications over the Internet.
  • All communications throughout the Internet is performed as UserRouterInternet RoutersRouterUser
  • According to Netcraft there are over 1.8 billion websites active on the Internet that means over 3.6 billion routers minimum.
  • The Internet runs on Protocols through routers period.
  • Anyone with programming experience can write a protocol to access the Internet, just follow the protocol rules.
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.

What we want to cover in Part 8:
The high visibility issues concerning IoT devices are security, privacy and safety, hence: the primary motive for this series.  Security, privacy and safety should not be an after thought to be implemented after a crisis.  Our focus is to design in security, privacy and safety during the development process to insure the safety and security needs of the consumer be it commercial or industrial.

Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology,  Overview → Basic → Detailed  (OBD).   We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.  

The preliminary preview of the entire index is shown below and will be updated with links as we progress through the live series.  Comments are welcome both publicly and privately.  If you want to participate privately we will give acknowledge of your participation only by your permission.  We hope to share insight to address hardware and software solutions to the security, privacy and safety issues of IoT devices.  Parts of the embedded processor series will apply to both desktop, tablets as well as embedded IoT devices since they all share common elements of a CPU system.

Lets Get Started:

A Brief CPU Summary:
Central Processing Units are relatively fixed function devices and will only perform a fixed set of predefined instructions, a programmed group of these predefined instructions we label a programmed sequence.  The security and privacy challenge is how to prevent unwanted instruction execution to the CPU and the connected peripherals that are controlled by the CPU.  Access to these functions generally come from two sources, the OS (Operating System) where unwanted embedded code is has been hacked into a memory location  or the Basic I/O drivers that are hacked and used to access system functions to compromise the system, example- the Ethernet controller driver and/or application software allowing remote access.

In order to prevent such intrusions and unwanted code from being executed we have to understand the hardware, firmware and software details being used on the core IoT Platform.  When we analyze the embedded processor market place we see that there are really only a handful of different category's of processors and a large variation of licensing of the same or simular cores.  It would take a several hundred page book to cover all the processor differences and is really outside the scope of this series, however we will look at the major players of 32 bit CPU cores and start there which is well within our scope.  The major players are Intel®, AMD®, ARM®, NXP®, Microchip® and a smaller x86 player but still applicable is ZFMicro®.  There are three that are x86 based, Intel, AMD and ZFMicro.  NXP M&A acquired the original Motorola/freescale 68K CPU line; ARM Ltd stands alone and has licensed the technology to many players including all the above. Microchip is in a unique position due to the several M&A's of Atmel, SMSC and others.  The processor lines for these major players cover a broad spectrum of applications which make it difficult to select a processor that will allow full control to insure security and privacy at the core level.

All the major players compete with their own versions of an IDE (Integrated Development Environment) package and once selected you are basically locked into the selected manufacturer.  Using a third party package allows the fast turn of a product to market, however it does not guarantee privacy or security.  In order to insure security and privacy a detailed understanding and disclosure of the internals of the processor and software packages used are a must as well as the access to the core macro assembler to be able to incorporate a users integrated security methodology.  That being said we will now present the basics of CPU architectures in order to ask the right questions when performing our selection process.

The variations of processors today range from a dollar to hundreds of dollars depending on the bit size 8/16/32/64 bits and speed from a few KHz to GigaHertz as well as integrated peripheral functions.  The main function of the CPU is the programmability of a sequence of instructions fetched from a memory system to control a users process.  What makes CPU's different in the industry is the Micro-Coded ROM (MCR) which identifies the unique set of machine instructions for each CPU manufacturer.  If you change the Micro-Coded ROM you change the processor instruction set even though it still controls memory access and some logic functions it has a unique Macro-Assembler assigned to the processor.  Open source compilers like GCC have incorporated several families of processors into the compiler allowing the user to write code in C and compile it for several types of processors.

The remaining blocks of the CPU all perform similar functions, the memory controller and sequencer controls the access to memory locations and also controls the CPU jump tables.  The Central Process Controller or Instruction Process Decoder is what performs the instructions that is fetched from memory and keeps track of the programmed instructions with a program address counter.  The Execution Control Unit performs basic arithmetic and logic functions and incorporates a set of general purpose registers.  The remaining interfaces, the External Memory is to store the application program and other application parameters, the Data/Address BUS & Control are for adding user peripherals. The BUS control allows direct access to the memory controller for fast data transfers.  The final section the Power-Up Entry is a special one time execution during power-on that will allow the user to enter a unique memory address to start fetching instructions to execute.   To understand the core requirements of security one should understand how the internals of selected processor functions.  This introductory presentation will shed light on the complexities of designing an embedded system with the highest level of security possible from the core hardware to firmware to application software.

During the CPU presentation we will be creating a Key Security Requirements (KSR) list to be use for the Embedded Processor selection process.  It is important to keep in mind that all the security requirements may not be met with COTS (Commercial-Off-The-Shelf) embedded processor and may shed some light on the limitations of COTS embedded systems and the compromises that are being made to put a product on the market.

CPU (Central Processor Unit)  What They All Have In Common:
Embedded Processors today range from a simple CPU to incorporating a complete system on a chip making selection complex as wells implementing security policies for unwanted access and privacy.  To present the subject matter at the detail required for comprehensive design and security development guidelines of the Core IoT Platform this will be a continuation of multiple parts for the hardware.   Embedded processors and CPU have many features that allow the designer to incorporate security policies in hardware/firmware to control all access to the platform.  Some System on a Chip (SoC) blocks are frozen designs and do not allow the implementation of security policies at the core CPU level.

The roadmap for Intel®, AMD®, Microchip®, NXP® and other manufacturers of embedded processors are very well documented leading us from a 4 bit microprocessor (historical read Intel 4004 microprocessor) up to the 64 bit processor families on the market today.  Our intent here is to present the core functionality of all Central Processing Units to understand how we will implement the security policies for the Core IoT Platform.  The CPU is just a programmable block of logic gates that allow the user to program a set of instructions designed into the processor unit connecting real world peripherals, transfer data as well as perform arithmetic and logical computations on digital data.

When we perform a Internet search on Embedded Processors we get inundated with millions of hits on a variety of devices from Single Board Computers (SBC) to general purpose MIPS, ARM, etc. type micro controllers CPU and other names associated to the programmable device.  These embedded systems are a finished product that the manufacturer supplies with a associated IDE (Integrated Development Environment) package to get a product on the market fast.  Putting a product on the market with canned IDE's without knowing or understanding the software and the amount of control questions the vulnerabilities of the IDE for hackers etc.  The better we understand the device we are programming the more confidence we will have in securing the device for our application.  With that said, lets start at the core of the Embedded system, the Central Processing Unit.  Figures 8.0 is a functional block diagram of a typical CPU.  When we look at Figure 8.0 we see that the Instruction Process Logic Block is the central controlling core of the processing unit and everything else are "internal peripherals" that are used as support interface devices for the core process block.  The real world connections for the CPU are just a interconnecting buffer block to form a protective communications mechanism to the internal BUS & Control.  All central processing units have a few section in common, they all have:

An Instruction Process Logic Block

     • Instruction Fetch Queue Buffer

     • An Instruction Process Decoder to execute a series of programmed instructions stored at specific memory locations.

     • A Micro-Coded ROM (MICR) Contains Machine Instruction Set - Registered, Patented or Trademarked.

     • An Execution Control Unit - AKA - Arithmetic Logic Unit - performs data and logic manipulation

A Memory Access Controller, AKA, Memory Management Unit (MMU) - logic to fetch and store data to memory addresses.

A Memory Data/Address Interface Control BUS to attach External Memory, RAM, EEPROM, DRAM etc.

A Set of General Purpose Registers - usually eight registers plus a Stack, Status, Program & Control Register

A Small Internal RAM Buffer for general purpose registers for the Execution Control Unit

A External Data /Address Interface BUS to transfer data to/from the CPU internal logic

A Clock interface controller for CPU process timing.

A Power On Sequence (POS) unique to the CPU core to start executing instructions from a defined memory location.

CPU_BLOCK
Figure 8.0  Typical CPU Functional Block Diagram

Core Functions of the Central Processor Unit Architecture:
Central Processing Units have evolved over the years to a plug and play architecture that includes a variety of peripherals that have been incorporated into a single chip and acquired the labels of System on a Chip (SoC) or System in a Package (SIP) and of course the notorious Embedded Processor.  From the CPU functional block diagram shown in Figure 8.0 the core to the CPU is the Instruction Process Logic Block that determines the type of CPU and the registered and/or patented instruction set like the x86 instruction set by Intel Corporation.  

Today there are peripherals that include an embedded processor to communicate complex instructions to reduce the instructions required to communicate when connected to an external main CPU that controls the system. This adds a new challenge to the security of the system since the peripheral today does not necessarily need the CPU to communicate, it just needs to have access to the local BUS.  Some of the more advanced intelligent peripherals are easily hacked today due to the vulnerability of the BUS access and the Internet controller used to communicate through the Internet, hence, The Reaper IoT Botnets Infects Millions of Networks is just the beginning of the security and privacy challenges. The challenge today is to incorporate security in all part of the designs especially in the BUS protocols in order to prevent unwanted intrusions and hidden root kits.

From Figure 8.0 which defines the Central Processor Core functions we may then define anything outside the core as a peripheral whether the peripheral function remains inside the actual chip or connected to the external pins of the chip.  If outside access is allowed to the CPU then full control is obtained over the IoT platform and so enters the Security, Privacy & Safety Policies to insure the CPU performs its programmed sequences without interference.  It is important that we understand all vulnerabilities of the selected CPU core,  how it communicates with the internal bus to the real world external bus, so enters the cliché "If you don't know where you are going any BUS will take you there" and the adventure begins.  The Memory Access Controller is considered a peripheral to connect external memory to the CPU core in order to execute instructions.  It is half of the memory interface peripheral and is one of the vulnerabilities that we enter as part of the KSR list.  Some embedded processor SoC include both EEPROM and RAM to address simple controllers, however for our Core IoT Platform we would like much more control that a fixed embedded system.

Instruction Process Logic Block
This is the primary mechanism that allows the execution of sequential programmed instructions from memory.  The Instruction Process Block is essentially the CPU itself, the remaining blocks are actual peripherals that are attached to the Internal BUS & Control lines.  The real world only sees the Real world Interface lines to keep the internal execution of instructions private.  Since programmed instructions have to be fetched from memory the security issue here is how the memory fetch is protected from interception and isolated from the real world.  The initialization of the integrated system to a known state prior to loading the OS or any other application is required, vulnerabilities are probable during this Power-On-Sequence-Test (POST) which is prevalent in all CPU's and attached peripherals due to the fact that it is a fixed process that is well documented for all to use.  This is part of the "Secure Boot" processes which we will cover later in the series after the selection process, however it will be added to the KSR list to insure the hardware is capable of securing this process in some way.

Instruction Process Decoder (IPD)
The Instruction Process Decoder performs the task of decoding the instruction type and length that has been fetched from the Instruction Queue.  Instructions generally go through a setup process in the IPD to determine the type of instruction before being sent to the Micro-Coded ROM that performs the unique sequence of steps for the fetched instruction.  If the instruction requires the use of the Execution Control Unit (ECU) then it is directed to that unit and the ECU performs the proper sequence of operations to complete the instruction.  If the instruction is an immediate instruction like jump to memory address 0x1234abcd and continue execution then the instruction is directed to the Immediate Control Sequencer that performs simple instructions sequences hence, Jump, Loop, Move Immediate or other immediate instructions.  We will address CPU instruction sets in the programming part of the series.  If the instruction is not immediate then it is transferred to the Micro-Coded ROM for continued processing.  If the instruction requires the ECU to perform complex logic etc. then it is transferred and the selected set of steps are performed to complete the instruction.

From a security point of view the IPD should not be accessible to the outside world and it should not be modifiable in any way.  If you do a bit of research there are some processors that allow micro-code updates when loading specific Operating Systems.  These patches are generally a firmware patch and linked to other (Basic Input/Output System) BIOS instructions toptimize the processor for the selected OS.  Older processors before 2007 require the operating system to control all the BIOS functions as part of the OS and do not use the firmware BIOS except for loading the OS at POST, this is not the case today which we will cover as we progress through the series.

Intel processors incorporate a SMM (System Management Mode) controller to hold the setup of system parameters for access to the required core functions that the OS has privilege to.  Initially, System Management Mode was used for implementing Advanced Power Management (APM) features. However, over time, some BIOS manufacturers have relied on SMM for other functionality like making a USB keyboard work in Legacy BIOS mode

Some uses of the System Management Mode are:

  • Handle system events like memory or chipset errors
  • Manage system safety functions, such as shutdown on high CPU temperature and turning the fans on and off
  • Security functions, such as flash device lock down require SMM support on some chipsets
  • Deeper sleep power management support on Intel systems
  • Control power management operations, such as managing the voltage regulator modules
  • Emulate motherboard hardware that is unimplemented or buggy
  • Emulate a PS/2 mouse and/or keyboard by converting the messages from USB versions of those peripherals to the messages that would have been generated had PS/2 versions of such hardware been connected (often referred to as USB legacy support)[6]
  • Centralize system configuration, such as on Toshiba and IBM notebook computers
  • Emulate or forward calls to a Trusted Platform Module (TPM)[7]

System Management Mode can also be abused to run high-privileged rootkits, as demonstrated at Black Hat 2008 and 2015.  Sony BMG copy protection rootkit scandal in 2005 is just one example and robbing banks is still against the law but still happens, hackers are always tempted and execute these kits..

Types of Processors, MIPS, RISC, CISC, Pipeline, Clocked.
There are different type of Execution Control Units that perform complex steps to complete the requested instruction.  Instruction sequences require several clock cycles to complete.  To reduce the number of clock cycles in several instructions block of pipeline logic are designed in to the ECU to reduce the number of clocks.  These processors have been given the name RISC (Reduced Instructions Set Computer). This does not mean that there are fewer instructions, in fact there are more instructions that perform many more functions, it does mean that the way instructions are processed has been reduced to the minimum number of clock cycles allowing faster processing.  From Wikipedia - "RISC ISAs include ARC, Alpha, Am29000, ARM, Atmel AVR, Blackfin, i860, i960, M88000, MIPS, PA-RISC, Power ISA (including PowerPC), RISC-V, SuperH, and SPARC. In the 21st century, the use of ARM architecture processors in smartphones and tablet computers such as the iPad and Android devices provided a wide user base for RISC-based systems. RISC processors are also used in supercomputers such as the K computer, the fastest on the TOP500 list in 2011, second at the 2012 list, and fourth at the 2013 list,[3][4] and Sequoia, the fastest in 2012 and third in the 2013 list."

Processors that are not RISC based will handle completes functions via a series of steps in sequence and are called CISC (Complex Instruction Set Computers) such as Digital Equipment PD -11 and VAX systems that incorporated a Polynomial evaluation instruction set based on CISC Instruction Set Architecture as well as several other complex instructions.  The Intel IA32, IA64, x86 product line, NXP 68000 are all CISC architecture processors.

The summary of RISC vs CISC is that the CISC processor performs a function in hardware such as a multiply Reg0, Reg1 and moves the results to Reg0 and only requires one line of code as MULT A, B and in C code,  A=A*B.  The MCR only needs one word for the entire operation.  The RISC processor performs this same Multiply in several steps such as:

    MOV Reg0, A
    MOV Reg1, B
    MULT A, B
    MOV Reg0, A

It is obvious that more memory and more clock cycles are required as well as more compile time for the same function.  However Even though it looks like a single operand there are still clock cycles involved.  Also in a CISC based system only the result is saved and if the B has to be used again it has to be reloaded where as in a RISC based B is still in the register.   We will come back to this at a later time when we get into the processor selection and security.  When we look at the available FPGAs (Field Programmable Gate Arrays) today it allows us to apply both worlds to obtain greater performance.  We will cover FPGA's and CPLD's (Complex Programmable Logic Device)  when we present the peripheral interface section of the series, keep in mind that Intel Corporation purchased Altera Corporation so new advancements with processor technology and FPGA's falls in the probability arena.

The Instruction Process Decoder (IPD) is a key mechanism that determines the complexity of a processor core.  Every manufacture of processors be it a stand alone CPU or embedded surrounded by a host of peripherals will incorporate a Instruction Process Decoder.  It is this decoder logic that makes the block of logic a processor due to the fact that this IPD allows a sequence of instructions to be performed in a unique sequence of steps.  The used within the IPD determines the type of Instruction Step Architecture for the processor, simply presented there are generally two type of  architecture that applies to processors, the first is Memory Mapped I/O architecture and the second is Dedicated I/O architecture.  Both types of architecture incorporate a memory access architecture that may be used for I/O peripherals, however the dedicated I/O incorporates an independent I/O instruction set that is separate from the typical fetch and store memory functions.  In the Dedicated I/O architecture there is usually a separate set of address lines to be used for peripherals and communicate through a selected register set to identify the I/O physical address to send the data to.  In a Memory Mapped I/O users may treat I/O Peripherals just like a memory location with all the memory instruction set functions within the processor.  The Intel x86 processor line has a separate I/O instruction set and uses the first 16 bits of the address bus as a shared memory and I/O since only one of the two functions, memory or I/O may be accessed at a time.  The NXP 68000 set of processors use the Memory Address/Data BUS as both for peripheral I/O and memory access. Both type of architecture have their pro's and con's.

All processor instructions require clock cycles to be implemented, the IPD is simply a sequencer that when input with a specific bit pattern will perform a specific sequence on the processor core.  Since all processor instructions that are not I/O peripheral are of a fixed nature the exact timing for each instruction may be calculated by the number of clock cycles it takes and the time period of the clock executing the instruction.  This is an important part of the processor and is added to the KSR list for the processor selection.  I/O timing is dependent on the real world inputs and may vary when waiting for responses to continue and are calculated based on the peripheral features and the application.

Pipeline processors that include pipeline instruction logic still require clocks to function as they require some type of status flag setup as well as results to be placed somewhere.  Pipeline instructions have the given of a fixed time to execute since it is based on two controllable parameters, the clock period and the propagation delays through the pipeline logic.  This gives them an advantage of clocked instruction sequences especially if the clock is much slower than the pipeline execution time of the instruction.  Pipeline instructions are less likely to be interrupted during the cycle since it is a fixed hardware function where as a clocked instruction may be interrupted in the middle of its process pushing the return state on the stack which requires more clocks then start executing the interrupt handling process until the interruption is completed, then returning to the interrupted instruction by popping the return state off the stack and continuing the instruction.  We will address processor interrupts and the security policies required to handle them later in the series.

Micro-Coded ROM (MCR) for the unique registered, patented or trademarked instruction set.
The Micro-Coded ROM contains the processor "machine" binary coded instruction set which is a unique set of bit patterns used to select a unique set of steps to complete an instruction process.  The MCR is only the machine instruction identifier that triggers a group of unique steps to complete the requested instruction.  This is accomplished by the "Instruction Control Sequencer" which contains all the sequences required for the Instruction Set Architecture of the CPU.  The MCR and the IPD are integrated logic blocks that function together to direct the path for the type of instruction and how it is sequenced.  Instruction are separated into categories to organize to optimize the performance and to direct the sequence of steps and data flow required for each category.

  • General Data Transfer
  • Arithmetic
  • Logic
  • Control Transfer
  • Conditional Jumps
  • Conditional Byte Set
  • Interrupt Instructions
  • Processor Control Instructions
  • Memory Segment Control - setup with the Memory Management Unit
  • Processor Status Flag Register

In order to have feedback on an instructions process in real time a set of FLAG bits are used by the process block to identify the final state of the last instruction.  Flags are set during the execution of instructions to determine the state or results of the instruction. The assigned bit position is specific to the processor design. Figure 8.1 shows a Typical; Intel Instruction Set Architecture Flag Bit Assignments.  Generally there are three classes of FLAG bits, Status, Control and System. Example: if we compare two registers data and they are equal the ZF (Zero Flag) is set to 0.

Intel_EFLAGS
Figure 8.1  Typical Intel Instruction Set Architecture Flag Bit Assignment.

It is not uncommon that a large number of instructions are designed into the hardware processor.  The MCR, IPD along with the Sequencer interact to control the step sequence for all the defined instructions.  There is no magic to a processor design just a large block of logic gates to control the 1's and 0's.  If the instruction is a pipeline type instruction then it is started with a single clock cycle and the data is pipelined through the fixed logic for the process. There will always be a debate on which is better, pipeline logic or clocked logic blocks, regardless there are applications that are better for each.  The clarity will present itself when we address security and peripheral communications in the sections that follow.  CPU's that incorporate a Reduced Instruction Set methodology are directed to a fixed logic function generally a pipeline logic set that makes up the Instruction Set Architecture (ISA) that requires less clock cycles to complete.

Instruction Control Sequencer - Loop & Jump Control:
The Instruction Control Sequencer handles the sequence of steps for each instruction and is generally clocked step by step in order to complete the instruction.  For simple jump direct instructions the program counter is loaded with the new jump address and starts instruction fetches and executes from the new address in memory.  For conditional branches the offset is calculated from the current program counter and either added or subtracted from the current program counter.  For other complex functions that require memory to memory and register assignments the sequencer and the Execution Control unit perform in unison to load / store registers and execute the instruction.  Pipeline logic and clocked logic are in both the Sequencer and ECU to optimize performance, this is the best of both RISC and CISC architecture.  

Execution Control Unit (ECU) - AKA - Arithmetic Logic Unit (ALU)
The Execution Control Unit (ECU) performs all the general purpose integer logic and arithmetic functions  are executed like Add, Subtract, XOR, NOT, OR, AND, Multiply, Divide, Shift Right/Left.  Many of the CPU's today incorporate integer Multiply / Divide instructions and vary depending on the processor type as previously mentioned.  This allows the programmer to incorporate an integer based cryptography for data integrity and a simple level of security.  Integer based cryptography is mainly for data transfer integrity for packet switched networks.  The ECU has its own internal operation registers that are linked to the general purpose register set to complete the requested instruction.  We will address this as we develop the IoT Platform.  Today the CPU is complimented with programmable logic arrays that extend the functionality of the integer ECU/ALU in such that peripheral control and customized processes algorithms are interfaced to the CPU's  integer based Arithmetic Logic Unit.  

Instrucion Process Logic Block Summary:
The Instruction Process Logic Block is the core of the CPU that is surrounded by support logic and by nature core instructions are performed in a single thread single instruction at a time.  Over the evolution of processor development the individual logic blocks were designed to be independent with their own clock source and pipeline architecture.   The core logic block independence allows faster seamless execution of instructions by starting the next instruction while the execution of the previous instruction is finishing up.  These independent function blocks do not change the single thread limitations of the core CPU blocks regardless of the number of Instruction Process Logic Block (cores) incorporated in the system that share the support logic, hence the introduction of the multi-core processor.

One of the areas we did not cover yet is the interrupt architecture of the processor core. Interrupts are a independent function that are usually integrated into the core instruction architecture that allow an interruption of the instruction process usually at the end of the instruction.  The architecture is such that it uses a memory pointer.  This pointer is called the Stack and is a small contiguous block of memory specifically used for interrupts.  When an interrupt happens the state of the core is pushed on the stack to be used for returning to the interrupted process; we will return to interrupts in the Memory section that follows.

Memory & Memory Access Controllers (MAC):
Memory Management Unit (MMU) & Memory Protection Unit (MPU):
Nothing happens without memory whether it be static, dynamic or Read Only memory, "no memory - no programmed instructions".  Controlling memory access is the beginning of securing the process from unwanted intrusions; "simple statement difficult challenge to implement".  Simple processors that incorporate simple interface control logic have little or no protection from stopping memory hacking from changing the process.  Memory hacking has two categories, internal and external, internal hacking requires the hacker to have physical access to the system, external hacking is performed remotely by uploading hacking code or acquiring remote access through a remote port on the system. That the easy part - the difficult part is hacking the processor to execute your code. Regardless of the method memory has to be loaded with valid code to be executed by the processor.

Allocating memory space is critical to a secure user process as well as a secure operating system, so before we get into the memory allocation lets look at the actual hardware that is used to communicate wit the memory.  Memory chips handle access by a selecting an address the contains a cell of data that data is either placed on the memory data bus or there is data on the memory databus to be stored at that address.  A direct read or write is the fastest memory cycle that exists in any processor block, delays enter the picture when we add address translation and protection to the simple memory access. Enter the MMU or MPU blocks of logic as well as some intelligent for encryption to determine if the address being accessed is assigned to the process being executed along with several other conditions.  I would take a guess that many of you reading this blog that you have heard of Spectre and Meltdown, (not the movies 2015, 2004),  however they are both disaster movies as is the conditions.  These two vulnerabilities have to do with memory access from an unwanted source to intercept the process instructions to gain access to the system. This is both a hardware and software issue so we will cover the hardware side now and when we get to the security software part of the series we will address this in detail..

Regardless of the memory type be it Static RAM or Dynamic RAM the access still has to be protected from unwanted intrusions, a challenge that has been here from the beginning.  There are basically two categories of memory Volatile and Non-Volatile, Volatile is memory that looses its data when the power is turned off and obviously Non-Volatile retains it data when the power is turned off.   There are basically three types of volatile Random Access Memory today, Static (SRAM), Dynamic (DRAM) and Pseudostatic (PSRAM).  Static (SRAM) does not require any refresh to maintain its memory content, however, the cost is chip density and reduced memory size.  Dynamic (DRAM) does require the cells to be refreshed (rewriting the cell data) periodically in order to maintain data storage and requires a special DRAM controller that shares real world data access with the refresh cycle.  A new kid on the block is Pseudostatic (PSRAM) which is dynamic RAM with a build in refresh that functions like SRAM but a bit slower speeds to handle the refresh and as with the DRAM controller requires a configuration process to maintain the thermals and access timing within the chip.

Within the volatile SRAM type there is some sub-types, Conventional memory and Content Addressable Memory (CAM), Conventional RAM is arranged as a single address to a single data word, Conventional RAM is present in all the desktops, tablets, smartphone's, 98% of the servers in the cloud, one address location one data location.  Content Addressable Memory (CAM) an older technology that has been around for over 60 years but very little has been discussed or applied using this category in today's processors.  There are multiple patents on CAM and applications filed from 1970 through 2012 for various versions and applications using CAM from companies like IBM®, AMD®, IDT®, TI® and many others to get their dominance in the market.  Content Addressable Memory is primarily used with Content Addressable Parallel Processors (CAPP), however it does not have to be applied to parallel processors in general.  This technology is very applicable to Artificial Intelligent since search compare and execute functions are a major part of AI processing and CAPP give higher speed and functionality than conventional processor systems.  CAM is generally related to Content Addressable Parallel Processors (CAPP) a subject we will address at another time since it is beyond the scope of this project at this time.

The memory controller handles access to the internals of the CPU; since instructions cannot be executed without memory the CPU issues a fetch instruction requests from the Memory access controller to start an instruction processes from a memory address.  Memory access is generally defined with the CPU specifications and features in order to incorporate security policies.  There are simple Memory Access Controllers that just handle a large linear array of memory without any special features, then there are the Memory Management Units which incorporate memory segmentation and protection, however they also are integrated with other blocks of the CPU architecture.  The MAC, MMU and MPU are just controllers that define memory access requirements attached to the CPU, they require some type of physical memory attached to them to function.

Memory access is a major security issue, how it is connected to the Core CPU and how it is allocated, Figure 8.2 shows the functional blocks of a typical memory access architecture connected to the core CPU that consists of a Dynamic Random Access Controller, DRAM, EEPROM and SRAM.  Since nothing happens without memory it stands to reason that hackers want access to plant virus, worms, root kits and other codes to obtain access which makes the memory hardware a high profile part of the security architecture.

FIGURE_MMUCtrlBlock
Figure 8.2  Typical Hardware Block, DRAM, EEPROM, SRAM & I/O

The simple Memory Access Controller is just a buffer cache that allows access to the memory array in a linear form from address 0000 to address nnnn, just one big linear array of memory addresses.  This is the most vulnerable memory access since there is no protection of data or program code regardless of where it is placed in memory and accessed without any fault or protection.  From Figure 8.2 we see that the MMU or MPU controls all aspects of memory access that includes Direct Memory Access from I/O devices which is a hardware security vulnerability that we will address in more detail as we progress through the series.  This is a major concern and noted in the KSR list.

Memory Management Unit (MMU) is a controller that intercepts "ALL" memory access.  Generally the common definition is that the MMU handles accesses to memory requests by the CPU, however that is not totally true.  For devices that incorporate DMA (Direct memory Access) hardware the MMU also handles this function and is termed the I/O MMU.  This does create security vulnerabilities since the direct writing to memory from a device may also put code as well as data in memory and if the code is in a page that is legal to the current program it may be executed   These devices are typically USB ports, Firewire, or storage type peripherals.  MMU's primary function is to control memory segmentation and paging, translate virtual memory to physical memory accesses and handle memory cache, protection and bus arbitration.  Hence: the MMU is just an add-on to the CPU to create a complete CPU (Central Processing Unit).  Unwanted access to the MMU and Memory is one of the root security vulnerabilities that has existed since its conception and still exists today.

The pros are paging, segmentation, virtual memory to physical memory,  security with a question mark, by intercepting all memory transactions through a TLB (Translation Lookaside Buffer) to insure multiple processes are directed to the CPU accordingly.  This does slow down the access since it adds additional clock cycles to perform the translation. The MMU segmentation protection methodology allows the memory to be partitioned and controlled into Kernal (trusted segment), code or program Protected segment, Supervisory and Data segment groups that add security to the processor system.  MMU's are incorporated into the majority of 32 bit processors available to the COTS (Commercial-Off-The-Shelf) market today.  We will research the market place for both simple processors without MMU that such that the MMU may be added as a peripheral for comparison as the series progresses.  Intel incorporated MMU as been part of the processor since the 80286 release and since then ARM, AMD, MIPS and other COTS embedded processors incorporate MMU's.

What is incorporated is an interrupt function that is in all CPUs today.  The interrupt sequence allows the core CPU to share time with other processes by saving the complete state of the core CPU along with a return location to restore the previous state and continue processing.  Each manufacturer specifies how their interrupt functions processes information to accomplish the switching.  Some use an interrupt controller that allows the fetching of a block of addresses defined as the interrupt vectors that hold pointers to processes to be executed.  Those that do not use an interrupt controller are limited to only a single interrupt along with an interrupt handler that must poll all devices to determine which one caused the interrupt.  Time sharing is an important feature when selecting a single processor core system since it will determine the overall program efficiency when several peripherals are attached.  This is also an issue with multi-core chips as well since each processor runs independently and shares memory.   Number of Processors and Interrupt capabilities will be put on the KSR list as well and does create a major security vulnerability if not handled properly.

Interrupts are a integral part of the CPU that allows the CPU to multi-task by interrupting a current process and jumping to another processor then returning when the interrupted process is completed.  CPU architectures generally have a single interrupt process that requires an external interrupt controller allowing management of several interrupt lines connected to peripherals that are assigned unique memory address locations that contain pointer to the interrupt handler code.  We will cover interrupt structures as we proceed through the series.  From the Instruction Process Logic Block can conclude that instructions are single thread and require a memory fetch request for the instruction to be executed which point to the memory as a key security vulnerability.

Each of the user defined memory segments have access control parameters to prevent any unwanted access.  Any intrusion to protected areas creates a page fault interrupt to a jump location that contains the error handling code to be executed sending a notification or correcting the intrusion.  We will cover Interrupt control processes in the Interface section as the series progresses.  The Memory Management Units control registers are generally integrated into the CPU's core control for better security such as in the Intel IA32, IA64 product lines.

Memory Protection Unit (MPU)
The MPU is an MMU with limited functionality that only allows memory protection for parts of the physical memory array, does not have virtual memory functionality.  MPU's do not have cache control, bank switching and bus arbitration which is necessary for systems that perform multi-tasking and with multiple-processors.  Many of the embedded processors incorporate an MPU because of logic array constraints by design.  MPU logic has less latency delays because of its smaller logic designs and less configuration parameters, both MPU has less segmentation and paging capability than the big brother MMU.

MMU, MPU Summary:
The MMU's MPU's are considered peripherals because their direction is from user controlled status & control registers and require a setup process.  If the MMU is part of the Internal BUS then we have to look at how it is accessed via the external bus and how does direct memory access (DMA) is connected as well as the DMA protection features.  

OK, now time to bring up interrupts again.   Now that we have all this memory access control, what happens if an unwanted access happens as it does in multi-tasking and multi-processor systems.  The answer is a page fault interrupt is generated and there is a separate stack of contiguous memory outside the normal OS that points to a block of code that handles the page fault interrupt.  A few conditions that are tested and some internal fixes are automatically fixed and process is resumed. Some errors halt the system and some errors just notify the user with some options.  Hackers are constantly playing with code injection and getting page faults to find back doors to the OS.  In a multii-tasking application the task manager in the MMU handles the segmentation and virtual memory allocation along with all the page/bank switching to save each tasks position in the task scheduler.

The interrupt sequence allows the "single thread" core CPU to share time with other processes by saving the complete state of the core CPU along with the tasks return location to restore the previous state and continue processing.  Each manufacturer specifies how their interrupt function processes information to accomplish the switching.  Some use an interrupt controller that allows the fetching of a block of addresses defined as the interrupt vectors that hold pointers to processes to be executed.  Those that do not use an interrupt controller are limited to only a single interrupt along with an interrupt handler that must poll all devices to determine which one caused the interrupt.  Time sharing is an important feature when selecting a single processor core system since it will determine the overall program efficiency when several peripherals are attached.  This is also an issue with multi-core chips as well since each processor runs independently and shares memory.   Number of Processors and Interrupt capabilities will be put on the KSR list as well and does create a major security vulnerability if not handled properly.

Task handlers require the management of all the tasks opened for processing as well as supplying a separate interrupt structure for each task, this is where bank/page switching and virtual segmentation is used for management both locally and globally.  CPU architectures generally have a single interrupt process that jumps to a specific location either pointed to by an internal CPU register set to a memory address.  Some cores require the use of an external interrupt controller allowing management of several interrupt lines connected to peripherals that are assigned unique memory address locations that contain pointer to the interrupt handler code.  We will cover interrupt structures as we proceed through the series.  From the Instruction Process Logic Block can conclude that instructions are single thread and require a memory fetch request for the instruction to be executed which point to the memory as a key security vulnerability.  Generally interrupt handlers are accessed indirectly from a contiguous block of memory specifically assigned by the core processor and integrated with an interrupt controller.

If access to the memory is permitted while the CPU is off executing tasks then all activity in the Core IoT Platform may be monitored, intercepted and controlled.  Therefore controlling access to this section of the processor is noted in the KSR list to address during the design.  Several embedded processor chips incorporate the Memory Management Unit (MMU) as part of the Memory Access Controller.  

The majority of embedded platforms work in the linear memory address mode and segmentation is generally not implemented probably for simplicity for those applications that do not require an OS to function.  Another major of concern for the MMY is the connection of a Direct Memory Access Controller (DMA) which also a direct access to memory without and CPU intervention.  This is a major security concern since DMA controllers transfer data in both directions at very high speeds to/from the real world BUS interface. Intel incorporated DMA controllers in the original 8088 PC and used it for all disc transfers for the speed.  When the 80286 was introduced the disk controller was redesigned and DMA was not used since the 80286 was faster by transferring direct.  Direct Memory Access for devices like USB, Firewire and other streaming devices present a security risk since they access a block of defined memory without CPU intervention. Memory access is a critical security vulnerability since it contains everything that is happening in the core system therefore it is on the top level KSR list of concerns.

External BUS Interface - Data /Address  & Control for External Devices & Memory
The External BUS Interface logic allows both memory and devices to be interfaced to the real world.  The BUS Control lines separate the BUS transactions for DMA (Direct Memory Access). Memory Mapped I/O this is also the device I/O BUS and the Address of the I/O devoice is decided by the user, usually at the top of the memory less the memory size it takes to boot the system up.  Memory Mapped I/O type processors require that the memory map be organized in order to prevent overlaps of program, data and I/O addressing.   If  DRAM is being incorporated into the design then a separate DRAM controller is attached as a peripheral device.  DRAM controllers are usually part of an embedded processor configuration however many are incorporated via an PAY externally.  Today there exists PSRAM (Pseudo Static Random Access Memory) that contains a self-refresh DRAM array that allows greater density than normal SRAM.  4Mx16 a standard size and it performs just like a real SRAM but with slightly slower speeds.  The one we use in the lab for testing and developing has a 55ns asychronous R/W access time  Dynamic RAM is still the best choice when looking at 1Gig to 4Gig RAM for the system.  Some Embedded Processor SoC only allow a few address lines to be brought out to the pins therefore limiting the performance requirements of the processor externally and will be part of the KSR list for review during the selection processor.

I/O Interface Control BUS:
The I/O Control BUS is dependent of the processor type as we discussed previously.  If the CPU type is a Memory-Mapped I/O then this block would be left out since all I/O device communications is the same as memory I/O.  If the CPU is a dedicated I/O type then a separate I/O address and I/O databus would be part of the chip.  Generally Dedicated I/O type CPUs use a single databus and separate address and control lines.  The Intel processor line uses the first 16 bits of the address lines and separate control lines to load a device address and the data lines are shared system wide.  The data lines are generally buffered if DRAM is used since it requires a DRAM controller to refresh the memory.  The NXP 68K series are Memory-Mapped-I/O CPU's, the Intel x86 series processors are Dedicated I/O type CPU's.  Memory mapped I/O may be controlled by the MMU or MPU allowing better segmeted control of device data, however the dedicated locations also introduce security vulnerabilities we will cover as we progress in the series.

Clock Interface Controller (CIC) for CPU process timing
The Clock Interface Control handles all the clock requirements of the integrated system.  The CIC handles synchronization for all peripherals, internal and external, insuring that there are unique time sequences for each instruction process and data transfer throughout the architecture.  The CIC also handles cascading multiple processors and systems by allowing external clock inputs to synchronize cascaded processors.  This is different from Hyper-threading as within the Intel x86 processor series, cascading embedded processors externally creates a fully independent multi-processor configuration.  On our core platform we will review the concept of adding a second processor for the control, security and privacy functions.  The CIC is dictated by the processor manufacturer so we will review the specifications as we add this to the KSR list.

Power On Sequence (POS) Initialization Test unique to the CPU core to start executing instructions from a defined memory location.
The POS is one of the critical vulnerabilities of all processor controlled systems. If one can intercept the POS it has the potential of adding code and changing the setups protected area to accept this code. This is called installing a root system that can be anything from a simple keyboard monitor to a worm or virus that infects the entire system.  we will address this in more detail as we get into the software and power on security of the IoT Platform.

At this point we will end this part and cover the remaining part of the CPU core system.

SUMMARY:
The majority of vulnerabilities are caused from poor hardware and software designs that have vulnerabilities which allow unwanted code to be injected via some remote or local mechanism.  Understanding the core processor hardware and its peripherals is a good place to start to design in security during development,  The Embedded process part of the series is intended to be an overview prior to the actual development of the Core IoT Platform in order to design in securiyt and privacy policies.  We will cover hardware vulnerability areas during the actual hardware development.   Security can not be an after-thought after the development will always create vulnerabilities that will give a back door for unwanted intrusion to the system.  Today the majority of hacks come from poor security behavior through e-mails and documents that are attached that contain malicious code embedded in the attachments.  Websites that are poorly written have hacked code to access your system remotely through various codes written in several webbased languages that are easily executed on a desktop or server.  We will cover these vulnerabilities in detail in the software sections of the series.

This part of the series is just the beginning and is meant to be an outline for reference.  The embedded processor world is expanding at such a rate that security is be ing bypassed for the fastest to market at the expense of the publics privacy and safety.


Reference Links for Part 8:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Reference documents for continued reading are listed below:

[PDF] Vertual Memory and Memory Management - Angelos Stavrou, George mason University


Part 9+  "Preliminary Outline" Embedded Processor Systesm: Continued

  • Power On Sequence Initialization Ttest - AKA (POST)
  • Using external FPGAs, CPLDs for Power On Initialization
  • Introduce a security policy right at the beginning of the design process
  • How much control do we really have?
  • Security protocols and how they play a roll in initialization.
  • Selection of the Core IoT Platform Processor(s) and peripherals.
  • Embedded Processor Technology, CPU Chips Technology,  FPGA System on a Chip - How much control do we really have
  • Types of processors, MIPS, RISC, CISC, Single Core, Multi-core etc.
  • Boot up Initialization processes and Vulnerabilities using embedded processors and independent CPU chips.
  • Secure Boot processes and Embedded Cryptographic Firmware Engines - A Closer Look.
  • An introduction to support chips for processors,  NorthBridge (MCH, GMCH) /  SouthBridge support chips (ICH),  SoC Platform Controller Hub
  • Security protocols and how they play a roll in initialization.
  • Key Security Requirements (KSR) list review
  • Selection of the Core IoT Platform Processor(s) and peripherals.
  • Reference Links

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-8  Embedded Processor Systems: The Core Processor Of Embedded System Configurations- (January 12, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=13&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-8 Embedded Processor Systems: <i>(Jan 12, 2018)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-7

saltuzzo | 23 November, 2017 06:56

Part 7: IPv4, IPv6, Protocols - Network, Transport & Application: Continued
The Ethernet Protocol(s) CRC-32 and Checksums

Design is a way of life, a point of view.  It involves the whole complex of visual communications: talent, creative ability, manual skill, and technical knowledge.  Aesthetics and economics, technology and psychology are intrinsically related to the process. - Paul Rand

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017)
Part 5 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued - The Ethernet Protocol(s) (Sept 21, 2017)

Quick review to set the atmosphere for Part 7
From the previous Internet of Things Part-1 through Part- 6:

  • All serial hardware protocols have to have some methodology to identify a starting point for the data transfer and the end of the data transfer, as well as when each bit is valid to be sensed.
  • We presented an overview of the list of protocols that IPv4 and IPv6 are able to handle as well as an overview of the list of protocols we wish to initially implement into our IoT Core Platform.

We presented the first part of the Ethernet Protocol hardware characteristics, the software frame structure and how it identifies devices on its network.
The Ethernet Physical Layer incorporates the following capabilities and features:

  • a differential twisted pair configuration for Transmit and Receive lines.
  • cable length is determined by the hardware, general Cat[5][6][7] cables are at least 100 Meters for 1Gbps and lower;  30 meters above 1Gbps
  • a variable length protocol - the payload varies from 46 bytes minimum to 1500 bytes maximum with an added eight bytres (802.2, 803.1Q) for inter layer links if incorporated.
  • an internally hardware controlled asynchronous autonegotiation protocol - uses 8 bytes to determine configuration and 12 idle bytes to end data transfer.
  • auto-configuration to run Full or Half duplex  for the 10/100 BASE-T,  1Gbps BASE-T and above run in full duplex only.
  • Ethernet switches internally maintain the devices IP and MAC address of devices connected to each port.
  • a mechanism through Ethernet switches allowing device to device communication without router intervention.
  • MAC addresses must be unique to the connected LAN devices.
  • Manufacturers must be assigned a block of MAC addresses along with a manufacturer ID.
  • The Ethernet Controller requires eight octets, a  block of 31 sets of state changes 1's and 0's to configure the controller for the start of the data
  • The Ethernet Controller requires a block 12 idle states to identify the end of data transfer or have a specified length in octets 20, 21 of  the frame.
  • Protocols have some way of checking or insuring the integrity of the data being transferred - many protocols use a Checksum or Cyclic Redundancy Check (CRC) -16/ 32 etc. bit algorithms.
  • Protocol and Headers are all not the same in the way the CRC's are implemented.

What we want to cover in Part 7:

The Checksum Algotiyhms and the Ethernet Protocol Cyclic Redundancy Check (CRC-32) 
In this part of the series we will present the error-detection section of the protocols for the Core IoT Platform, the checksum and the Ethernet protocol CRC-32.  We will start off with some ground floor history of error-detection in serial data streams and proceed to the  various algorithms that have been develop for the Internet.  We will then present an introduction with a bit of history of the embedded processor, microcontroller and CPU marketplace.  To close this part we will present an overview of the Core IoT Platform requirements in order to create an IoT Platform functional block diagram. The outline is listed below.

Enjoy the series.

Lets Get Started: A "BIT" of CRC and Checksum History
Serial data transfer from its conception to present day has the task of insuring that the data block of bits being transported does not contain any changed bits during transfer.  Before the Internet serial communications were part of the telecommunications and information theory, coding theory, cryptography and others.  What the innovators looked at was how to detect bit reversals in a block of bits and ignore the actual format of the data being transferred.  All that was of interested was that there were no bad bits in the block of bits period.  Well to look at this reality we have to look at how many bit reversals exists in the source block of bits and calculate a methodology to test for any reversals.  If there are no reversals then it is assumed that the block of bits was transferred correctly with no errors.  This simple explanation has created a "bit" of confusion in the serial digital world and still exists today.  Ok, the research of bit reversals leads us into the theory of how several checksum methodology evolved to and how to place them in the block of data bits for the best performance.  Checksum algorithms vary in the world of processors and programming, there are a set of simplified checksums for embedded processors that handle smaller data transfer sizes to the Internet that handle gigabits of data continually.

The object of the theory is to detect errors in transmission by using some sort of error detection code sequence which was introduce back in the 1940's by Richard W. Hamming who modernized the development of error-correcting codes.  This was fast evolving by the contribution of other theorists and ended up with the name Hamming Distance and so we have the introduction to checksums and CRC by way of Error-Detecting Codes and Correction incorporating Hamming Distance theory.

Hamming Distance:
The Hamming Distance (HD)  is defined as the number of transitions required to make two strings of identical length the same.  Hamming Distance is an interesting theory when applied to comparing a block of bits as we will see shortly.  It is also an interesting application when applied to cryptography and ciphers.  Hamming Distance is a starting point for cracking a cipher based on language, region, and bit changes within blocks, there are several other brute force methods as well which will be discussed in another blog on cryptography in the future.  OK, so the question, what does Hamming Distance have to do Checksums and CRCs?  The larger the Hamming Distance number means the more bit reversals within the block of bits being tested and the reference block of bits, the more difficult it is to be exact that a bit error will be detected.    Lets take both Checksum and CRC separately and look at the methodology and how they would detect bit errors.

There are many documents published detailing several different methodologies to test a block of bits, in fact so many that some sort of standard had to be set for the Internet in order to insure some type of data transfer integrity where all system use the same methodology at both ends to insure consistency throughout the networks.  As we stated in previous parts of this series, "as long as you follow the protocols in place the data will be routed source to destination however, there is no guarantee that the data will not contain bit errors "and" that is the main task of the CRC and Checksum algorithms.  The user data extraction is up to the application to encode/decode the users data which also should contain some sort or data integrity checking process as well.  So with that said we will look at the protocols being presented which are Ethernet, IP, TCP, and UDP and the checking methodologies used to insure data transfer integrity.   There is an intense amount of research information on serial data bit testing and grouping of bits into blocks of various sizes attempting to create the best process of identifying a single bit error in a large block of data during transfer.  We will give some references at the end of this part for reference, one could make a career in error-detecting-codes, that is not the intent here, just an overview with an understanding to implement the algorithms for our IoT Core Platform development.  There are so many web pages that give the source code in several languages for the Hamming distance function eliminating the need to present it here.

We often see in the protocol header used in the Internet fields labeled  "Checksum", Frame Check Sequence (FCS) , CRC and others, these fields may be a Checksum or CRC or some other error checking methodology unique to the protocol. To clear this up we will look at the checksum functions and the Cyclic Redundancy Check (CRC) algorithm which are the main functions used for many of the protocols, specifically for the initial IoT Core Platform.  We will return to the Checksums and CRC later in the series when we address the programming of selected protocols and the OSI model.

Hamming Distance And The Checksum:
Here we are now 20 years later into the 70's and still wondering how to best incorporate the error detecting and error correction codes for large amounts of data transfers.  Well lets do a slow walk first to see how this bit reversal and error detection evolved.  The Hamming Distance theory set the sites of looking at the reduction of bit reversals in a segmented block of bits for transferring data insuring that if a transfer error or bit reversal happened it would be detected.   This lead to the simplest proof of the Hamming Distance Theorem when it was implemented into a ASCII hex file data format representing bytes of data.  This simple checksum algorithm was introduced by Motorola and based on the 6800 microprocessor series and given the names SRECORD, SREC, S19, S28, S37 file format which was commonly used to program the flash memory, the loading format was not very fast but very efficient at the time.  Intel Corporation® reviewed and revised the file format for use on the 8008 CPU in the early 70's and eventually created a new specification for the Intel processor line in the late 80's and labeled it the IntelHex File Jan 6, 1988 for the entire x86 line of processors.  OK enough of ancient history, although roots are important, even though they are routinely ignored the tree would not have grown without them.

The IntelHex file format checksum is the interesting section of the IntelHex File format that we want to cover here which is defined as the sum of all the data bytes in the single line as shown in Figure 7.0 below.  The line of code has a maximum length of  [Start Code(S) + Byte Count + Address +  Record Type + Data ] bytes all represented in ASCII Hex format.  Each eight bit byte is represented by two ASCII hex characters (0-9-A-F)  for a maximum ASCII hex character line length of [1*2 + 2*2 +  1*2 + 256*2 ] =  1032 ASCII hex characters + 1*2  characters for the checksum which is attached to the line after calculation.

The checksum calculation is the two's compliment of the Least Significant Byte of the summation of ASCII Character bytes in the line less the Start Character, ASCII colon ":".  So how is this effective?  Lets look at Figure 7.1 The Hex Number Notation and the actual data transitions of the hex data 0-9, A-F  in binary format, they are 0x30 - 0x39 and 0x41-0x46 respectfully to binary string values are 00110000 - 00111001  and  01000001 - 01000110.  So as we see the number of transitions to make any two binary hex digit strings to be the same is always less than 5 transitions.  This is important for checksums since the lower HD number the better chance of catching a bit error in a sequence.  The upper case A-F  is used since bits 5, 6, & 7 never change leaving only 5 bits to test. Bit 4 gives a minimum HD of 1 and the detection of  a bit reversal would only require the checksums to be different.  This is the reason that the simple IntelHex File checksum is effective.  This checksum algorithm would have a greater opportunity to miss the detection of a bit reversal if the entire byte of 255 reversals were allowed.

The IntelHex File Format for transferring data is one of the "least efficient" methodologies and would totally burden the Internet, however for loading an embedded processor program memory, FPGA's, CPLD's EEPROM etc. it is efficient and accurate which is why several embedded processor manufacturers incorporated it into their Integrated Development Environment (IDE) tool and still widely used today.  Since the IntelHex File Format is only applied for single text line of characters with data blocks of 256 bytes [256x2 hex characters] or less makes this algorithm not applicable for Internet data transfer checking function that require large amounts of data transfers.

IntelHexFileFormat
Figure 7.0  Intel Hex File Format Example

ASCII_HEX_BinarySrting.jpg
Figure 7.1  Hex Numbers 0-9 A-F in Binary Notation

Taking into to account what we are looking for is actual bit reversals from the transfer of data from source to destination through a medium.  So if we look at the data and ask the following questions while visualizing the data blocks shown in Figure 7.2.

  • What would be the optimized block size for the checksum?
  • What is the reliability of detecting a single bit reversal anywhere in the block of bits?
  • What is the probability of detecting several bit reversals in the block of data?
  • How many unique bit reversals would have to convolve to give the same source checksum results?
  • What is the probability of several bit reversals that would convolve to give the same source checksum results?

Checksum_Blocks
Figure 7.2  Hex Numbers 0-9 A-F  Sum of Blocks Calculated Checksum

For this example we are only using the ASCII Hex byte for simplicity since the resultant G(x) size for the sum would be less than 16 bits and the highest bit change would be bit five would be 64 x 1032 = 66,048 which would require 17 bits sum register for G(x).  Looking at the bit patterns in Figure 7.1 and the blocks in 7.2, in order to get the same checksum from bit reversals two consecutive blocks would have to have a specific bit reversal that would subtract from one and add to the other to give the same sum.  The probability of this happening is very small due to the uniqueness of the ASCII Hex bit patterns.  The probability of detecting one to several bit reversals is very good.  This is why the ASCII Hex file format has a high reliability.  If all eight bits were to be used this would reduce the reliability and be difficult to handle if the total number of blocks were to increase.   This is the basics to understanding bit reversals and the front door of error-detecting, error-correcting code sequences.

Moving forward, to the late 70's an individual from Lawrence Livermore Labs credited for creating a flexible checksum algorithm that incorporates a variable block size and was given the name the Fletcher Checksum after its creator John G. Fletcher (1934-2012).  This added more credibility to the error-detection process and is used throughout the Internet today.  However, keep in mind that all checksum algorithms that use the sum algorithm process have their limitations since it is just a sum and XOR of bits that give a result on a block of bits.  Adding two byte/word bit strings is a simple non-cpu taxing process and is the fastest algorithm for obtaining a sum of a block of bits for a simple checksum algorithm however, as stated it does have its limitations.

The Fletcher Checksum implemented a Checksum Size to the process which allowed variations for different applications and improved performance. If the groups are sized properly depending on the Hamming Distance the probably of missing the detection of a bit reversal is reduced to a very usable state for transferring large amounts of data as well as loading embedded system memory that would be apparent over the Internet, however it is still questionable today of its performance with present Gigabit network speeds.  The Quality of Service (QoS) of the Internet is quite high and if the physical layer is properly installed the transfer errors are very low;.in a gigabit network even if the data resends a few packets it would not be realized over time.

CRC Versus Checksum:

Checksum Overview:
A Checksum is a simpler runtime calculation of a group of bits to determine if any errors occurred during a data transfer process.  There are several checksum functions or algorithms depending on the design goals and would usually work on small datum sizes.  Checksum algorithms are Parity byte or Parity word,  Modular Sum,  Position-Dependent.  Before the innovation of disk drives serial data transfer existed way back and used the simple audio cassette player - the Commodore Vic20 C2N-B Datasette.  The Datasette was so reliable that they were widely used in Europe while the USA was moving to the disk drive.  The first digital error checking was writing the data twice and checking it twice, not much for efficiency however very accurate.   This progressed to a faster method for transferring digital data that incorporated the simple checksum methodology.  The original simple checksum was created by Motorola for the 6800 and progressed to the Intel Corporation IntelHex File Format as stated earlier.  

Cyclic Redundancy Check CRC Overview:
The CRC (Cyclic Redundancy Check) algorithm was initially created in 1961 by W. Wesley Peterson.   The CRC size used in the Ethernet physical layer protocol is 32 bits (CRC-32) and was derived from the work of several researchers and was eventually published in 1975.  The CRC was created to work on blocks of binary bits, hence the CRC-dd where dd is the size of the binary block.  The CRC is an integer algorithm, no fractions or remainders, which implies that it is not exact and has "bit" limitations. In fact there has been a lot of research into the CRC algorithm(s) to select the optimized polynomial size and bit blocks for the Internet as well as other serial protocols.  The tradeoff for using a CRC or Checksum algorithm is that the data it is applied to is not changed in any way as with encryption and other algorithms that change and add data to the original data and increase or decrease the length.  Before we get into irregularities of the CRC lets focus on the protocols we want to present, the Ethernet Protocol which uses a CRC-32.

Hamming Distance, Polynomials And The CRC
Hamming Distance and the CRC polynomial methodology has been around for many years prior to the Internet that DARPA was developing in the 70's.  Today after all the research and papers published the conclusion is that there is no single CRC polynomial "silver bullet" that will yield the same performance for all the applications.  This has created some challenges for the Internet Standards Group to define a error-detection code standard for Internet traffic as well as create some confusion for hardware and software developers.   There still are different CRC size algorithms being used today for specific applications; it is important to keep in mind as we present this series that CRC algorithms are generally tailored for the best performance for the application.  Several reference links to CRC papers on various Hamming Distances and CRC sizes versus performance characteristics will be at the end of this part of the series.  We will revisit Hamming Distance, CRC, Checksums and other algorithms along with some core applications when we present the security and encryption sections of this series.  The paper presented at the International Conference on Dependable Systems and Networks covers the issue of CRC polynomials with data.   We will return to these algorithms when we address the protocol software implementation.

Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks 2004 

Philip Koopman
ECE Department & ICES
Carnegie Mellon University
Pittsburgh, PA, USA
koopman@cmu.edu
Tridib Chakravarty
Pittsburgh, PA, USA
tridib@alumni.carnegiemellon.edu

Hamming Distance, CRC, Checksum Summary:
Ok, to even attempt to put in ones own words the vast amount of research and experimental data performed over the years on the checksum vs CRC would be an exercise in futility.  So instead lets acknowledge the brilliant minds that already performed these tasks with precision.  Review at your leisure to understand the unique variations of the two algorithms and keep in mind that there are issues with many of the error-detection coding used on the Internet.

Performance of Checksums and CRCs over Real Data (1998)
Craig Partridge (Bolt Beranek and Newman, Inc),
Jim Hughes (Network Systems Corporation),
and Jonathan Stone (Stanford University)

Looking at systems in mathematics and definitions, multiplication is group addition and division is group subtraction; the basics of the checksum is group addition, we see that both CRC polynomial evaluation and checksum have similar properties.  The uniqueness of the CRC is that the polynomial allows a combination of groups because of the division and has a greater probability of detecting a bit reversal because of the Hamming Distance.  The conclusion is that error-detection for bit reversals during transmission will remain a challenging topic for one to create a fool proof methodology.  The interesting part of all this is the ability to detail the limitations of the algorithms and still be able to implement them and generally rely on their functionality as we have for the past 50 years and will continue until a better methodology in created.  We will be implementing various security protocols and policies during once the hardware has been defined for the Core IoT Platform.  This covers the initial presentation of the Internet IPv4 and IPv6 in general and gives us enough details to select the hardware platform. We will be implementing the Checksum and CRC in a software module for the first time through development.  Hardware implementation of CRC algorithms will be addressed after the initial Core IoT Platform has been through a POD (Proof of Design).

Introduction to the Embedded Processor and CPU Marketplace:

A Brief History of the Embedded and CPU Major Players
The $64,535 question of the day, which one should we pick?  Lets backup for a moment to look at the Embedded Processor and CPU Chip Marketplace and the timeline of how it evolved.  Since this marketplace is huge we will only cover some of the Mergers & Acquisitions of the major players in the marketplace to get a glimpse of the arena we are entering.  You may easily search the various manufacturers to see the transitions if you want to research this further.  OK, the major players back in time were Motorola®, Intel®, Cyrix®, AMD®, SMCC®, Microchip® and Texac Instruments®.

  • Motorola®  processor division dominated the embedded and automotive embedded market (68x00 Processors) for many years then decided to diverse its embedded division to become Freescale Semiconductor®.
  • Intel® entered the embedded market after 1986 when they moved the 80x86 CPU line to the newly formed embedded division, from that point on after every silicon rollover of older processors enter the Intel embedded arena.
  • AMD® aquired the x86 instruction set perpectual license by acquiring National Semiconductor® and Cyrix®, the creator of the Intel Math Co-Processor chip.
  • Microchip® acquired SMSC® (Standard MicroSystems Corporation)  in 2012 and Atmel® in 2016.  Microchip markets the MIPS32/64®, ARM® Cortex™ processor lines..
  • NXP® acquired Freescale Semiconductor the original HC68000 embedded processor line.
  • Texac Instruments® - Acquired Burr Brown in 2000,  acquired National Semiconductor in 2011, National Semiconductors cross license of the x86 instruction set for the Cirrus Processor.

There are several other players that cross license cores and put their own name on them which we did not mention here for simplicity.  All of the above companies and several other younger players incorporate the ARM Cortex line of processors, since ARM allows the cross licensing of  the processor technology.  This allows each of these manufacturers to incorporate the ARM processor technology and incorporate their own unique interfaces and software development environment.  ARM also distributes its own development software as well as training for the processor line. OK, that is a brief history of the embedded processor marketplace from 1971 to 2017 that shows nothing is as stable as we would like it to be when developing hardware.  For the selection process we have to decide on a 32 or 64 bit processor and which manufacturer will be manufacturing this processor for several years. Researching embedded processors on the Internet we see that there are many available, however when we review the Last-Time-Buy (LTB) we see that many are being discontinued by the end of 2018/2019.  That means that we would have to redesign the platform before we even get it on the market for a year.  Silicon rollover is one of the major concerns in the hardware development process.  If you are in the market for the long term you have to make long term decisions to insure cost effectiveness.  This is usually overlooked during the startup stages since the main objective is to get the product to market first and create the market need and identity.

The Processors Dilemma:
Embedded Processors vs CPUs vs Micro-Controllers vs System on a Chip (SoC)
There are many players in the Embedded Processor Units (EPU),  System on a Chip (SoC) and  Micro-Processor Controllers (MPC) market to choose from on a global level and only a few at most in the Central Processor Unit (CPU) market, it is acronym-alphabet soup city.  The real dilemma arises with Silicon rollover, discontinued parts, revisions that are not Plug'N'Play compatible which create a headache for the supply chain industry and a nightmare for the design engineer.  To add insult to injury manufacturers like any other business look at the bottom line and fail or just plain neglect to let the designer know when the Last-Time-Buy (LTB) date is and generally hide it from their roadmap's.  Forcing a Life-Time-Buy for any product is a very serious concern, not only for the expense for the LTB but the expense and resources required to redesign the product.  So how do we handle this conundrum? Answer: pick a stable processor, if there is one!  Manufactures of embedded components and tools are different from the standard commercial and consumer products.  Consumer products are designed to be replaced at the earliest tolerable life cycle, commercial products look at about two to three years or shortly after the instream revenue falls below the expected margin usually peaks out by 2 years.

Going back in time, the original Intel 80486 back in 1989 introduced the first processor incorporating the tightly woven pipeline architecture and remained in the embedded market for over 15 years before Intel officially stopped manufacturing the chip.  However, there are still a couple of manufacturers that still produce chip with the x86 pipeline process under one of the few remaining perpetual licenses.  The ones I found on the Internet that sell the Chip and not a fully assembled single board computer are AMD® Corporation GEODE™ Series, system on a chip with graphics engine,  ZFMicro™ Corporation  ZFx86™ which is a 100MHz 486DX pipeline processor with an 80 bit FPU core with no graphics engine and 33 MHz PCI BUS and IDE drive interface under 1 watt; both ZFx86 and GEODE series are SoC's.   The Microchip MIPS32/64®  processor line is a RISC (Reduced Instruction Set Computer) M-Class processor core and as of 2017 MIPS32/64®  processors are still being used for residential gateways, routers and other Android/Linux OS based embedded systems.  MIPS origin is formally from MIPS Technologies back in the early days.  From the history MIPS processors would be the likely choice for the IoT Core Platform.  MIPS architecture is still a pipeline architecture with some added features that add up to five additional cycles to complete the fetch and execution while balancing the System Clock to the Instruction Performance.

Which Embedded Processor To Choose? 
From Part 4 it becomes apparent that we will have to use some type of processor for the IoT Core Platform to handle the communication and security functions  Also since we are looking at both conventional AES256 as well as unconventional security methodologies for future devices we will also look at separate processor for handling the security functions.  The dual processor feature allows greater flexibility for future growth and separate processors allows the data flow to be encrypted separately for the normal Internet communications.  Selecting the right processor(s) for the platform will determine the longevity and QoS of the platform.   The objective is to be able to control all the central processor functions externally.  There are many CPU's that take all the control away from the designer such as Intel, AMD and others by incorporating an OC right inside the CPU chip at Power On Test (POT) and setsup all the driver connections to the peripherals.  This only allows the user to ride on top of this and thus allowing vulnerabilities since much of this core is Intellectual Property and protected by the manufacturer and they do have that right to protect their IT just as we are.  The difference is that if we add IP to the platform on top of someone else's IP we have no guarantee that we are the only one controlling access, basic security policy 101 especially if you are going to connect to a network in any way.

Putting our top level requirement on the table for a flexible IoT Core Platform that has reasonable RAM and FLASH memory to execute the simple to the complex application does present a challenge.  There are two schools of thought when developing a platform, the first is to reduce the chip count to the smallest possible number up front and struggle with the selection of embedded peripherals that can be shared; Second, start with a stand alone processor then add the memory and peripherals selected for a proof of design then start to reduce the design for cost savings.  There are pros & cons for both approaches.  Our approach in this series is to create a functional block diagram using single blocks for each function to get a top level (40,000 foot) envision of the all the functionality we would like for the platform.  From the functional block diagram we will look at how an embedded architecture will incorporate some of the blocks and build the system platform from there.

For those who prefer running an OS like Linux or others we will keep that in mind when selecting the embedded processor system. The embedded marketplace has caused a lot of work for the Linux development team that certifies Linux OS implementations with hundreds of embedded processors if any would be available today.  Remember if we just look at the core functions we could use other technology to add functionality later as long as we maintain control over the functional components for implementing security policies.

The Embedded Processor Selection:
We are not going to select an embedded processor at this time since we have a lot more to discuss.  Embedded processors incorporate many features for handling applications which makes the selection challenging.  The selection process for this series addresses several major features for the purpose of education from the beginner to the seasoned product developer to share knowledge in developing the IoT Core platform.

  • Long life cycle availability, at least five years with roadmap's for revisions and support. Typical for the embedded markets
  • Common assembly language across 32/64 bit platforms.
  • Processor speeds of 100 MHz minimum.
  • Full control over the boot up process of the CPU, Memory & Peripherals.
  • Free or low cost  IDE (Integrated Development Environment) platform if available.
  • Software: C Compilers &  Macro Assembler, Linux, WinCE etc. OS's supported.
  • Many application examples with source code for support.
  • Libraries available to reduce software development time.
  • Evaluation demo PCB for the selected embedded processor.
  • Selection of different configurations using the same IDE platform software.
  • Large selection of physical chip packaging, LQFP, TQFP, BGA - environment reliability.

The IoT Core Platform Peripheral Requirements:

Peripheral vs. Functions
At this time we let our imagination run free a bit and pick the main peripherals and functions we would like to have in the IoT Core Platform.  Table 7.0 Core Platform Peripherals and Functions, below list out these requirements and a short description of each.  From this list a functional block diagram may be created.  When we look at the functional block diagram it looks similar to the embedded processors with a bunch of peripherals available today.  We have a few choices at this point as to how we want to create the IoT Core Platform.  Selecting just a CPU core, Interrupt Controller, a DRAM controller and FPU would put us in the SBC (Single Board Computer) arena.  Our Intent here is to get a single chip that has many of the functions in the block diagram then add the ones that will be required per application.  That keeps the chip count down to a minimum.  However it would be great to have some type of evaluation demo board that we could test software and hardware for the peripherals we will be adding pending the application.

Peripheral Type

ISP Side     IoT Core Platform Peripherals   Description

Ethernet Controller  10/100/1Gbps

The ISP front end WAN that is connected to the Global Internet RJ45

WiFi  Controller 2.4GHz / 5GHz dual band

The ISP front end WAN that is connected via WiFi - IPv4 / IPv6

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform Peripherals   Description

Ethernet Controller  10/100/1Gbps

The local  LAN/ULA network connections that are for hard wired peripherals RJ45 connected  to the platform LAN / ULA local network

WiFi  Controller 2.4GHz / 5GHz dual band

This is for all the Local Wireless WiFi peripherals that are connected to the platform LAN / ULA local network

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform  Serial Control Peripherals Single Channel   Description

SPI (Serial Peripheral Interface)  

Standard Component and control interface. These are direct connect devices that are separate from any network or wireless protocols.

I²C (Industrial and HighSpeed ) topologies

Standard Component and control interface.  These are direct connect devices that are separate from any network or wireless protocols.

CAN (1 Wire / Differential)

Standard automotive network peripherals

RS-232/422 Serial I/O

General Purpose Serial I/O devices

   

Counter-Timer(s)

This is used for event triggering of peripherals

Real Time Clock Output

This is a separate output from the system clock that is programmable to a specific interval.

Watchdog Timer - Interval Programmable

This is a separate timer for the system integrity and insures that the system is running in the sequence programmed.

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform  Serial Control Peripherals  Multi-Channel  Description

Bluetooth 2.4GHz

These are for all the Local Bluetooth devices connected to the platform LAN / ULA local network

USB 3.x / 2.0 

Standard USB interface with High Speed option of 480MHz USB 2.0 minimum

Parallel BUS (16/32Bit Data) / (16 Bit Address)

This is a separate data bus for parallel type peripheral connections. It allows any type of direct connection to the platform. (Optional)

Analog Inputs 16 Bit  - 8 channels analog inputs

This is for monitoring environmental and platform parameters directly (0 ± 15Vdc standard

Analog Outputs 16 Bit -  8 Channels

This is for controlling and adjusting and calibrating sensors for environmental parameters directly (0 ± 15Vdc standard

RTD Analog Signal Conditioning Front End

This is for Platinum RTD's for very accurate temperature measurements. Separate peripheral for 8 channels

Thermocouple Analog Signal Conditioning

This is for standard thermocouples standard temperature measurements. Separate peripheral for 8 channels

 

Peripheral Type

Core Processor Section     IoT Core Platform   Description

32 bit pipeline MIPS M-Class Processor

MIPS M-Class processors allow same instruction set for both 32/64 bit. 32 bit is efficient for the IoT Core Platform.

FPU  Single/Double precision

Floating Point Processor unit - Single / Double 64 bit precision

Interrupt Controller - 8/16/32 channels

Interrupt controller to generate interrupt requests to the processor selected.

DMA controller for RAM Interface

Direct Memory Access controller to allow peripherals direct access to the RAM interface.

EEPROM interface for external parameter storage

This is a separate EEPROM storage area for platform parameters only accessible through the security interface Serial/Parallel NAND to handle up to 16 GigaBytes (128Gbits)

RAM interface for external data buffering

This is a separate interface that allows the connected peripherals direct high speed access to the memory for data collection.  Static RAM up to 32 MegaBytes

 

 

Table 7.0   Core IoT Platform Peripherals and Functions


Figure 7.2   Core IoT Platform Functional Block Diagram

OK, the functional block diagram shows many peripherals attached to the main bus, it is not very difficult to create a block diagram like this considering the number of features we would like to see in the IoT Core Platform.  The two items that should stand out are the 32 bit parallel interface controller and the Custom User Interface Controller.  If we were to remove all the other peripherals then the 32Bit Parallel Interface Controller and the Custom User Interface Controller would allow us to add just about any type of peripheral(s) that can be imagined within the boundaries of the processor.  

I am not a big fan of wireless in a process control area for many reasons that we will cover when we get into the security and software development parts of the series.  

This is the first conceptual block diagram presentation of the Core IoT Platform, as we continue the series we will apply any changes to the platform as required for the applications and optimization


Reference Links for Part 7:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main_Page

The high level expert links for the CRC and Checksum are listed below; there are so many Internet references to this subject that listing them would take up several pages and is not the intent of this series.

PDF The iSCSI CRC32C Digest and the Simultaneous Multiply and Divide Algorithm January 30, 2002 Luben Tuikov & Vicente Cavannay 

PDF Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks 2004  Philip Koopman,  Tridib Chakravarty

PDF Performance of Checksums and CRCs over Real Data (1998)  Craig Partridge, Jim Hughes, Jonathan Stone

TEXT Computing the Internet Checksum RFC 1071


Part 8  Preliminary Outline:

  • Embedded Processor Technology, CPU Chips Technology,  FPGA System on a Chip - How much control do we really have?
  • Types of processors, MIPS, RISC, CISC, Single Core, Multi-core etc.
  • Boot up Initialization processes and Vulnerabilities using embedded processors and independent CPU chips.
  • Secure Boot processes and Embedded Cryptographic Firmware Engines - A Closer Look.
  • An introduction to support chips for processors,  NorthBridge (MCH, GMCH) /  SouthBridge support chips (ICH),  SoC Platform Controller Hub
  • Security protocols and how they play a roll in initialization.
  • Selection of the Core IoT Platform Processor(s) and peripherals.

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-7 The Ethernet Protocol(s): Lets Sync Up- (November 23, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=12&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-7 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Sept 242017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

1 2 3 4 5  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2017 BASIL Networks, PLLC. All rights reserved
webmaster