¿Por qué no fue codificar “administrado” desde el principio? [cerrado]

https://stackoverflow.com/questions/796931

18-09-2019
|

Pregunta

Tenga en cuenta que esto no es sobre el CLR .NET que Microsoft está empujando a la atmósfera para evangelizar el concepto de código administrado. La mayoría de ustedes saben que el código administrado ha existido desde hace bastante tiempo y no está muy relacionado con la ciencia de cohetes.

Lo que me gustaría saber es ¿Por qué el concepto de seguridad en tiempo de ejecución en la evolución de los ordenadores llegó tan tarde .

Sé que esto es como preguntar "¿por qué no entre el primer Modelo T de Ford con bolsas de aire y cinturones de seguridad?". La relevancia de la pregunta sigue en pie a pesar de esto, sin embargo, porque es bien dentro de la naturaleza humana para proteger a los againts peligros conocidos. P.ej. el primer T-Ford no fue lo suficientemente rápido como para motivar la investigación airbag. No se fue lo suficientemente rápido como para que las personas cometen errores de juicio fatales tan a menudo que motivaría el cinturón de seguridad según la ley y la norma en muchos países.

En la evolución del ordenador es casi al revés. Empezamos con el ensamblador, el equivalente de conducir un Ford T en 200 mph con un parche en el ojo. He tenido el placer de conversating con unos camioneros viejos de esta época, al oír estas historias sobre el código de montaje-montaje de la mano, depuradores humanos, líneas de código grillion etc. Si hacemos un error muy desagradable en C, podríamos terminar con una pantalla azul. Hace décadas, podría terminar con el hardware dañado y dios sabe qué. Pero es un misterio para mí -. Tantas décadas, y todo lo que hizo para hacer chocar menos dolorosa fue la pantalla azul (lo siento por el uso de MS como arquetipo para nada)

No es sólo dentro de la naturaleza humana para proteger contra los peligros conocidos, también dentro de la naturaleza de cualquier programador para automatizar y sistematizar las instalaciones comunes , como la comprobación de errores, los diagnósticos de memoria, los marcos de la explotación forestal, el mantenimiento de copia de seguridad, etc, etc.

¿Por qué no programadores / los seres humanos comienzan a automatizar la tarea de asegurar que el código se alimentan al sistema no dañará el sistema ?. Sí, por supuesto, rendimiento . Pero bueno, esto fue mucho antes de cualquier estándar de hardware que penetra en serio. ¿Por qué no consiguen placas base diseñadas con arquitecturas de bus y procesadores adicionales para facilitar el "código administrado"?

¿Hay alguna metáfora para Fords modelo T no ser lo suficientemente rápido que me falta?

Solución

Vamos a pensar en esto a través de los primeros principios.

A plataforma gestionada proporciona un área relativamente recinto de seguridad para ejecutar código de programa que se crea desde el lenguaje de alto nivel a una forma más adecuada para ser ejecutado por la plataforma (bytecodes IL). Allí también son características de servicios públicos como la recolección de basura y la carga de módulos.

Ahora piense en una aplicación nativa - el sistema operativo proporciona un área relativamente aislado (un proceso) para ejecutar código de programa que se crea a partir de un lenguaje de alto nivel a una forma más conveniente ser ejecutado por la plataforma (códigos de operación x86). Allí también son características de servicios públicos como la gestión de memoria virtual y la carga del módulo.

No hay mucha diferencia, creo que la razón por la que hemos logrado plataforma en primer lugar es simplemente porque hace que la codificación de la plataforma más fácil. Se debe hacer que el código portable entre sistemas operativos, pero no le importaba MS para eso. La seguridad es parte de la plataforma gestionada, sino que debe ser parte del sistema operativo - por ejemplo. su aplicación gestionada puede escribir archivos y similares, al igual que un proceso normal. La restricción que es una característica de seguridad, no es un aspecto de una plataforma administrada que no existe en nativo.

En última instancia, podrían haber puesto todas esas características administrados en un conjunto de archivos DLL nativos y desechado la idea del código de bytes intermediario, JIT compilar a código nativo en su lugar. características "gestionados" como GC es fácilmente posible en montones nativas -. ver la Boehm C ++ uno para un ejemplo

Creo que MS lo hizo en parte porque se hizo el compilador más fácil de escribir, y en parte porque así es como se hizo en Java (y .NET es en gran medida un descendiente de Java, aunque sólo sea en espíritu), aunque Java lo hizo de esa manera para hacer posible la codificación multi-plataforma, algo EM no se preocupa por.

Así que, ¿por qué no nos obtener el código desde el principio lograron - porque todas las cosas que usted menciona como parte de código 'gestionado', son de código nativo. plataformas gestionadas que tenemos hoy son simplemente una abstracción adicional en la parte superior de una plataforma ya abstraído. Los lenguajes de alto nivel han tenido más características añadidas a ellos para protegerle de sí mismo, desbordamientos de búfer son una cosa del pasado, pero no hay ninguna razón por la que no podrían haber sido implementado en C cuando C fue inventado. Es sólo que no lo eran. Tal vez retrospectiva hace que parezca que estas características faltaban, pero estoy seguro que dentro de 10 años, vamos a preguntarnos "¿por qué no en C # implementar la función de utilidad, obviamente, XYZ como el que tenemos hoy"

Otros consejos

El código administrado construida en seguridad, etc. ha existido por mucho tiempo.

Simplemente no había espacio para él en la plataforma PC original y nunca se añadió más tarde.

direccionamiento, bibliotecas meollo intocables, función de seguridad basada

El mainframe IBM ha venerado ha protegido, etc, etc desde los años 70. Además todo ese código ensamblador fue gestionado por un sofisticado (por el momento) Sistema de gestión del cambio. (Univac, etc Burroughs tenía algo similar.)

Unix tenía la seguridad bastante decente construido en desde el principio (y no ha cambiado mucho en los últimos años).

Así que creo que esto es en gran medida un problema de espacio ventanas / web.

No ha habido nunca un virus de mainframe! La mayor parte de las transacciones financieras en el mundo pasan a través de estos sistemas en algún momento así que no es como si se interrumpía un objetivo atractivo.

El sistema interno de correo IBM hizo el anfitrión de la primera 'troyano', aunque!

En realidad, el código administrado ha estado alrededor por un tiempo muy largo. Considere lo siguiente:

LISP
Smalltalk
BASIC (sabor original)

Todos sistema como entornos proporcionado operativos que protegían el uso de otros problemas de control de recursos de memoria y. Y todos fueron fracasos relativos (solamente BÁSICO realmente sucedieron cuando se introdujeron características como PEEK y POKE que permitieron meterse con el sistema subyacente).

Los ordenadores no eran lo suficientemente potente y hacerlas lo suficientemente potente como era demasiado caro. Cuando se ha conseguido solamente limitados recursos a su disposición, cada byte y cuentas de ciclo de la CPU.

El primer ordenador que utilicé fue una rel="nofollow Sinclair ZX Spectrum en 1982. Tenía menos RAM (16K) que el tamaño del archivo de fuentes hoy una sola Windows. Y eso fue hace relativamente poco tiempo, en la era del ordenador en casa. Antes de mediados de la década de 1970 la idea de tener un ordenador en su casa era inconcebible.

montaje

Sólo para que conste, nunca compilado a mano. Nos mano-ensamblados código en lenguaje ensamblador. Ahora que eso está claro ...

Su analogía es la opacidad a la pregunta debido a que la velocidad del coche no es análoga a la velocidad de la computadora en este sentido: El aumento de la velocidad del coche hizo necesario los cambios en la seguridad de los automóviles, pero no es el aumento de la velocidad de la computadora que impulsa la necesidad de cambios en la seguridad informática, es el aumento de la conectividad. Desde un ángulo ligeramente diferente: Para el coche, el aumento de la velocidad es el conducción la tecnología para aumentar la seguridad. Para los equipos, aumentando la velocidad es la permitir la tecnología para aumentar la seguridad.

Por lo tanto, los primeros coches estaban a salvo de accidentes, ya que eran lentos. Los primeros ordenadores eran seguros porque no estaban en red.

Ahora, los coches se hacen más seguro a través de cinturones de seguridad, bolsas de aire, ABS, dispositivos anti-colisión, y así sucesivamente. Las computadoras se hacen seguras a través de técnicas adicionales, aunque aún no puede vencer a desconectar el cable de red.

Esto es una simplificación, pero creo que se pone en el centro de la misma. No había necesidad de que las cosas en aquel entonces, porque las computadoras no estaban conectados a la red.

La misma razón por la que no había trenes hace 300 años. La misma razón por la que no había teléfonos celulares hace 30 años. La misma razón por la que todavía no tenemos máquina de teletransporte.

La tecnología evoluciona con el tiempo, se le llama evolución.

Los ordenadores no era lo suficientemente potente como en aquel entonces. la ejecución de un recolector de basura en el fondo tendría que matarte rendimiento de las aplicaciones.

En declaraciones a la pregunta de por qué los ordenadores no tienen los mecanismos de protección en el nivel de código administrado, en lugar de por qué las máquinas virtuales no podía correr en hardware lento (ya se ha explicado en otras publicaciones). La respuesta corta es que fue. CPU fueron diseñados para lanzar una excepción cuando el código malo ha pasado para que no dañaría el sistema. Windows maneja este notoriamente deficiente, pero hay otros sistemas operativos que hay. Unix se lo pasa como señales para que los programas consiguen terminados sin cerrar el sistema. Realmente si está o no se está ejecutando el código administrado o no, una excepción de puntero nulo tendrá como resultado la misma manera - en la terminación del programa. La memoria virtual garantiza que los programas no ensucia con otro código, por lo que lo único que pueden hacer es daño a sí mismos.

Lo que me lleva al segundo punto. Todo esto no es necesario si usted sabe lo que está haciendo. Si quiero mantener mis muebles limpio, sencillamente no caída de los alimentos en él. No necesito para cubrir mi casa en plástico, sólo tengo que tener cuidado. Si usted es un codificador descuidado la mejor máquina virtual en el mundo no se va a salvar, sólo se permitirá ejecutar su código descuidado y sin ningún ruido. Además, portar código es fácil si utiliza la encapsulación adecuada. Cuando eres un buen programador, código administrado no ayuda ampliamente. Es por eso que no todo el mundo lo está utilizando. Es simplemente una cuestión de preferencia, no es mejor / peor.

En lo que va de seguridad en tiempo de ejecución, no hay nada que un compilador de código P puede predecir que un código de máquina no puede, y no un intérprete de código administrado puede manejar que el sistema operativo no puede (o no) ya . Las placas base con conjuntos de autobuses, CPU e instrucciones adicionales cuestan mucho más dinero - es todo acerca de la relación coste / rendimiento

En 1970, el coste de la memoria era alrededor de $ 1 / bits (sin inflación). Usted no puede permitirse el lujo de recolección de basura con los costos por el estilo.

Creo que como la mayoría de las preguntas, "¿Por qué no lo hemos hecho en la programación X Y hace años", la respuesta es la asignación de velocidad / recurso. Con recursos limitados que tenían que ser manejados con la mayor eficacia posible. El tipo de propósito general de gestión asociado con el código administrado habría sido el consumo de haber sido de beneficio en el rendimiento de las aplicaciones críticas de la época también de recursos. Esto también es parte de la razón por código crítico el rendimiento de hoy todavía está escrito en C, Fortran o ensamblador.

¿Por qué didn'we simplemente construir aviones y naves espaciales a la vez, en lugar de al rededor del caballo y el carro y todo eso tediosa?

El uso de un lenguaje intermedio requiere una de dos cosas:

interpretación en tiempo de ejecución, lo que tendrá una penalización de rendimiento sustancial (muy variable - de vez en 2x o menos, pero a veces 100 veces o más)
Un compilador justo a tiempo, lo que requerirá memoria RAM adicional, y que se sumarán demora aproximadamente proporcional al tamaño del programa, en lugar de número de instrucciones ejecutadas

Una cosa que ha cambiado con los años es que muchos programas se ejecutan las partes más fuertemente usadas de su modo muchas veces más de lo que solían. Supongamos que la primera vez que se ejecuta ninguna declaración en particular tendrá un cargo de 1.000 veces más largo que las ejecuciones posteriores. ¿Cuál será el efecto de que la pena en un programa donde cada instrucción se ejecuta un promedio de 100 veces? ¿Cuál será el efecto de que la sanción a un programa en el que cada instrucción se ejecuta un promedio de 1.000.000 de veces?

Justo a tiempo de compilación ha sido posible desde hace mucho tiempo, pero en los años 1990 o 1980 de, el costo de rendimiento habría sido inaceptable. Dado que las tecnologías han cambiado, los costos prácticos de la compilación JIT han llegado hasta el punto de que son totalmente práctico.

La respuesta se hace más claro - los seres humanos no fueron construidos para escribir programas. Las máquinas deben estar haciéndolo y dejarnos relajarse jugando Pacman.

Por lo que vale, he leído un par de papeles para mi clase de lenguajes informáticos (uno por CAR Hoare y otro por Nicholas Wirth) abogando exactamente esto en los años 60 y 70, entre otras cosas.

No puedo hablar a exactamente por qué estas cosas no suceden, pero yo creo que es sólo una de esas cosas que se parece obvio a posteriori que no era evidente en el momento. No es que los compiladores anteriores no estaban preocupados por la seguridad. Es que tenían diferentes ideas acerca de cómo hacer esto.

Hoare menciona la idea de un "compilador de pago y envío". Por lo que yo puedo decir, esto es esencialmente un compilador que hace el análisis estático. Para él, esto era una técnica popular que falló (o al menos no han conseguido solucionar tantos problemas como los que se inteneded de resolver). La solución para él era hacer los lenguajes de programación más seguro mediante la creación de código administrado (o al menos eso es lo que habría dicho en términos modernos).

Me imagino que una vez que C (y más tarde en C ++) tuvo éxito, la idea de código administrado era esencialmente muerto. No es que C era una mala lengua, sólo que estaba destinado a ser un lenguaje ensamblador en lugar de un lenguaje de programación de aplicaciones.

Si tienes la oportunidad, que se puede leer Sugerencias de programación en lenguaje de diseño . Es una muy buena lectura si está interesado en este tipo de cosas.

La mejor respuesta a esta pregunta es, en mi humilde opinión, nadie tenía una idea de código administrado en ese momento. Conocimiento realidad evoluciona con el tiempo. En comparación con campos como la arquitectura o la agricultura, la informática es un campo muy joven. Por lo que el conocimiento colectivo sobre el terreno también es joven y va a evolucionar con el tiempo. Tal vez dentro de unos años nos encontramos con un nuevo fenómeno y alguien va a estar haciendo la misma pregunta: "¿Por qué nadie piensa en XYZ beofore?".

Yo diría que es en gran medida el cambio habido resistencia junto con falsa percepción de ineficiencia de recolección de basura que se retrasa la adopción de GC y técnicas relacionadas. Por supuesto, la muerte cerebral segmentado modelo de memoria en el procesador Intel 8086 no exactamente ayudar a promover la gestión de memoria en su sano juicio en el PC.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow