Controladores ARM Cortex Mxx con Trustzone

Hola amigos, quiero compartir con ustedes la información de los nuevos controladores ARM Cortex M 23 y 33:

Thank you for registering for "Using TrustZone on Cortex-M23 and Cortex-M33 ".
Welcome! Please register for the webinar by entering your details below.

Webinar overview:
ARM recently announced the first two processors using the ARMv8-M architecture, ARM Cortex-M23 and Cortex-M33. ARM TrustZone for ARMv8-M adds security features to these cores that allow applications and services to operate securely while safeguarding the secure resources from being misused, corrupted or inspected by intruders. The webinar will explain how to program secure and non-secure domains on a processor with TrustZone.
Una parte importante para reducir la vulnerabilidad de sistemas embebidos. ARM me ha invitado a un webinario en el cual presenta las adiciones de funciones de seguridad de la empresa ARM, llamados TRUSTZONE, para controladores ARM Cortex M xx. Estas 2 nuevas versiones de controladores ARM ahora tienen que ser licenciados por proveedores de controladores ARM para realizar sus variedades propietarias.

Básicamente parece ser punto aceptado en la comunidad de desarrolladores de sistemas embebidos, que controladores con conexión al Internet, llamados "connected devices", requieren de la funcionalidad ya conocida para centros de cómputo, el aislamiento de aplicaciones y entornos. El reto especial es el hacer tal funcionalidad disponible en controladores para sistemas embebidos. Ya había escrito en otra parte es este foro, que la empresa Freescale, luego parte de NXP y finalmente con alta probabilidad de ser parte de la empresa Qualcomm, que los controladores del tipo i.MX8, disponibles para el público general en el primer cuartal del 17.

Se trata de que los programas responsables para suministrar el entorno virtual, hipervisores del tipo 1, también llamados "bare metall" por lo que el hipervisor es ejecutado directamente accediendo la hardware y no atraves de un os, requiere un entorno mas privilegiado aún que los núcleos de los os. Comunicación entre ese entorno super privilegiado usa sus propias instrucciones. Para hacer posible una comunicación entre ese entorno super privilegiado y el entorno de los núcleos de os, se usan también instrucciones especiales solo accesibles por los núcleos ejecutando en el entorno normal privilegiado. Así es posible que el entorno virtual aparentemente no existe, no es registrado, por el os, por ejemplo Linux.
Pero eso requiere que el entorno privilegiado tenga apoyos implementados en hardware del controlador. Uno es la MMU, unidad de management de la memoria. es requerimiento que la hardware tenga múltiples de estas unidades, para que cada entorno virtual traduzca sus direcciones de memoria lógicos a entornos asociados para los entornos virtuales. Lo mismo se requiere para acceso a la red y otros.
El reto hasta ahora a sido, que recién con la alta vulnerabilidad de sistemas embebidos conectados a la red, IoT, IIoT, Industry 4.0, aplicaciones medicas, aviación requieren de estas funcionalidades para poder ser operados responsablemente en conexión con el Intenet. Los ataques recientes a sistemas del tipo IoT y similar ha demostrado que es requerimiento establecer tales barreras para reducir su vulnerabilidad.
 
Hola amigos, ayer estuve en la feria e investigue de cual era la actitud de la industria de semiconductores hacia los métodos para reducir la vulnerabilidad de sistemas IoT…. conectado a las redes.
Básicamente tengo que expresar, que la gran mayoría de los presentes en la feria no saben nada al respecto. En cierto sentido no es sorprendente!
El primer producto que había identificado son los nuevos miembros de la familia de controladores "i.MX*" Resulta que la empresa aún NXP, Qualcomm aún requiere de la aprobación de su compra de NXP, ha seleccionado 5 clientes de primera prioridad, "Tier 1", para su introducción del "i.MX8"-. Aunque una ex colega está a cargo en Alemania, se por experiencia que tendré que esperar hasta el próximo año para poder acceder a datos mas detallados del producto. Valdrá la pena investigar el entorno y la IDE de para los productor "i.MX*" para estar bien preparado para cuando la i.MX8 esté disponible!
El otro resultado de mis investigaciones es, que aún domina el punto de vista en los proveedores que controladores, es que controladores con apoyo para la virtualización son caros y por lo tanto de segunda prioridad. También recibí el mensaje que aún muchos clientes no se han realmente ocupado lo suficiente con el tema de la reducción de vulnerabilidad en sistemas embebidos. Otro también me dijo, que para realizar productos de reducida vulnerabilidad es requerimiento que ya desde los primeros pasos de concepción y diseño de productos se tiene que integrar la protección contra vulnerabilidad. Estoy totalmente de acuerdo con ello.
Estoy convencido que se están desarrollando especificaciones que serán aplicadas por ley a todo diseño de sistemas conectados a la red. El costo y el peligro para toda la sociedad es inmenso si esto no ocurre! El reciente ataque a los Estados Unidos que usó mas de 1 millón de sistemas conectados a la red para su ataque es prueba de esto. Si observan, los gobiernos occidentales están armado "tropas" informáticas para protegerse de ataques de la red y para manejar la guerra informática. El éxito de Trump en las elecciones hay quién dice que Rusia tiene mucha responsabilidad para ello influenciando las elecciones publicando materia que desprestigiaba a la Clinton!
Yo, como viejo romántico y ferviente admirador del mundo iberoamericano, quiero mandar mi mensaje para que en este campo los latinos no seamos los últimos!
Queda por reportar un último aspecto que aprendí de mis investigaciones en la feria: El tema de la reducción de la vulnerabilidad es un tema muy complejo. Es requerimiento hacer esto accesible de forma amplia simplificando al máximo posible la implementación. Creo que habrá muy pronto una interfaz de programación, API, estandardizada y bibliotecas que implementan la funcionalidad ocultando así la complejidad del tema! En sistemas embebidos, de esto estoy convencido a razón de mis investigaciones hasta el día de hoy, es requerimiento indispensable la integración de funciones requeridas dentro de controlador. Estoy convencido que el tal presentado "alto costo" de la implementación de las funcionalidades es puramente un tema de "marketing"! Todos los controladores actuales están limitados, no por el espacio dentro del circuito integrado, core limited, sino por el número de pines requeridos, pad limited! Esto se puede verificar viendo como la implementación de múltiples núcleos en controladores se está volviendo estándar! La estandardización de las funcionalidades requeridas tiene muy alta probabilidad por el rol dominante de los núcleos de ARM. Los ARM Cortex M23 y ARM Cortex M33 son los primeros de integrar estas funcionalidades y así defecto se volverán estándar en la industria!
 
Última edición:
Los nombres de los diseños de Cortex M con las funcionalidades de la Trustedzone son.

ARM Cortex M23 y ARM Cortex M33. Extensa información ha sido publicado recientemente, buscar on Google los controladores mencionados.

También, finalmente, se empieza a encontrar extensa información de como usar controladores de los tipos mencionados. La empresa Keil, tiene excelentes datos al respecto. Recuerden, ARM no es proveedor de controladores, es proveedor de diseños que son licenciados por empresas del sector de semiconductores y que alrededor de la propiedad intelectual de ARM, aquí los 2 tipos nombrados, diseñan sus chips y SoCs!
 
Aquí el enlace a cursos de entrenamiento de NXP. Allí se menciona que los cursos empiezan a mitad de mayo! Eso debe ser indicativo, que NXP piensa hacer público los temas alrededor de sus implementaciones de la arquitectura ARM v8 y de como usar las funcionalidades relacionadas al Trustzone! Por si el acceder de estas páginas demandara identificarse, aquí el enlace:

https://training.nxp.com/courses

Aparentemente en el segundo quartal del 2017 la cosa es accesible para todos!
 
Aquí el enlace a un artículo sobre el mercado de controladores para IoT, que ve ARM con sus núcleos ARM Cortex M23 y 33 y su arquitectura ARMv8-M e Intel con sus Quark D1000 y D2000 como las 2 arquitecturas dominantes del IoT.
 
A mí es que siempre que leo IoT me parece la abreviatura de idiot.
Se ve que tengo la mente sucia.

Pues si, el futuro de todo conectado es presente ya mismo.
 
El establecer el entorno de un controlador "seguro", no es cosa trivial. Por eso creo que se recomienda usar un sistema operativo de tiempo real. Allí este, debe establecer ese entorno seguro y su documentación describir el como se pone el software de uno de forma correcta. No solo es el ejecutar el programa de forma segura, es el también establecer como se actualiza software en el entorno sin ofrecer así una puerta de entrada.
 
Hola a todos! Soy novato, he usado microcontroladores PIC, sobretodo para manejo de display's. Quiero un proyecto más avanzado, con un display más avanzado, más memoria RAM, etc... Quiero saber como podría crear mi propia placa base para ARM Cortex-A75, o cualquier otro Cortex-A. Estuve buscando en internet, pero encontré solamente para crear placas de desarrollo para microcontroladores. También busque algun blueprint de arduino 32 pero nada, alguien sabe como podría hacerlo? O en dónde encontrar lo que busco?? Gracias!
 
Si tienes el deseo, hazlo! Lo que tienes que aclarar para ti, es que es lo que quieres, buscas? Como Cristián escribe, hacer una placa para una componente con muchísimos pines es bastante difícil de hacer. Hace ya bastantes años cuando empecé a crear soluciones para mi hobby del modelismo naval, el mega8 AVR se podía comprar por 1 Euro y la placa era fácil de hacer y ese rea el método para tener una placa con un controlador lo mas barato posible. Bastante mas tarde me empecé a interesar por el controlador LPC1769 de NXP. Una placa con ese controlador, producido con calidad profesional se conseguía por menos que el costo de comprar el controlador como componente era mayor a comprar la placa LPC1769 de "Embedded Artists".
Y 2 aspectos aún reforzaban mi decisión de ir por la placas de "Embedded Artists":

1. Era la disponibilidad de la herramienta de programación que incluía la adaptación a las placas LPCXpresso y la disponibilidad completamente gratuito de la IDE y del CMSIS-DAP.

2. Era que con esas placas venía la placa que permite grabar y analizar los programas ejecutados en esas placas.

Ya los primeros controladores ARM M3 y M4 en comparación con el mega8 de avr eran casi que infinitamente mas potentes. Uno de los efectos de esto es que puede tener mucho sentido usar un os de tiempo real, como FreeRTOS y en conjunto con ello la librería del CMSIS. programando un controlador ARM usando las librerías de CMSIS pone a tu disposición un API, "Application Programming Interface" que permite ejecutar tu programa en cualquier controlador a base de ARM, ya que siempre la interfaz a las funcionalidades periféricas de los controladores es idéntico.

El querer programar un controlador ARM de la forma como programamos un Arduino es como tener un Ferrari y usar un buro para que lo jale!

Pero como si lo escrito aquí fuera poco, usar las funcionalidades de seguridad de controladores ARM basados en los ARM M23 y MC33 es otra dimensión de complejidad adicional.

Si buscas un controlador ARM de máxima potencia el sitio de Variscite y el de Toradex, los MX8 son controladores de máxima potencia, siendo el tipo Quad de los MX8 el mas potente. Son tantas las capacidades de estos controladores, que NXP y empresas como Variscite y Toradex ofrecen para sus placas software que facilita su uso en diversas aplicaciones. Desde que apareció el MX8 hasta el día de hoy su uso ha sido limitado a empresas capaces de tener equipos de ingenieros de especialización para las diversas funcionalidades. Hoy empiezan a ser disponibles entornos que fascilitan el uso de estos controladores para diversas aplicaciones.
 

Arriba