O Caso a Favor de Roadmaps Seguros para a Memória

Adoção de Linguagens com Segurança de Memória em Código de Sistemas/SO

• A discussão gira em torno de como trazer segurança de memória para kernels e sistemas de baixo nível.
• Rust no kernel Linux é visto como promissor, mas ainda com presença muito pequena e em estágio inicial, principalmente em drivers.
• A estratégia favorecida: conversão gradual de componentes “de borda” para Rust, em vez de reescritas completas.
• Alguns argumentam que microkernels ou segmentação pesada (VMs, isolamento no estilo Qubes) teriam resolvido muito disso mais cedo.

Escolhas de Linguagem e a “Lista Segura” da NSA

• O apêndice da NSA lista C#, Go, Java, Python, Rust, Swift como “memory safe”, o que gerou debate.
• Muitos observam que ecossistemas do mundo real frequentemente chamam bibliotecas C/C++, enfraquecendo a segurança prática.
• Alguns se perguntam por que Python está na lista, mas não Ruby, JS ou Perl; a explicação sugerida: popularidade e o impulso de IA/ML.

Rust vs C/C++ (e Go/Swift)

• Defensores destacam o “safe por padrão, unsafe em regiões pequenas e explícitas” do Rust, reduzindo a superfície de auditoria.
• Críticos dizem que, para trabalho de baixo nível, acabam encontrando unsafe e MaybeUninit com frequência, parecendo C com cerimônia extra.
• Defensores de C++ argumentam que RAII, smart pointers, tipos inteiros personalizados, sanitizers e subconjuntos disciplinados podem ser “seguros o suficiente”, mas outros respondem que a história mostra humanos ainda introduzindo bugs críticos.
• Go e Swift são apontados como seguros em nível de linguagem, mas com ressalvas: Go tem explorações baseadas em data race; Swift e Rust adicionam garantias de concorrência mais fortes.

Outras Linguagens: Ada, Fortran, Java, JavaScript, Python

• Ada/SPARK são citados como fortemente seguros em memória em domínios críticos de segurança (aviônica, ferroviário, defesa), mas com participação de mercado pequena.
• Fortran está em grande parte confinado à computação científica; não é visto como uma grande superfície de ataque.
• Java é chamado tanto de um “pest fest” para explorações quanto, por outros, de majoritariamente aceitável, exceto por incidentes notáveis (por exemplo, log4j).
• Motores JavaScript são difíceis de tornar totalmente seguros devido à complexidade do JIT; alguns mencionam implementações mais seguras na JVM.
• Python em si é memory safe, mas a dependência de extensões C/C++ reintroduz risco.

Concorrência, Comportamento Indefinido e Limites da Segurança

• Vários argumentam que, depois da segurança de memória, comportamento indefinido e overflow/underflow de inteiros deveriam ser os próximos alvos.
• O comportamento definido de overflow do Rust (panic em debug, wrap em release, além de APIs explícitas de verificação) é elogiado.
• Outros apontam que nenhuma linguagem “resolve” totalmente a concorrência; Rust e Swift vão mais longe, mas corridas lógicas continuam.

Código Legado, Treinamento e Ferramentas

• O enorme legado em C/C++ é visto como o problema central. Muitos novos sistemas ainda começam nessas linguagens.
• Alguns propõem subconjuntos mais estritos (estilo MISRA) e análise estática (Astree, Frama-C, etc.) para provar segurança, mas observam custo e dificuldade.
• O fio é cético de que treinamento sozinho possa impedir bugs de memória; até desenvolvedores altamente treinados em domínios regulados ainda os lançam.
• IA é sugerida como um assistente futuro para auditar C/C++ em busca de problemas de memória, em vez de escrever novo código.

Modelos de Ameaça, Air Gaps e Motivos da NSA

• Participantes enfatizam que código C em ambiente air-gapped ou “offline” não é imune (Stuxnet é citado); se o air-gapping parece necessário, linguagens seguras em memória provavelmente também o são.
• Alguns, de forma cínica, sugerem que a NSA quer que a indústria migre para runtimes compartilhados que ela possa atingir, enquanto אחרים contrapõem que a NSA também tem fortes incentivos para endurecer a infraestrutura dos EUA.