Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos » Arduino y Raspberry Pi
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

29/09/2016 #1

Avatar de Hellmut1956

Reflexiones y Conversación sobre Trustzone y hipervsor.
Hola amigos, resulta que como consecuencia de haber redefinido mi infraestructura informática de mi taller he descubierto para mi el tema de hypervisors y trustzone con foco a su adaptación en sistemas embebidos. me voy a meter de forma "real y física" con el tema de hipervisores del tipo 1, también llamados "bare metall" en el servidor. Publico aquí la imagen de la estructura muy burda, es la primera edición:



Tanto en mi PC, donde actualmente uso un i7 620, como con el Xenion X5550 a 2,67 GHz, uso procesadores con funcionalidad para operar hipervisor del tipo 1. Me compré 2 Xenion X5550 por solo 26,70 Euros incluyendo el costo del flete con LGA1366.

El hombrecito a la derecha abajo, yo y mi ordenador principalmente usa Windows 10, pero tengo un segundo disco duro con Ubuntu 16.04 TLS! Esto lo dejaré por ahora al menos, tal cual está. Ya estoy armándome el servidor con una placa madre ASUS P&t WS Professional a la cual le pondré unos de los procesadores Xenion 5550. Alí me voy a dedicar al reto de instalar el hipervisor tipo 1. Aún estoy investigando de que proveedor. Sobre el hipervisor pondré un entorno virtual con Windows 10 Pro y otra entorno virtual con Ubuntu 16.04 TLS.

Alguno de Ustedes ya tiene experiencias con hipervisores?

Por WiFi en el centro del gráfico ven las placas Raspi conectadas de forma inalámbrica con el servidor.

Aquí el enlace a un artículo muy interesante para mis objetivos y es que en controladores del tipo ARM Cortex basadas en la versión V8 la empresa ARM ha portado lo que llama Trustzone. Es funcionalidad de apoyo para la funcionalidad de hipervisor.

Voy a empezar a investigar cual proveedor ya es activo en este sector. las chances son muy buenas investigar en el entorno de los productos provenientes de Freescale en NXP. Esta es la parte del uso de la virtualización y el encapsulamiento lograble aislando partes de los programas en entornos virtuales proporcionados por estas funcionalidades.

Aquí un segundo artículo que consta de la "parte uno" y "la parte dos".

Esta serie de artículos a la que quiero sumar tales de la empresa "Mentor Graphics" se discute el tema de hipervisores como método de protección en sistemas embebidos con ejemplo a los entornos de sistemas embebidos en carros en general y de ciculación autónoma. Allí también cuentan que por ejemplo la industria de aviación ve en esta metodología una forma mas avanzada de proteger sus sistemas. Pero también las informaciones de la funcionalidad de hipervisores en sistemas embebidos, deep embedded, donde los tiempos de reacción de tiempo real parece exigir funcionalidad mas desarrollada aún para pasar la funcionalidad de hipervisor de la software a la hardware.

También me parece muy interesante las informaciones sobre la vulnerabilidad con foco en sistemas embebidos. Un ejemplo para esto que quiero presentar es el peligro que representa el poder acceder el sistema final por JTAG por ejemplo! Trustzone y mentor Graphics artículos hablan de la necesidad de implementar la funcionalidad de autorización a nivel de la hardware con instrucciones especiales que entonces son responsables cuando una funcionalidad de la software requiere comunicarse con software en la zona segura, Trustzone! Evidente me parece el ejemplo que dan cuando un evento exterior, que pudiera venir de un atacante, ejecuta una interrupción de alta prioridad. Entonces la hardware del controlador tiene que resetar el contenido de registros de la trustzone para impedir así el ingresar del atacante. Una vez que la ejecución vuelve al código ejecutado en la zona de seguridad, entonces la hardware tiene que poner los valores originales en los registros reseteados!

El IoT, IIoT o Industria 4.0 en conjunto con los múltiples núcleos en controladores modernos y que estos sistemas están conectados a redes y por lo tanto susceptibles a ataques. Pero también las interacciones de programas actuando en paralelo en diferentes núcleos hacen el tema de la seguridad y la programación adecuada algo supremamente mas complejo!

Quiero publicando esta contribución compartir estas informaciones. Pero también ojala encontrar foristas que también tienen conocimientos sobre el tema! El hilo creo que está bién aquí, pues las placas Raspis, en especial la RaspBerry Pi 3B que tiene un controlador ARM con las instrucciones de la versión V8. Veo que la implementación de la estructura informática de mi taller me da la posibilidad de meterme en esta materia para luego ver y analizar si la placas Raspi 3B en su SoC ya apoya tales funcionalidades! Con seguridad el tema, que parece estar en auge desde algún tiempo bastante reciente, será apoyado por modernas placas Raspi, siendo la 3B la primera que debiera tenerla! Como la sofisticación del tema impactará las implementaciones futuras, vale empezar a familiarizarse con el tema hoy, si fuera de interés.
10/10/2016 #2

Avatar de Hellmut1956

Parece que "XEN" es un hipervisor apropiado
Hola amigos. Investigando por que ruta avanzar en esto de materia de hipervisor me he encontrado una página que me está pareciendo apropiada para meterme en esto.



Un buen gráfico para mi representa un posible recurso de aprendizaje. este gráfico me parece demostrar de buena forma lo que es un "hipervisor tipo 1" y le da el nombre, "XEN", que el entorno de programación del hipervisor tiene. Aparentemente tanto Windows 10 como Ubuntu 16.04 TLS ya tienen la funcionalidad incluida para la cooperación con el hipervisor!

Si no mal recuerdo en mi contribución anterior el foco estaba en la temática del hipervisor de forma independiente de cual se podría usar. No digo que este camino me lleve a la meta, pero tal es cuando uno se mete en esto! Mi objetivo inicial es usar uno de los discos duros de mi ordenador de 160 GBytes como alternativa de donde arrancar el entorno.

El primer objetivo será ver como es que XEN es puesto en el disco duro y el ordenador arranque desde ese disco con XEN!

Primero quiero indicar los 2 entornos presentes.

El uno llamado "Dom0" es el entorno privilegiado. Recuerden que en mi primera contribución mencioné la interacción controlada por el hipervisor tipo 1. Esta consiste en hardware disponible en el procesador que resulta en un entorno privilegiado y instrucciones reservadas para este entorno y de una software, el hipervisor, que uso este entorno privilegiado para la administración del entorno de virtualización!

El otro llamado "DomoU" es el medio de comunicación entre los entornos virtuales, por ejemplo "Windows 10" y "Ubuntu" como sistemas operacionales huesped, aquí "Guest OS". usando instrucciones especiales disponibles como parte de la ampliación de procesadores para tales entornos virtuales para requerir algun servicio del entorno privilegiado.

Como pueden ver en el gráfico, en color "verde" esta lo que sería la placa madre, en mi entorno de aprendizaje sera la placa madre de mi ordenador. "XEN" entonces representa el hipervisor administrando la hardware de tal forma que los so's huesped, ahora en adelante lo llamaré "GuestOS" con sus "kernel", núcleos del os. La columna a la izquierda representa el hipervisor usando XEN para administrar la hardware y su "Dom0 Kernel" es el software privilegiado que representa la adminstración de los recursos de la hardware.

Allí, desde la consola las herramientas del hipervisor están disponibles para administrar el hipervisor.esto debe ser mi primer objetivo de llegar a este punto!
28/10/2016 #3

Avatar de Hellmut1956

%==Bague
Hola amigos, como habrán notado el tema de entender el como reducir la vulnerabilidad de sistemas embebidos ha sido un tema de gran interés para mí por haber sufrido ataques que rindieron mi PC inoperable usando las cosas que activé durante mis primeros experimentos con la placa Raspi! Ahora encontré un artículo muy interesante en específicamente la vulnerabilidad en sistemas embebidos. Este artículo, doy el enlace de donde poder descargarlo como pdf, pone en contexto los temas de vulnerabilidad.

Como el artículo es en Inglés y como el tratar de presentar el mensaje de este artículo en Español es buen ejercicio para profundizar mi entendimiento de su contenido, trataré de presentar aquí el tema. Claro, un artículo con referencia a otro nunca alcanza la calidad del original, este intento tiene como propósito adicional el presentar un tema a aquellos no tan fluidos en el idioma Inglés, que ganará en importancia en un cercano futuro.

El artículo original tiene el título:

Securing modern-day devices with Embedded Virtualization and ARM Trustzone Technology
El primer paso del artículo quiere definir en que relación equipos IoT están referente a su vulnerabilidad y para ello da 3 ejemplos. La razón para presentar el tema del artículo empezando por presentar 3 tipos de equipos IoT y así presentar que clase de vulnerabilidad sistemas IoT tienen. También pone en relación el costo de tales productos IoT y de los mecanismos de protección. Si un equipo IoT cuesta 2 Euros invertir 10 Euros para reducir su vulnerabilidad no tiene sentido. Mecanismos de reducción de vulnerabilidad por lo tanto también tienen que estar en una sana relación al costo del equipo y al monto disponible para reducción de su vulnerabilidad.

Uso el término de vulnerabilidad como término que presenta que potencial de ser víctima de una ataque un equipo tiene. Existen varios conceptos que ayudan el recopilar los objetivos de una reducción de vulnerabilidad. 2 de estos presento ahora:

1. CIA

Aquí doy el enlace a un glosario en Español y si van a los puntos bajo "C" encuentran el tema CIA presentado en Español.

CIA
Véase: CID. Acrónimo inglés de confidentiality, integrity y availability, las dimensiones básicas de la seguridad de la información.
C = confidencialidad

Confidencialidad
(Inglés: Confidentiality). Propiedad de la información de no ponerse a disposición o ser revelada a individuos, entidades o procesos no autorizados.
I = integridad

Integridad
(Inglés: Integrity). Propiedad de la información relativa a su exactitud y completitud.
A = disponibilidad (availabilty)

Disponibilidad
(Inglés: Availability). Propiedad de la información de estar accesible y utilizable cuando lo requiera una entidad autorizada.
Estas definiciones no me gustan del todo pues creo que no presentan la explicación de ejemplos relacionados a cada punto. Pero es la forma usada por recursos oficiales. Quiero dar el enlace a un curso gratuito sobre criptología de la Universidad de Stanford
28/10/2016 #4

Avatar de Dr. Zoidberg

Hellmut1956 dijo: Ver Mensaje
Estas definiciones no me gustan del todo pues creo que no presentan la explicación de ejemplos relacionados a cada punto. Pero es la forma usada por recursos oficiales. Quiero dar el enlace a un curso gratuito sobre criptología de la Universidad de Stanford
Esas "definiciones" que mencionás son los pilares estándar para la implementación de la Seguridad Informática en una instalación, y su significado es muy simple y conciso:
  • Confidencialidad: nadie debe acceder a lo que no le corresponde acceder.
  • Integridad: La información debe mantenerse completa y "precisa" --> Debe estar bajo control según el punto anterior.
  • Disponibilidad: La información debe estar disponible donde y para quien la necesite, sujeto a las restricciones anteriores.
Y esas "definiciones" abarcan absolutamente todo lo que se refiere a la protección de la información. Lo que sucede con ellas es que son definiciones de alto nivel, y para bajarlas a la tierra hay que definir lo que se llama "Políticas de Seguridad Informática" que básicamente son conjuntos de documentos que definen lineamientos sobre temas específicos de seguridad, como por ejemplo "Política de Usuarios, Contraseñas y Perfiles de Operación" que está relacionado con la Confidencialidad y la Integridad, o "Política de Backup de Información", que está relacionada con la Disponibilidad.

Y así en adelante...

PD: Estuve cuatro años a cargo de la seguridad informática de un gran centro de cómputos de un organismo gubernamental en Argentina, así que esta historia de "los pilares" la conozco bastante bien.
28/10/2016 #5

Avatar de Ardogan

A la pucha Hellmut... primera vez que veo esto de hiper-visores para sistemas embebidos.

Tu laboratorio dentro de poco se va a convertir en una atracción futurista para los electrónicos más básicos como yo
Estaré más que interesado en ver como vas progresando con tu setup

Aja... mover el hypervisor de software (cortex A) a hardware de micros... acá estoy mirando las primeras páginas de este pdf para revisar algun concepto.

Ok... el tema es interesante, pero creo que el campo de aplicación es algo mucho más grande que lo normal: vehículos autónomos, automatización de fábricas/almacenes conectados a la red, sistemas de comunicaciones de banda ancha, organizaciones que precisen preservar muy bien secretos comerciales/info de usuarios/información crítica.

¿Parecería un poco alejado de lo que vería un electrónico común y corriente?, ¿o (muy probablemente) me equivoco y es algo que se empezara a ver más en hogares y empresas pequeñas?
Solo escribo las preguntas que pasan por mi cabeza, cualquiera que haya leído 5 minutos más que yo (un gran total de media hora ) va a poder ponerme en mi lugar bien rápido...

Paso al 2do mensaje Hellmutiano
Estoy pensando en cual es tu objetivo... diría que automatizar el laboratorio de forma super-segura para que Don Hellmut pueda minar bitcoins a raudales
Pero viendo arduinos y puntos de acceso inalámbricos sería para automatizar el laboratorio lo más que se pueda de forma segura o algo así.

Tercer mensaje...
Aaaaahhhh... te atacaron via internet?, la PC que tenías conectada a la raspy. Bueno, ahí ya hay una fuerte motivación para no sufrir más daños.
¿Pero fue algo normalmente evitable? no me quiero meter donde no corresponde, pero quizás si es la misma máquina para trabajar que para usar el facebook que para tenerla de servidor... bueno, dividirse la red en zona segura y DMZ, ¿jugar con la arquitectura de red doméstica?
Solo quería plantear eso último, no esta bien meterme a especular con la privacidad de cada uno.

Es decir, al final ya se ve clara mi cuestión, ¿no es demasiado hardware para un taller de electrónica?
28/10/2016 #6

Avatar de Hellmut1956

@Dr. Zoidberg: Quien sabe y está familiarizado con el tema, las explicaciones de los términos son completas y correctas. El punto es que yo, y quizá algún otro lector de este hilo, por ejemplo Ardogan, no familiares con el tema, necesitan ejemplos mas plásticos para captar el alcance de estos términos! Pero el énfasis que yo tengo en la materia es en el uso de estos mecanismos en sistemas embebidos. En el campo de centros de cómputo y de servidores estas técnicas se aplican y se desarrollan en grandes pasos! Ssistemas altamente embebidos, donde el hardware ofrece recursos mucho mas limitados, y esto es aplicable a dispositivos "IoT". Las experiencias recientes, la cada vez mas alta calidad de los atacantes y los miles de millones de equipos IoT, hay quien habla de "trillones", millones de millones de dispositivos IoT e IIoT, las cada vez mayores capacidades de los controladores usados, requieren de reducir al máximo la vulnerabilidad de sistemas embebidos. Al momento solo tengo noción de los controladores i.mx6, que tienen implementadas funciones de apoyo de la virtualización en hardware, lo que reduce la complejidad de la software. Hay quien escribe que solo el apoyo masivo de la virtualización, del aislamiento, en la hardware de un controlador permite reducir los riesgos de vulnerabilidad de los equipos IoT! es mas, como estoy seguro bien sabes, recientemente los estados unidos sufrieron graves daños debido a un atacante que uso millones de dispositivos embebidos para su ataque!

El proliferar de dispositivos IoT, dispositivos accesibles desde la nube a millones de millones de dispositivos y las cada vez mayores capacidades y recursos de los controladores en estos dispositivos hace que este tema, que fuera tema de pocos en oficios como el que tu tenías, alcance la realidad profesional de muchísimos. Viendo las dificultades que me he encontrado al investigar el tema de la virtualización y del aislamiento como método de protección de equipos embebidos, opino que este medio es un buen camino para hacer conscientes del tema a nuestros compañeros de habla hispana! Tus conocimientos y tus experiencias con seguridad pueden enriquecernos a todos aquellos con voluntad de dedicarse al tema. Yo voy a usar la feria "electronica 2016" aquí en Munich a mitad de noviembre para informarme sobre el tema y encontrar recursos adicionales. lo que mas quisiera encontrar es una placa similar a la raspi con un controlador que tenga el apoyo en hardware lo mas sofisticado posible!

@Ardogan: Ojalá note he ofendido poniéndote a ti y a mi persona como individuos no experimentados del tema y quienes se benefician de ejemplo concretos. pero quiero responderte a tu referencia a que objetivos tengo!

La temática de la protección de sistemas embebidos requerirá el hacer tales sistemas parte del IoT y por lo tanto la inmensa mayoría de sistemas en un futuro muy próximo tendrá que contener el apoyo de la virtualización y aislamiento.

Como ya no puedo trabajar en la industria por razones de salud y por los daños que sufrí debido a varios paros cardíacos, el estudiar, investigar y aplicar en experimentos tiene la función de mantener y recuperar mis capacidades mentales, de llenar mi vida con objetivos que me fascinen y así mantener un estilo de vida organizado. Típico alemán, según dicen!

Empecé con el modelismo naval y allí con la construcción y diseño del modelo de un velero. Después de varios años, en los cuales aprendí y desarrollé mis capacidades de modelismo físico, el querer realizar un sistema de control de escotas que permita operar el control de escotas y por lo tanto la posición de las velas. esto fue el punto inicial, después de aprender a realizar mis propios circuitos electrónicos, de reactivar mis capacidades de programación y de estudiar por ejemplo la funcionalidad de un motor de paso en detalle, me embarqué en la materia de modelación de partes de mi sistema de control de escotas, lo que después de varios cominos me llevo a decidirme por la software de Wolfram Software, Mathematica y SystemModeler. Mathematica me da una herramienta muy poderosa matemática que se requiere para desarrollar los algoritmos y del SystemModeler que permite modelar un sistema de multiples dominios, mecánico, eléctrico, etcétera usando el lenguaje de modelación "Modelica. Como el modelar exige el verificar la funcionalidad del modelo en comparación a la realidad física, me encontré con las técnicas de HiL y SiL, Hardware-in-the-Loop y Software-in-the-Loop"! Como estos temas aún eran muy rudimentariamente apoyados por las funcionalidades de Mathematica y SystemModeler, me decidí por usar la plataforma que mejor apoyaban estas herramientas entonces, las placas Raspi!

Así me encontré con la necesidad de aprender e investigar el como usar estas placas en combinación con un PC como sistema de desarrollo. Así empecé a inestigar y experimentar este entorno, muy pronto siendo capaz de manejar las placas Raspi desde mi PC y hacerlas accesibles desde el Internet. De lo que me descuidé, por creer estar seguro debido a que mi PC con Windows siempre era en la versión mas actual y utilizando herramientas de protección. resulta que de pronto mi PC con Windows se llenaba de aplicaciones de una utilidad de Windows al punto que dejaba de ser posible el solo escribir un texto en un editor, debido a que los caracteres aparecían después de casi un minuto. Tratando de usar los caminos disponibles para reparar esto no tuve éxito. Por esta razón me decidí de actualizar mi Windows 7 Ultimate a Windows 10 Pro. esto me recuperó mi PC.

Así me decidí por estudiar Linux, el os de Raspi y de las técnicas de protección. Me metí en algo para mi nuevo y como siempre me acabó fascinando y despertando mi apetito por nuevos conocimientos! Así en algún momento me encontré con la temática de hipervisores al tratar de aprender de forma metódica el como el programar y experimentar en entornos virtuales. Cosa que descubría muchos programadores hacen para no poner en peligro la funcionalidad de su PC! Estudiando el tema de hipervisores muy pronto encontré que el procesador de mi PC efectivamente ya tenía en hardware apoyo para la virtualización. Muy pronto me encontré con que la virtualización con hipervisores y contenedores como el método establecido por centrales de cómputo, donde los clientes no reciben su servidor físico individual, sino que reciben entornos virtuales no diferenciales de sistemas físicos. Es mas, estos entornos pueden ser transferidos a otro servidor físico aún cuando tales entornos virtuales están activos.
Leyendo sobre los mecanismos de apoyo que la empresa ARM desarrolla para sus productos ofertados y leyendo en mayor detalle en que consisten los elementos de apoyo en Hardware para la virtualización, pude ver que estas funcionalidades desarrolladas por ARM bajo el concepto de "TrustedZone", solo son opcionales para aquellos que toman licencia de los núcleos de ARM. Entre otros, los núcleos en la nueva placa Raspi 3B, son apoyados por ARM para la implementación de funciones de apoyo de la virtualización. Pero con excepción de los controladores i.mx6 la documentación de ningún proveedor de controladores contiene referencia a estas funcionalidades. Así el articulo reverenciado al principio de esta contribución que combina TrustedZone y sistemas embebidos resaltó al punto que me decidí por publicar esto.

Creo que el tema de la reducción de la vulnerabilidad de sistemas embebidos en el ámbito del IoT usando virtualización y aislamiento es tan reciente, que todavía no existe un amplio apoyo. Pero la necesidad de volver sistemas IoT mas seguros, menos vulnerables, no permitirá sistemas IoT sin tales mecanismos. Yo creo que el futuro de sistemas embebidos en la inmensa mayoría de los casos deberán ser sistemas IoT y por lo tanto tendrán que usar estos mecanismos de protección!
28/10/2016 #7

Avatar de Dr. Zoidberg

A ver....
La idea de los hypervisors tipo 1 es buena, pero no para proteger, sino para poder separar los dominios de un problema cuando se lo resuelve con uno o más programas. Esta separación "ayudaría" a que si un subsistema es vulnerado esa vulnerabilidad (o el ataque) no se propague a otros subsistemas (hardware + software).
Por supuesto que esto no es automático ni mucho menos, por que si consideramos un sistema embebido que soporte virtualización e hypervisors aún nos queda hacer los programas que permitan que el sistema embebido cumpla con las función para la que fué creado, y eso corre en las manos de los diseñadores de software y los programadores.... y ese es precisamente punto débil del asunto: personas con mucha formación en las ciencias electrónicas pero no-muy-buenas para programar o tipos con formación en ciencias de la computación pero con fallas importantes al tiempo de interactuar con el hardware.... en general. A eso hay que sumarle la escasa experiencia en programación concurrente, que si bien no es exactamente el caso de los hypervisors es terriblemente parecido cuando se pretende intercomunicar los diferentes programas entre sí. Ni hablar si dos programas "independientes" (en diferentes VM) entre sí necesitan acceder al mismo componente de hardware... que el hypervisor debe haber virtualizado, o bien cuando necesitan intercambiar información. Estas cosas mas o menos se solucionan si se dispone de un hypervisor o un sistema operativo avanzado (+hardware) que soporte los mecanismos de virtualización, pero este tipo de cosas no es muy común en sistemas embebidos.

Digo.... la virtualización puede ayudar a "contener" (no proteger) los ataques, pero eso exige una política de desarrollo de software y capacitación bastante sofisticada que no cualquiera puede afrontar
28/10/2016 #8

Avatar de Hellmut1956

%==Bague
@Dr. Zoidberg: Quiero darte el enlace a una serie de artículos sobre el tema de seguridad aquí!

Este artículo y subsiguientes de la misma serie sobre el tema trata muy a fondo el tema de los "threats" en diferentes puntos de un sistema. Como seguro bien sabes, los peligros que impactan la vulnerabilidad de sistemas está intensamente relacionada a diferentes estados del sistema a analizar. Empieza con el acceso a una parte usando los métodos del "debug" y sigue hasta los aspectos relacionados con la comunicación, pasnado por diversos estados operativos de un sistema.

Por un lado el reto de sistemas IoT, que por definición están conectados a la red, son los limitados recursos, los medios económicos muy reducidos por unidad debido al bajo precio de los sistemas que limitan que tipo de protección tiene sentido.

Pero también el aspecto que mencionas que un tal sistema embebido tiene que cumplir sus funciones y eso dentro del entorno de tiempo real que frecuentemente tiene lugar en tales sistemas. El asunto se vuelve hasta mas complejo cuando se analiza la situación en Socs como aquel en el Raspi que tienen por ejemplo hasta 4 núcleos, o de controladores como aquellos de NXP, heredado de Freescale, los i.mx6 a 8. que al igual de otros controladores tienen núcleos diferentes, como ARM A7, 4 cores en el i.mx8, 2 ARM Cortex M4F mas GPUs. El pdf de Mentor Graphics al que doy el enlace al principio de mis contribuciones de hoy, pero también otra parte de los artículos de la revista "Semiconductor Engineering", trata el tema de los threats y del aislamiento al tiempo de analizar los áreas adicionales abiertos a ataques que resultan de como se organiza la software en tales sistemas embebidos.

Mucho me gusta la comparación de las imagenes 7 y 8 de la página 7 del pdf. Allí se compara y se analiza la vulnerabilidad de IoT de múltiples núcleos. En la imagen 7 se presentan las barreras que debe tener tal sistema en su hardware y consiguiente en lo que llama "Monitor!. En la imagen 7 cada sistema de un núcleo contiene tanto la funcionalidad del entorno seguro, "Secure World" y de "Normal World". Muy bien describe que requerimientos debe cumplir la software del entorno seguro y que es altamente deseable de mantener la cantidad de código lo mas limitado posible, para así poder lograr la verificación de la seguridad de la software que por definición debe estar libre de errores y de limitar al máximo los áreas de ataque. El Monitor es lo equivalente a un hipervisor del tipo 1m pero que maneja de forma separada el flujo de datos y de instruciones, L1 D y L1 I. Los 3 bloques debajo de la imagen del bus interno, Snoop Control Unit, presenta que es hardware la que monitorea si quien accede tiene el derecho a ello. El bloque "Integrated Interrupt Controller y Distributor" tiene la función de evitar el ataque usando el estado de servicio de interrupciones.

Dentro del artículo se escribe que en sistemas IoT seguridad solo es posible si esta es realizada en Hardware. vale la pena lleer en detalle de como aplicaciones en el entorno "Normal" pueden comunicarse con el entorno protegido. Y que toda software que acceda al entorno protegido a su vez tiene que ser "segura! Esto viene muy unido al concepto de privilegiada ejecución requerido en sistemas que se aproximen a lo que ARM denomina "Trustedzone". Todos conocemos de un sistema Linux por ejemplo el núcleo o Kernel de Linux se ejecuta en un nivel privilegiado y los programas normales en un entorno de menos privilegio. En sistemas que apoyan la virtualización y el aislamiento algo que llamemos "hipervisor" es ejecutado a un nivel mas privilegiado que aquel en el cual opera el Kernel de Linux! Así un programa el el entorno normal está ejecutando las instrucciones de su código que exclusivamente relacionadas al entorno normal. Servicios especiales que usan instrucciones especiales privilegiadas se comunican con el programa en el entorno normal y de allí pueden pasar datos al entorno super privilegiado del hypervisor. Solo usando estas instrucciones especiales reservadas por el servicio es posible comunicarse con el hipervisor ejecutado en el nivel de super privilegio.
Tienes toda la razón cuando escribes que los entornos virtualizados aislan código ejecutado en ellos y hasta los controladores ARM Cortex Mx usan la hardware de la MMU, "Memory Management Unit", para restringir el acceso de un entorno fuera del área de la memoria asignada a el y así logran un aislamiento. Pero cuando controladores como actualmente solo conozco de las especificaciones del controlador i.mx8 de antes Freescale, ahora NXP y pronto Qualcomm, implementan un repertorio mucho mas amplio de protección.
Creo que resulta excesivo si trato con medio conocer, para exagerer, tratar de presentar todos los aspectos que los artículos mencionados presentan. Pero los artículos de "Semiconductor Engineering" tratan el tema extensivamente analizando y presentando todas las áreas de ataque y los métodos de ataque relacionados a cada área de ataque.
Creo, eso sí, poder contradecirte, si lo he entendido bien, sobre estimas el role de la software. Si aceptamos lo escrito en los artículos reverenciados por sendos enlaces en mis contribuciones, una protección total es imposible en cualquier sistema en contacto con el Internet. Lo único que se puede lograr es reducir la probabilidad de éxito de ataques o de hacerlos tan "caros", refiriéndose a los recursos de computación, por ejemplo que se requieren, que el atacar con éxito no es justificable para el atacante en la mayoría de los casos.
Igualmente creo que concordamos que el punto de defensa mas debil de todo sistema esta en el ser humano que tiene acceso al sistema!
Así se expresa en los artículos, que el lograr un nivel de seguridad necesario para equipos del IoT requiere y exige que la hardware ofrezca los servicios mas extensos posibles para reducir la vulnerabilidad.
Creo que hay una gran diferencia entre la situación de vulnerabilidad y de los métodos requeridos para su reducción a un nivel tolerable para un mundo con miles o millones de millones de equipos IoT, comparado con la ya casi madura situación en centros de cómputo, donde los recursos económicos para establecer una baja vulnerabilidad son casi infinitos y la posibilidades de sub-sistemas de protección pueden costar miles de Euros por unidad!
28/10/2016 #9

Avatar de Dr. Zoidberg

Es que, a fin de cuentas, es como todo lo que nos rodea: la famosa relación costo/beneficio.
La seguridad absoluta no existe, independientemente de la cantidad de hardware que se agregue en el camino. Por ejemplo, como ya comentamos, la virtualización me permite "reducir el área de impacto" de una vulnerabilidad por que me permite aislar tareas entre sí creando una máquina virtual para cada una de ellas, sin embargo, la exposición de vulnerabilidades por código mal diseñado sigue presente. La "Trusted Zone" permite partir la ejecución en, por así decirlo, procesos de confianza y procesos sin-confianza, dando privilegios a los primeros y quitándoselos a los segundos. Sin embargo, la necesidad de comunicación entre ambos es otra fuente real de potenciales vulnerabilidades. La gente de ARM parece que viene trabajando mucho en esto, así que habrá que analizar hasta donde ha llegado.
Como comenté antes, esto no "protege" al dispositivo IoT sino que atenúa (en mas o en menos por que depende del diseño del software) los efectos de una vulnerabilidad explotada en un ataque, lo que NO ES POCA COSA!!!, pero las viejas herramientas de detección y prevención de ataques (NDIS, firewalls, etc) siguen siendo válidas... al menos por ahora, para proteger de forma efectiva una instalación de estos aparatitos. Por ejemplo, un firewall stateful completamente convencional e incluido en el propio kernel Linux (el famoso iptables) basta para evitar ataques desde Internet... o de la red local, da lo mismo, sin quitar la posibilidad de acceso.
Lo otro que hace falta es una plataforma y estructura de red de datos donde estos bichitos puedan vivir sin estar expuestos a los "depredadores".... por ejemplo, si mi heladera tiene la posibilidad de hacer pedidos al supermercado para reponer comestibles y "bebestibles", no tiene caso exponerla mediante un enlace IoT tipo 4G (por decir algo) sin protección y con IP públicas cuando puedo protegerla detras de un router wifi con firewall.

Opino que todas estas cosas están muy buenas (es un terrible avance tecnológico para los sistemas embebidos), pero me parece que la gente de marketing le está agregando demasiado humo a la venta.
28/10/2016 #10

Avatar de Ardogan

Hellmut1956 dijo: Ver Mensaje
...y esto es aplicable a dispositivos "IoT". Las experiencias recientes, la cada vez mas alta calidad de los atacantes y los miles de millones de equipos IoT, hay quien habla de "trillones", millones de millones de dispositivos IoT e IIoT, las cada vez mayores capacidades de los controladores usados, requieren de reducir al máximo la vulnerabilidad de sistemas embebidos. Al momento solo tengo noción de los controladores i.mx6, que tienen implementadas funciones de apoyo de la virtualización en hardware, lo que reduce la complejidad de la software. Hay quien escribe que solo el apoyo masivo de la virtualización, del aislamiento, en la hardware de un controlador permite reducir los riesgos de vulnerabilidad de los equipos IoT! es mas, como estoy seguro bien sabes, recientemente los estados unidos sufrieron graves daños debido a un atacante que uso millones de dispositivos embebidos para su ataque!
Sí... esta fresco el caso del ataque usando cámaras de video que, por sus propias necesidades (transmitir video en tiempo real), son capaces de usar ancho de banda mucho mayor que cualquier otro dispositivo en red.

Pero el rango de aplicaciones IoT es enorme, desde un termómetro remoto (un paquete cada una hora) en comparación a la cámara de seguridad.
Uno funciona con pila botón, la electrónica propia palidece frente a lo que habría que poner para tener una comunicación inalámbrica segura, y el costo se multiplicaría decenas de veces solo por conectarlo en forma segura. Quizás en el caso del termómetro ni siquiera importa que alguien pueda espiar el dato, no es información crítica.

En cambio el caso de cámara de seguridad: quiero altísima confiabilidad, buen ancho de banda, tiempo real, redundancia para que no se cuelgue nunca, no quiero que alguien desde fuera del banco pueda ver las imágenes, etc. Ahí si estoy dispuesto a invertir más para cumplir con mis requisitos.

Quiero decir, que no hay una solución que sirva para tanta diversidad de aplicaciones. Algunos serán dispositivos super-seguros, otros priorizarán poder funcionar con una pila botón, otros ni siquiera se molestan en que terceros puedan ver fácilmente la información que están enviando...

Hellmut1956 dijo: Ver Mensaje
@Ardogan: Ojalá note he ofendido poniéndote a ti y a mi persona como individuos no experimentados del tema y quienes se benefician de ejemplo concretos. pero quiero responderte a tu referencia a que objetivos tengo!
Estimadísimo Hellmut, para nada!!! no logro ver de qué manera habrías podido ofenderme, faltaba más mi amigo.
Por supuesto que no tengo ninguna experiencia en estos sistemas complejos, es tan claro como el agua , y en verdad es la primera vez que escucho de estos esquemas super-seguros en micros ARM.

Y si digo alguna tontera estoy más que feliz de que me corrijan, qué mejor favor me podrían hacer que invertir tiempo en rectificarme u orientarme. Más que agradecido .

Y recuerdo tu situación de otros temas que has iniciado en el foro, de allí que dije que querías ver de poner un laboratorio electrónico en casa de primera línea.

Hellmut1956 dijo: Ver Mensaje
La temática de la protección de sistemas embebidos requerirá el hacer tales sistemas parte del IoT y por lo tanto la inmensa mayoría de sistemas en un futuro muy próximo tendrá que contener el apoyo de la virtualización y aislamiento.

Como ya no puedo trabajar en la industria por razones de salud y por los daños que sufrí debido a varios paros cardíacos, el estudiar, investigar y aplicar en experimentos tiene la función de mantener y recuperar mis capacidades mentales, de llenar mi vida con objetivos que me fascinen y así mantener un estilo de vida organizado. Típico alemán, según dicen!
He trabajado con alemanes alguna vez, NUNCA aprendí tanta disciplina de trabajo como entonces, filosofía de: no excusas, sin vueltas (ya viste como somos los rioplatenses), hay que aprovechar el tiempo de trabajo, buen uso de herramientas, no sacar una tuerca de 1/2" con una llave de 13mm.
¿Cometiste un error?, nadie te va a echar del trabajo por eso, somos humanos, pero tu responsabilidad profesional es aprender del error, y ver la forma de que no vuelva a pasar. Y de vuelta, sin excusas, no hay tiempo para eso ni nos interesa hacer cacería de brujas

Al principio yo mismo tuve el impulso de buscar justificaciones si no lograba hacer algo de forma correcta o lo hacía fuera de tiempo, lamentablemente eso es algo que muchos latinoamericanos hacemos desde niños y casi como que es una marca cultural.
Luego decidí exponer los problemas de forma plana y simple y... una maravilla, nadie se puso a "retarme" ni nada de eso, si hay un alemán del otro lado estoy tranquilo de que traen la mentalidad de resolver problemas como una marca genética, mientras tanto aquí tenemos la cultura de la excusa (a veces justificada, pero a veces no).

Hellmut1956 dijo: Ver Mensaje
Empecé con el modelismo naval y allí con la construcción y diseño del modelo de un velero. Después de varios años, en los cuales aprendí y desarrollé mis capacidades de modelismo físico, el querer realizar un sistema de control de escotas que permita operar el control de escotas y por lo tanto la posición de las velas. esto fue el punto inicial, después de aprender a realizar mis propios circuitos electrónicos, de reactivar mis capacidades de programación y de estudiar por ejemplo la funcionalidad de un motor de paso en detalle, me embarqué en la materia de modelación de partes de mi sistema de control de escotas, lo que después de varios cominos me llevo a decidirme por la software de Wolfram Software, Mathematica y SystemModeler. Mathematica me da una herramienta muy poderosa matemática que se requiere para desarrollar los algoritmos y del SystemModeler que permite modelar un sistema de multiples dominios, mecánico, eléctrico, etcétera usando el lenguaje de modelación "Modelica. Como el modelar exige el verificar la funcionalidad del modelo en comparación a la realidad física, me encontré con las técnicas de HiL y SiL, Hardware-in-the-Loop y Software-in-the-Loop"! Como estos temas aún eran muy rudimentariamente apoyados por las funcionalidades de Mathematica y SystemModeler, me decidí por usar la plataforma que mejor apoyaban estas herramientas entonces, las placas Raspi!
Sí señor, vengo siguiendo tus intereses de modelado hace un tiempo largo, y tu entusiasmo inspira a probar cosas nuevas y no quedarse con lo poco que uno sabe (o al menos cree saber).


Hellmut1956 dijo: Ver Mensaje
Así me encontré con la necesidad de aprender e investigar el como usar estas placas en combinación con un PC como sistema de desarrollo. Así empecé a inestigar y experimentar este entorno, muy pronto siendo capaz de manejar las placas Raspi desde mi PC y hacerlas accesibles desde el Internet. De lo que me descuidé, por creer estar seguro debido a que mi PC con Windows siempre era en la versión mas actual y utilizando herramientas de protección. resulta que de pronto mi PC con Windows se llenaba de aplicaciones de una utilidad de Windows al punto que dejaba de ser posible el solo escribir un texto en un editor, debido a que los caracteres aparecían después de casi un minuto. Tratando de usar los caminos disponibles para reparar esto no tuve éxito. Por esta razón me decidí de actualizar mi Windows 7 Ultimate a Windows 10 Pro. esto me recuperó mi PC.
Sí, me ha pasado. En gran parte por eso ya desde 2009 nunca más utilice Windows en mis máquinas.
Y agrego más, últimamente Ubuntu me está dando demasiados dolores de cabeza, tengo que determinar aún si el problema es el usuario (yo) o el sistema, pero antes no me pasaba.

Hellmut1956 dijo: Ver Mensaje
Así me decidí por estudiar Linux, el os de Raspi y de las técnicas de protección. Me metí en algo para mi nuevo y como siempre me acabó fascinando y despertando mi apetito por nuevos conocimientos! Así en algún momento me encontré con la temática de hipervisores al tratar de aprender de forma metódica el como el programar y experimentar en entornos virtuales. Cosa que descubría muchos programadores hacen para no poner en peligro la funcionalidad de su PC!
Sí, y también para poder emular distintos sistemas sobre una misma máquina. Ejemplo: programar en una máquina con Windows para el sistema iOS de Apple, o para un servidor Linux...
Pero aquí me estoy refiriendo solo a máquinas virtuales (VM) que se ejecutan arriba del sistema operativo. De hecho es normal que alguien se encargue de configurar todo el entorno de desarrollo (IDE, sistema operativo, compilador, librerías, configuración de hardware) en una unidad de disco virtual y luego trabajar todos sobre la misma máquina virtual.

Hellmut1956 dijo: Ver Mensaje
Estudiando el tema de hipervisores muy pronto encontré que el procesador de mi PC efectivamente ya tenía en hardware apoyo para la virtualización. Muy pronto me encontré con que la virtualización con hipervisores y contenedores como el método establecido por centrales de cómputo, donde los clientes no reciben su servidor físico individual, sino que reciben entornos virtuales no diferenciales de sistemas físicos. Es mas, estos entornos pueden ser transferidos a otro servidor físico aún cuando tales entornos virtuales están activos.
¿No estaremos hablando de lo mismo?.
Recuerdo haber escuchado que los procesadores tenían modo supervisor y modo usuario desde los '90 (cuando yo iba a la secundaria ). Si mal no recuerdo la idea era que había recursos (interrupciones de hardware, espacios de memoria, código de drivers) que solo queremos que los use el sistema operativo (modo supervisor) y no las aplicaciones que corren encima del sistema operativo (modo usuario).

Esto de ARM me parece que apunta a otro objetivo distinto: agregar una capa abajo del sistema operativo, ejecutar a la par todo aquello que precise respuesta en tiempo real (bare metal como con un micro pequeño), y que el sistema operativo no esté como intermediario entre el código de tiempo real y el hardware.

Y por supuesto, agregar seguridad para que una aplicación que usa el sistema operativo no pueda acceder a los recursos que usa el código de tiempo real.

Hellmut1956 dijo: Ver Mensaje
Leyendo sobre los mecanismos de apoyo que la empresa ARM desarrolla para sus productos ofertados y leyendo en mayor detalle en que consisten los elementos de apoyo en Hardware para la virtualización, pude ver que estas funcionalidades desarrolladas por ARM bajo el concepto de "TrustedZone", solo son opcionales para aquellos que toman licencia de los núcleos de ARM. Entre otros, los núcleos en la nueva placa Raspi 3B, son apoyados por ARM para la implementación de funciones de apoyo de la virtualización. Pero con excepción de los controladores i.mx6 la documentación de ningún proveedor de controladores contiene referencia a estas funcionalidades. Así el articulo reverenciado al principio de esta contribución que combina TrustedZone y sistemas embebidos resaltó al punto que me decidí por publicar esto.
Creo que el tema de la reducción de la vulnerabilidad de sistemas embebidos en el ámbito del IoT usando virtualización y aislamiento es tan reciente, que todavía no existe un amplio apoyo. Pero la necesidad de volver sistemas IoT mas seguros, menos vulnerables, no permitirá sistemas IoT sin tales mecanismos. Yo creo que el futuro de sistemas embebidos en la inmensa mayoría de los casos deberán ser sistemas IoT y por lo tanto tendrán que usar estos mecanismos de protección!
Bueno, aquí es donde yo veo que tenemos opiniones distintas.
No pienso que esto sea para cualquier aplicación IoT, en los 2 casos extremos que mencioné arriba, sí puede servir para la cámara de seguridad, pero no creo que se use para un termómetro remoto barato y que funcione a pilas.

Hago una comparación burda. Una cosa es querer proteger tu Mercedes Benz ultimo modelo en Argentina y otra distinta es querer proteger la bicicleta.
Para el automóvil voy a contratar una cochera segura, poner un rastreador GPS en caso de robo, contratar auxilio mecánico en todo el país, y hacer todos los servicios de mantenimiento preventivo tal cual dice el manual.
Para la bicicleta... durante el día bien podría dejarla encadenada a un árbol a la vista de mi amigo del kiosco, y a la noche la puedo entrar a mi pequeño departamento para dejarla en la cocina poco antes de ir a dormir. Y si me la roban... no es una gran pérdida.

Las medidas de seguridad a tomar están en directa relación con el valor de la cosa protegida, y en IoT a veces hablan como si todo fuera lo mismo: no es lo mismo el control de luces que el sistema de seguridad hogareño, o el portero eléctrico, o el control climático, o incluso el control de apertura de puerta de entrada de la casa (con una smartcard o algo así).
Hay una relación costo-beneficio distinta para cada cosa, y esa es una de las dificultades a superar, porque el hardware/protocolo de comunicaciones/calidad de servicio/etc varía mucho para todo lo que se propone conectar a la red.

Bueno, me disculpo por la longitud de la respuesta, pero siempre me gusta participar cuando Hellmut escribe algo .

Un abrazo.
Hace 3 Semanas #11

Avatar de Hellmut1956

Primeras reacciones a mi visita de la feria "electronica 2016"
Hola amigos. La visita a la feria fue nuy interesante y para mi productiva. Mi pregunta inicial al contactar personas en los puestos de la feria fue:
"Que puedes contarme sobre como tu empresa ofrece servicios para reducir la vulnerabilidad de sistemas usando sus controladores en sistemas embebidos?"
Realmente, con muy pocas excepciones, las personas no tenían idea alguna de que demonios estaba hablando! Así lograba que me pusieran en contacto con la persona mas calificada, presente en la feria, para atenderme. Pero esas personas con las que fui puesto en contacto, o me respondían que no tenían nada para ese tema, cosa que es expresión de las capacidades de tal persona de lo mas elogiables, pues evita el malgastar tiempo! De las pocas empresas que si tenían noción del tema en suma funcionalidades para la visualización y seguridad, esto se veía como algo disponibles en productos de la categoría "Premium"!

Vale referenciar la informaciones disponibles en el Internet sobre los 2 nuevos productos recién publicados: ARM Cortex M23 y M33. Si miran no solo en el sitio de Internet de ARM, sino también a presentaciones de ARM sobre estos 2 nuevos miembros de sus diseños en YouTube. el "23" es un producto especializado en ofrecer un diseño lo mas pequeño posible y con el menor consumo de energía posible. Por ejemplo habla de aplicaciones sin batería, que toman la energía requerida del medio ambiente en el cual están! En inglés se habla de "Energy Harvesting". Es importante resaltar aquí que los ingenieros de ARM realizaron las funcionalidades de virtualización y protección con el foco en que estas funcionalidades requieran una ínfima cantidad del silicio. Hablan en el vídeo de que esta protección de ja de ser un "lujo" opcional, a volverse un requerimiento indispensable para sistemas conectados a la red!
El ARM Cortex M33 está dirigido a aplicaciones equivalentes a aquellas para las cuales hoy se usan ARM Cortex M3 y M4. Su implementación de los dispositivos de seguridad es mas extensa. El dicho que usan y que muy bien refleja el tema es: El elemento mas débil de una cadena define su vulnerabilidad. Vulnerabilidad y seguridad tienen que influenciar un diseño desde el primer paso! El tercer dicho es que no existe seguridad absoluta, pero que el objetivo es hacer la penetración de un atacante lo mas "cara" posible para así limitar los recursos de atacantes. Finalmente el objetivo es evitar que un sistema que ha sido penetrado exitósamente pueda servir como punto inicial de un ataque!
El "33"
Una empresa en la que me encontré con una persona muy bien informada, fue la empresa "Renesas" y aquí en especial los controladores de la familia "S7" serán objeto que permanecerán en la pantalla de mi "radar"! Los controladores son ARM Cortex M4 y las funcionalidades relevantes para reducir la vulnerabilidad están subsumadas bajo los títulos "Safety" < "Security & Encription"! La lectura sobre los mecanismos de protección son muy valiosas si se tienen ciertas informaciones generales sobre vulnerabilidades! Se habla de reducir el "área" expuesto a atacantes al mínimo posible. El documento al que me refiero con enlace en una contribución anterior me sirvió para poder adquirir una visión mas amplia que creo me capacita entender el porque de los mecanismos de protección.
Texas Instruments, Ti, me recomendó ir a cierto sitio de su sitio de Internet, cosa que haré en un futuro cercano!
Finalmente está el nuevo producto de Freescale, i.MX8. Este producto, ya primeras versiones han sido entregadas a 5 clientes escogidos, implementa las funcionalidades de protección de ARM y referencias a este producto también aparecen en el sitio de Internet del hipervisor "XEN" y el sub proyectos para sistemas embebidos tomando como ejemplo inicial su aplicación en el sector automotriz! Esta componente será hecha disponible en 2017 y recién entonces habrá acceso general a documentaciones mas específicas! Pude identificar una ex colega de "Motorola Semiconductores" que es responsable y el contacto para preguntas referentes a esta nueva familia de controladores. ARM en relación a su vídeo sobre los Cortex M23 y M33 también presenta la nueva IDE que apoya las funcionalidades específicas y habla que existe la implementación de los Cortex M23 y M33 en una placa con un FPGA y que permite estudiar y experimentar y diseñar software para estos productos.

El resultado de estas investigaciones al momento es que probablemente el controlador i.MX8 de Qualcomm, NXP, Freescale será el primer producto disponible y que Freescale lo proyecta para aplicaciones en el automóvil. Hay quien dice, que el automóvil será la aplicación móvil mas importante del mercado, mas que teléfonos y tabletas! Así iré investigando como ir preparándome para los controladores i.MX8. Por un lado me compré recién un libro sobre XEN y su uso en PCs. Allí hablan de una "Live CD" que permite experimentar con XEN sin tener que implementarlo. El libro es de 2007 y como esta area de investigación avanza a pasos agigantados en especial en sistemas embebidos, aún no he encontrado lugar de donde descargar una "Live CD" para la versión actual estable de Xen, 4.7.1. Quier empezar a "jugar" con "Xen 4.7.1" en mi PC. Por otro lado veré cuanto puedo acceder herramientas de i.MX7, pues estas tendrán cierta similitud con aquellas para i.MX8.
Finalmente voy a investigar si es posible económicamente para mi adquirir una placa con el i.MX8 cuando aparezca. La IDE de "ARM-Keil" para los controladores M23 y M33 es otro de los entornos a estudiar.
Creo que el montón de informaciones que tengo que estudiar, el montón de conceptos que tengo que conocer y la lentitud de mis estudios por mis problemas de salud le quitan la urgencia a acceder a silicio y documentación del i.MX8 antes que sea generalmente disponible!

Aquí el enlace a información sobre Xen para el sector embebido!

un enlace a un vídeo de ARM que presenta de forma muy estructurada la familia de productos ARM. Es excepcionalmente informativo y completo!
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Buscar más temas sobre:
Lupa Arduino y Raspberry Pi

Cerrar
Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos » Arduino y Raspberry Pi

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.