BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B | March 2018

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

saltuzzo | 16 March, 2018 17:35

Part 9: IoT Core Platform - Embedded (SoC), (SIP)
The Core Processor of Embedded System Configurations - Vulnerabilities Continued

"Firmness of purpose is one of the most necessary sinews of character and one of the best instruments of success. Without it, genius wastes its efforts in a maze of inconsistencies." - Lord Chesterfield

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 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 10 IoT Core Platform
- SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018) 
Part 12 IoT Core Platform
- SoC Core Processor of Embedded Systems -Documentation Management Processes (July 29, 2018)

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

  • (Worth Repeating) - 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 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 basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • Basic types of CPU architecture on the market today

What we want to cover in Part 9:
A short detour to present an overview before we cover the MMU and Virtual Technology.  There are many publications on vulnerabilities relating to the x86 multi-core processors and the Management Engine environment incorporated as part of the processor chips for the past 10 years that should be addressed before we move into the security and privacy policies.  We will present this as an introduction to security, privacy and control of the Memory Management Unit, the DRAM controller and the Paging for Virtual Technology.

  • A short historical (not hysterical) summary of high performance processor development to the current state.
  • The current vulnerability issues of high performance processors that are circulating on the Internet.
  • A look at the internals of x86 processors and hidden OS vulnerabilities
  • An Engineering Approach to identifying the issues of concern.
  • An Engineering Solution "suggestion" for the main issues.

Lets Get Started:
A Brief summary - CPU, MMU, Page Memory Virtual Memory Summary:
While writing this series my thoughts were simple just remain focused on the series, moving forward linking every part of the series together smoothly, well, there is always construction on the highway and some detours.  This short presentation detour will present the two main vulnerability issues, yes jut two for now, that we will be facing since they address processors for the past 10 years and future processors.  Since the current state of concerns are security and control as well as privacy, we are at the point where we have to talk about security policies, control policies and of course memory access and create them for our Core IoT Platform.

Wow, things change fast in the technology arena with everyone writing about the majority of CPU vulnerabilities with Meltdown and Spectre and others.  This series is not going to disrespect or criticize the huge effort that has been on-going to develop operating systems for the industry. So lets give this a positive attempt to put this into the engineering perspective, that is before a problem may be solved it has to be analyzed and understood with given facts that have been vetted and the desired results.  There are two main technical papers covering Meltdown and Spectre but before we get to them we have to put some core facts on the table.  There are two issues of vulnerability that exists, the first is the internal control of all peripherals by a secured processor that runs an internal OS that is part of the multi-core processor chip, second is the Virtual Page vulnerability fault identified by Meltdown and Spectre publications.

OK, not to give age, al little history is good to understand as not to repeat it.  I started working with designs in the 70's on Data General NOVA, Micro-NOVA and Digital Equipment Corporations PDP-11 Series minicomputers, by the late 70's early 80's I started designing with Intel Processors in the days of the 8080 when it was first released and moved to the 8088 and was fortunate enough to own an IBM-PC in December 1981 that was used for developing hardware and software, no I do not use a walker although I do sit a lot more,  so you might call me seasoned or just strong minded.  So what does this have to do with the price of tea?  Nothing, however it has to do with the advancements of technology in the industry over time and the forgotten problems that have been solved as with all new technologies from someone that experienced those advancements while working in development for over 35 years.  There were two main developments in the computer processor world at that time, mini-computer mostly CISC architecture and microprocessor RISC architecture advancements, both have teams of talent.  Keep in mind that the development of MINIX and other operating systems started way back in the 1960's as well.

Processors in those days required a lot of external support chips to make up the system motherboard and memory management issue was studied and was implemented into the chips however, required more development to make it practical.  As time passed and the fabrication process technology improved more of the support chips were integrated into the processor support chipset's. Figure 9.0a and 9.0b are the 19" rack mount relics' of the computer age in the 70's.  There are still some PDP-11 systems controlling power plants in Canada.

DATA_GENERAL_NOVA
Figure 9.0a Data General Nova,(1971) - Micro Nova  (1978)

DEC_PDP_11_LSI_11
Figure 9.0b   DEC PDP-11 (1970) - LSI-11/23 (1978)

A Brief Historical Summary of Technology Advancements Over The Years.
To really start this brief historical journey we should start way back in the 50's, yes, there were working computers then, the Univac-1101 or ERA 1101,  the first computer was named Colossus in 1943.  For you SiFi groups Colossus was a 1980's movie.  The programs that were run were broken down into small partitions which were placed in secondary storage and called up to be overlaid into a predefined block of core memory for processing.  This virtual overlay process and virtual memory was created from a thesis by German physicist Fritz-Rudoff Guntsch in 1956.  The Atlas Computer developed in 1959 was the first to incorporate Virtual Paging Overlay methodology at the University of Manchester and was formally commissioned on the Atlas computer in 1962.  Also in 1962 Burroughs Corporation (for us old timers) released the first commercial computer with Virtual Memory Overlay technology, B5000 that used segmentation rather than paging.  Figure 9.1 shown the Virtual Memory Functional Block Diagram With Segmentation.  Paging was still a theoretical process and still being developed due to the complex translation software and hardware limitations at the time, segmentation was a more practical first approach.

Virtual_Memory_Segmentation
Figure 9.1   Virtual Memory Segmentation Block Diagram

IBM in 1969 solved the problems of virtual memory for commercial computers by proving their Virtual Overlay System was reliable on the IBM-370.  From there the storage and chip technology advanced to a point that made page memory feasible and Digital Equipment Corporation incorporated Virtual Address Space in their VAX/VMS (Virtual Address eXtension / Virtual Management System) and their Multi-User/Multi-Tasking OS  RSX-11M and MUMPS.  Data General Corporation initially developed RDOS (RealTime Disk OS) Data General was acquired by EMC in 1999 and EMC introduced VMWare a Virtual Machine OS. The main architectural differences between Digital Equipment and Data General is Digital Equipment is a Memory Mapped I/O architecture where the I/O devices occupied an actual memory address; the Data General is a dedicated I/O architecture where all I/O devices have a unique address that is not part of the memory addressing and specific I/O instruction set that is accumulator or register based.  The mini-computers were all CISC architecture computers and the microprocessor introduction incorporated RISC architecture; Intel and AMD are RISC architecture base processors.

Over time Intel and AMD addressed the Virtual Technology in steps.  First came the multi-tasking applications running in Virtual86 mode that was part of the 80386 processor by adding hardware instructions to the RISC processor for task switching with a TASK handler along with Global and Local Descriptor Registers, .  This enhanced the virtual operation and lead the way for multi-core processors.   Until the introduction of multi-core processors there were multi-processor chip motherboards 2-way, 4-way that had some unique logic as to operate in a symmetrical environment, Symmetrical Multi-Processors (SMP), or Multi-Processors (MP).  Intel's Xeon-DP chips were used for the 2-Way motherboards which is what we still use here for testing.

SMP configurations share the BUS and Memory and are controlled by the main processor in SMP systems as shown in Figure 9.2 Symmetrical Multi-Processors SMP configuration.  Each of the Applications ran in Virtual86 mode and each processor was capable of multi-tasking as well increasing the performance of the entire system.  SMP configurations only ran one OS and would require a reboot to run a different environment which was typical in those days using a multi-boot startup program.

SMP_CONFIGURATION
Figure 9.2   Symmetrical Multi-Processor Configuration Block Diagram

This SMP configuration was used for several years and continues today, hyperthreads linked to the Virtual Processor which is a separate core still controlled by the associated processor core the hyperthread was attached to.  The multi-core with hyperthreads increase the performance to the next level in the Xeon Processors which are still used today.  The latest Xeon is a true multi-core Virtual Technology processor chip that allows multiple operating systems as well as virtual multi-tasking per core.

For a true Virtual Machine by definition each processor must be independent, no dependencies on other processors in the core, and be capable of sharing all the functional peripherals attached to the system on demand.  Both Intel and AMD have protected IP as well as patents to protect their core technology advancements.

In 2005 both Intel  (Intel® VT) and AMD developed their own methodology of Virtual Technologies ending up with the same results using multi-processor core chips and entered the market of Virtual Technology.  This is when Intel and AMD incorporated total control over the Virtual Memory and Virtual Processor core to implement their propriety Virtual Technology.  Figure 9.3 shows the current Virtual Technology Block Diagram, a portion of the technology is propriety and protected from the public.

VAS_MMU_RAM_FUNCTIONAL_BLOCK
Figure 9.3   Virtual Memory To Physical Page Memory Block Diagram

Prior to 2005 there were no virtual processor desktops at the time, just SMP configurations, however Intel had a few years of accumulative experience developing the Memory Management Unit (MMU), the MMU being incorporated into the i486 chip along with the Floating Point Unit (FPU) and gaining knowledge with Virtual Address Space technology partly from the Open Source VAX/VMS software lead the way for the next generation processor.

The new Virtual Technologies started to gain momentum and several talks surfaced about hardware modifications, peripherals and what is essential for a desktop system, how small can it be to maintain functionality and performance., keep in mind that the only peripherals that were in the x86 processors were the Keyboard, Mouse controller, FPU the MMU, the Internal BUS arbitration logic and the easy back door for hacking, the "System Management Mode (SMM) controller", all these incorporated peripherals were controlled by an external drivers loaded when the OS was loaded except the keyboard and mouse that were part of the BIOS from the getgo; software driver updates were downloaded and installed externally.  Windows 3.x was released in 1990 and introduced the a pseudo virtual memory driver mechanism called a loadable virtual device drivers (VxD) and capable of running applications in protected mode that ran on top of DOS.  The processor support advanced to include DRAM Controller, MMU and  Real World BUS arbitration control were in a separate chipset's for each processor, these were called Nortbridge and Southbridge chip sets.  They handled different I/O functions for the specified x86 processor.

The advancements continued to Windows 95 in 1995, Windows NT  and Windows 98 in 1998 which introduced the Windows Driver Model (WDM).  Along the way Windows NT also introduced a new file structure very different from the standard FAT32 and entered the server Multi-tasking/Multi-user arena.  Windows NT was very easily hacked, in fact while at one company one of the engineers hacked all the user passwords and sent them to upper management to prove a point.  In 2001 Windows XP was introduced and by this time Microsoft and already had several years dealing with page memory management multi-tasking, also Windows NT changed names to Windows Server 200x and maintained the NT file structure for the XP environment as well.

The advancements and demands for faster, more powerful processing kept the pressure on the key players in the x86 processor marketplace, Intel®, AMD® and Microsoft® , to develop a more self adjusting secure user oriented Windows OS.  There were and still are many discussions of the pro's and con's of incorporating the video controller into the same chip with the CPU as well as other peripherals like disk management, USB etc., of course peripherals were incorporated inside the chip, however the drivers were still outside and installed as a virtual driver for the first level of change as the OS was installed.  Remote control of the drivers was short lived, in 2006 Intel® and AMD® incorporated a complete OS internal to their virtual processor chips.  The complete control using an internal OS was classified as a trade secret and was well kept till the vulnerabilities surfaced and that is where we are at today.

Vulnerabilities and Concerns for Chips Today:
The fact that the fabrication technology has advanced to a point that we are able to place many controllers in a single chip is not an issue it is a concern it is a technology advancement that many peripherals along with the multi-core processors are on a single chip..  As an example the Q9500 quad core 64 bit processor was released in 2007, connects to a LGA775 (Land Grid Array 775 pads) socket has 465 Million transistors Package size of 37.5mm x 37.5mm and was processed using 45nm lithography technology.  The 80486 16 MHz 32 bit processor released in 1989 in a 208 pin QuadFlatPack incorporated a little over 1 million transistors using 1µm lithography technology, (1µm = 1000nm).   The latest i7 generation quad core  processor with 8 hyperthreads is 3.1GHz 31mm x 58.5mm package built using 14nm lithography technology 2270 ball surface BGA (Ball Grid Array).  The lithography technology went from 1µm to 14nm in density, almost 1000 to 1 density increase, so putting peripherals on a single processor chip is not an issue.

The topology advance did not happen over night, it took several years to go from several LSI (Large Scale Integration) integrated circuits support, Northbridge/Southbridge chipset's, USB, Graphic and other LSI controller IC's.  As the density of wafer fabrication technology increased along with the reliability it was cost effective to incorporate more an more technology into a single chip.  As this process was being implemented so were the drivers, Intel motherboards were shipped a complete set of drivers for all the controllers that were on their motherboards, as did other motherboard manufacturers, the practice of including a setup disk for selected Operating Systems was part of the expectations for system integrators.  The practice of external software drivers still exists for third party PCIe cards and other peripherals to enhance performance or customize for special applications and gave opportunities for the OS manufacturers to advance their products to better support their customers.

Incorporating peripherals into the processor chip is really not a concern, however incorporating the drivers which in turn require some type of OS to control and interface them to the applications does change the game.  The "Secure Boot" process, the added hardware and software for security changed the security platform.  The pushback is coming not only from the operating system software manufacturers but from the security industry and third party software developers.  Now that all the vulnerabilities for a multitude of processors have been published the businesses are now looking at damage control and how they can protect their business from intruders since it does not appear a real solution is coming any time soon.   If a hardware rollover of the silicon chip has is required you are looking at a year plus down the road.  That is a long time to allow that many vulnerabilities to be exposed in the industry.

The incorporation of an operating system on the CPU processors creates a few concerns that have very little to do with the actual operating system itself.  The issue is that it puts a hardware manufacture of CPU chips in the operating system arena and controls how software will communicate with it.  This concept has been a concern for many years all the way back to the DEC and Data General days.  When I consulted for DEC back then the corporate talks throughout the corporate levels were "We are a hardware company forced to include an OS with the product", Data General also had the same point of view, however to maintain competitive they also were forced to developed operating systems.  Things would have been a lot different if the same support for RSX-11 and RDOS spun off and many applications build around it as the IBM-PC support.   It turned out that each application was a engineering project within a specific company and the software and hardware became proprietary and not for sale on the public market.

The next issue arises on how to communicate with the new All-In-One chips, hence the UEFI (Unified Extensible Firmware Interface) specification lays out specifics on how to interface with the processor, all 2899 pages.  From the first release January 31, 2006 to May 2017 Rev 2.7 there have been a dozen updates each year.  The Platform Initialization (PI) and the Advanced Configuration & Power Interface (ACPI) specifications which address the core of security and protection for microprocessors in today's marketplace.  What makes this interesting is that someone probably knew of the many vulnerabilities that existed way before they were published along with the fact of insuring that interfacing with the UEFI is reliable on their application. For the full set of specifications go to the UEFI Forum.

We hope to be conducting a few test here to monitor the communications activity when the system is turned off and when it is in sleep mode.  Updating the operating system is also an issue and how it will effect the outside OS's that have to communicate through it.  For the Intel line the internal OS has been identified as MINIX 3 which has been around for 30 years and has weathered the test of time as being a very efficient core OS.  The AMD Ryzen series is a propriety OS and is controlled by a 32 bit ARM Cortex A5 and monitors and maintains the security environment.  We will get to the operating systems when we address the software development part of this series.  There is no criticism towards any of the operating systems only admiration of the many hours spent developing, maintaining and then giving several of them to Open Source for all to use and learn from.

There have been so many vulnerabilities over the years from many products during their introduction of evolving technologies, many have been addressed and some are still prevalent that have been ignored, it is a real world.  Many issues have been solved with the release of updates and patches.  To understand and publish the vulnerability purely at a technical level always leads to some type of solution that may be administered to fix the vulnerability.  I doubt that this methodology will change any time soon since new code and applications are impossible to test for every type of hack.  As I stated in Part 1 "Where Do We Start" - All manufactures have the right to develop anything they want, sell it and make a profit from the technology.  Manufacturers also have the right to control and maintain intellectual property rights of their developed technology within their product.  Today we have a large volume of open source software under the GNU license that any manufacturer may use and alter as long as they maintain the GNU identification requirements of the source.  As new products, especially processors enter the market the demand to protect Intellectual Property and technology becomes more difficult due the advancements within the Internet and the ability to hack just about any server make patents and IP difficult to protect, so the next best thing is a Trade Secret which is what the major players and many corporations are now practicing and very well since it took about 10 years for the public to be aware of the current processor vulnerabilities.

It is obvious that Intel and AMD kept their trade secrets well hidden until a short time ago when vulnerabilities were uncovered.  The concern is not the peripherals on a single chip, it is all about this internal OS controlling the peripherals and applications have to go through and the possibility of unwanted access to the system the processors are used in.  The "Management Engine" interfacing has taken lead on the pushback.  Trade secrets become a problem when it causes damage to the user by not disclosing the risks as many are experiencing and over the last few months more and more risks have been exposed. Today there are so many processors internal to everything in every day business and private life that intrusion vulnerabilities are magnified 1000 fold considering over 1.5 billion cell phones and several hundred million tablets, desktops, laptops, tablets and can create tremendous losses on all fronts.

OK, The second issue that we are not going to reiterate on is the memory paging vulnerability issue of  Meltdown and Spectre since there are so many articles and opinions already out there.  This went viral on the Internet with just about every publication except teach yourself basket weaving 101 has rephrased it to their publications.  The technical side of this vulnerability is worth noting in order to understand what we should keep that in mind to address during the development of the Core IoT Platform.  The technical details about Meltdown and Spectre are linked for those that are interested.  We will talk about a solution next. Remember the MMU hardware is a peripherals and the API that drives it is software/firmware that is part of  the integrated OS that the processor manufacturers incorporate as part of their chip which has opened a Pandora's box of issues.  The x86 architecture on Intel x86 line and AMD Ryzen's series are now the center of a wide range of publications on the vulnerabilities.

A Proposed Solution with Facts - May Not Require A Chip Redesign- Summary:
OK, writing about problems without a fair reasonable solution is just paraphrasing everyone else's publications, something the author avoids, so here is a reasonable seasoned suggested solution from someone that has had many technical discussions of incorporating everything in a chip.  If you are expecting a "Silver Bullet" solution, well sorry that is only in the movies, however we are able to address the vulnerabilities one at a time and implement a solutions that are reasonable.  We will return to these vulnerabilities and other solutions during the software security part of the series.

The first argument on vulnerabilities is cored around the trade secret part of the internal operating system software as part of the processor chips, Intel x86 line using MINIX-3 and other Ryzens propriety microcode in AMD that takes control of all the peripherals and the Virtual Technology operations of the chip.  Since the internal code has access to the internal peripherals, some microcode to access them would be accessed in some way.  With that being said, a reasonable solution that would require a microcode update would be as follows.

Minix has a microcode kernel architecture for the OS and the drivers are user-applications, the peripherals still go through the kernel for register access, that is typical of all low level access for the application driver to be developed,  I am not sure how AMD performs the similar task, however it has some type microcode or monolithic OS and drivers are in order, considering the Ryzen latest round of vulnerabilities have been published.  Lets start with the Intel x86 Processors, this would apply to AMD as well, however, the OS is different.

  • Remove MINIX OS and all the peripheral drivers from within the chip - easy just erase the EEPROM (about 5MiB of the 8MiB).  
  • Keep the required standard Platform Initialization (PI) part of the BIOS, the MMU, FPU BUS Arbitration etc., the chip manufactures probably best suited for the task.
  • The MMU and Translation hardware that is proprietary and patented is still internal to the chip.
  • Once Initialized transfer all control to the developer and any drivers to the developers OS outside the chip.
  • Add an additional hook to Platform Initialization (PI) for the Operating Systems to initialize and control all internal peripherals.
  • The peripherals are already connected internally to the BUS arbitration crossbar logic therefore a small microcode update would allow these peripherals to be controlled externally.
  • Some parts of the MMU and FPU arbitration that performs a hardware translation may be part of a patent or IP that may remain in the 8MiB EEPROM for faster execution.  
  • Interfacing to this Patented or IP code may be licensed generating a revenue flow as part of the ROI for the chip development keeping the technology intact.
  • Add BIOS enable/disable of the internal peripherals to mask them out if desired allowing third party peripherals for customization.
  • Add an additional reset function for a default restore of the BIOS.
  • Disable SMM at startup on Intel Processor Chips and keep it off permanently.

All this leads to a relatively reasonable microcode update that will give the processor and all of its capability and accountability back to the programmers, developers and OS manufacturers.  There has to be an additional mechanism to reset the BIOS to a default state if the microcode and OS update is interrupted or fails to initiate, encrypt the default bios setup. The microcode and the OS updates may be accomplished with one update process or allow companies to perform the distribution internally manually or automatically through their servers.  The time frame for distribution is to be determined on the complexity of the updates and the companies involved.  The main concern here is the updates and who is the creator of the microcode in order as to insure to the public that the security is traceable for all concerned.

The second issue deals with the Virtual Technology Paging vulnerabilities, that may be addressed in the remaining space in the 8MiB of EEPROM, special intercepts may be incorporated to stop the full dump and the way the page table is rewritten.  Some scrambling may be initiated as to protect the raw data from being dumped as well.  This is probably the smallest hit on performance and may not be recognized if an increase on performance is brought on by removing MINIX and the other support nesting.

Why This Will Work:
Peripherals are just external devices connected to the processors BUS which require a device driver to operate.  For the graphics, nVIDIA and ATI  or other embedded graphic controllers they are just peripheral devices like any other.  Since the major players Intel and AMD already have access to graphic technologies from they previous Mergers and Acquisitions over the years,  nVidia & ATI controllers respectively and that both controller series are also used in COTS graphic adapters for many systems eliminates the issue of driver availability and support.  Intel also is licensing AMD Radeon graphics engine in the latest Intel's iGPU, well that ends the cold war on graphic technology since AMD and NVIDIA own so many patents it would be better to cross license, besides the Intel NVIDA settlement agreement ended March 31, 2017 opening the door to new business.

Even if there were some unique addressing scheme used, both Intel and AMD already have the drivers that work for their implementations of the controllers.  The peripherals do not have to be removed, just allow programming control from the outside.  This may or may not involve some hardware pin reassignment or microcode to redirect the control to the external BUS architecture to share the internal memory for graphics and other peripherals.   However since one of the cores already have access, some small microcode should be able to handle it.   This does not change any "Virtual Technology" capabilities of the chip and in some cases may even add performance to the processor since it may be able to free up a couple of cores that can be used as part of the OS as well.  

As for security, this allows the software to be secured by the OS manufacturer and not the chip maker of hardware, eliminating a level of who has what access and when..  This also gives OS manufacturers more flexibility to maintain security of their platform.  This solution has not changed the way peripherals are required to performs and it gives a broader flexibility for the Virtual OS to increase performance.  Peripherals like the Network Interface Controller, the USB, etc. should be completely controlled outside the chip and access to these peripherals should be allowed only through the OS.  There are a series of methodologies that we have been working on for a few years now and are planning to incorporating them into the Core IoT Platform for this series.

The extra internal memory probably about 5MiB and the associated cores could easily be used for protecting the processor from intrusion by allowing corporations to use that area for propriety company ID encryption and other security protocols that are unique to the corporation and also allow the OS manufacturers to add their own standard protection for consumers that purchase Windows, Linux and any other OS manufacturer for retail consumer use.  This gives control and accountability back to the operating system and developers.  These updates allow unique markets to emerge for the security of the consumer and corporate platforms, allows for secure code in the prevention of the current missed page interrupts for Meltdown and Spectre among others that are not mentioned here.  

SUMMARY:
The presentation of the current software vulnerabilities in conjunction with hardware limitations has without doubt raised deep concerns of security and privacy.  Presented here may not be the ultimate solution, however the fact remains that all new technologies have issues and eventually they are solved as they have been in the past to bring us to the level we are at today.  The embedded processor world is expanding at such a rate that security is being bypassed for the fastest to market at the expense of the publics privacy and safety.  The best we strive to do is to insure that today's solutions are not tomorrows problems.  Yes, hardware has bugs as well! combining the hardware bugs and the software bugs is enough to create a new feature!  OK, for you real serious minded that was a pun.

The Free Enterprise System:
Freedom of private business to organize and operate for profit in a competitive system without interference by government beyond regulation necessary to protect public interest and keep the national economy balanced.  The U.S. economic system of free enterprise operates according to five main principles:

  • Freedom to choose our businesses,
  • Right to private property,
  • Profit motive,
  • Competition,
  • Consumer sovereignty.

Consumer Sovereignty
In the end, it is the customers, or consumers, who determine whether any business succeeds or fails.  In the U.S. free enterprise economy, consumers are said to have sovereignty-the power or freedom to have final say.  Consumers are free to spend their money for Product X or for Product Y.  If they prefer Y over X, then the company making X may lose money, go out of business, or decide to manufacture something else (perhaps Product Z).  Thus, how consumers choose to spend their dollars causes business firms of all kinds to produce certain goods and services and not others.

"Those who cannot remember the past are condemned to repeat it" - George Santayana

 


 

Part 10  "Preliminary Outline" Embedded Processor Systems: Continued

  • Back to the Core IoT Platform Development.
  • Selecting a Platform Compiler
  • Selecting a Processor
  • and more ....

Part 1X+  More To Come -"Preliminary Outline" Embedded Processor System: Continued

  • Power On Sequence Initialization Test - 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 for Part 9:
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

 Open Source Linux Conference Europe on Intel® UEFI/ME      [PDF] Slides  

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

[PDF]Enabling Intel® Virtualization Technology Features and Benefits

[PDF] Meltdown

[PDF] Spectre 

[PDF] AMD Flaws from CTS Labs on EPYC, Ryzen, Ryzen Pro and Ryzen Mobile

[PDF] UEFI Specifications Version 2.7 All 2,899 pages

UEFI.org Specifications

Server Security Advisory AMD Processors
Lessons Learned From 30 Years of MINIX
Memory Segmentation

The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory


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 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 10 IoT Core Platform
- SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform
- SoC Core Processor of Embedded Systems -Documentation Management Processes (July 29, 2018)


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- (December 24, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=11&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-9 Embedded Processor Systems: <i>Continued (Mar 16, 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

 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2017 BASIL Networks, PLLC. All rights reserved
webmaster