Estudo mostra que LLMs geram codigo RTL funcional mas inseguro quando a especificacao nao menciona seguranca explicitamente
Pesquisadores criaram o SECRTL-GEN, benchmark com 392 tarefas de geracao de codigo de hardware (RTL) em Verilog, SystemVerilog, VHDL e Python que testa correcao funcional e seguranca separadamente. Modelos de fronteira passam em 73% a 79% dos testes funcionais mas apenas 14% a 35% dos testes de seguranca, e modelos funcionalmente melhores nao sao necessariamente mais seguros -- um framework auxiliar, o RTL-Obliger, eleva a taxa combinada de aprovacao para 61,6% inferindo obrigacoes de seguranca implicitas a partir da propria especificacao.
O trabalho parte de uma observacao pratica sobre como equipes de design de hardware escrevem especificacoes: requisitos de seguranca (como controle de acesso a determinados registradores ou protecao contra estados de fault injetados) frequentemente ficam fora da documentacao funcional, sendo tratados como conhecimento implicito que um engenheiro experiente aplicaria por padrao, mas que nunca aparece explicitamente escrito na especificacao que alimenta um LLM gerador de codigo. O SECRTL-GEN foi desenhado especificamente para testar esse cenario realista: as 392 tarefas do benchmark, cobrindo cinco familias de CWE (Common Weakness Enumeration) em quatro linguagens de descricao de hardware, deliberadamente omitem obrigacoes de seguranca das especificacoes funcionais, com testbenches de caixa-preta separados para corretude funcional e para seguranca.
O achado central e uma lacuna acentuada entre as duas dimensoes: os cinco modelos de fronteira avaliados passam em 73% a 79% dos testes funcionais sob prompts simples, mas apenas 14% a 35% dos testes de seguranca -- e criticamente, os modelos com melhor desempenho funcional nao sao os mais seguros, o que descarta a hipotese confortavel de que 'modelos melhores em geral' resolveriam o problema de seguranca automaticamente. Isso e especialmente grave no dominio de RTL porque, ao contrario de software convencional, uma falha de seguranca em codigo RTL que ja foi taped out (fabricado fisicamente em silicio) nao pode mais ser corrigida com um patch -- o defeito fica permanentemente embutido no chip fisico.
Os experimentos de mitigacao trazem um diagnostico interessante sobre a causa raiz: adicionar conhecimento explicito sobre categorias CWE relevantes ao prompt melhora a taxa de seguranca, mas pedir ao modelo para simplesmente 'pensar mais' sobre seguranca (self-thinking nao guiado) ajuda pouco, e prompts orientados a seguranca tendem a reduzir a taxa de aprovacao funcional -- ou seja, o gargalo nao e falta de capacidade do modelo em escrever RTL defensivo, e sim falta de consciencia de qual ameaca especifica se aplica aquele contexto quando a especificacao nao menciona.
O RTL-Obliger, framework neuro-simbolico proposto pelos mesmos autores, ataca exatamente esse gargalo de forma estruturada: um LLM extrai um grafo semantico-funcional da especificacao, um motor simbolico cruza esse grafo contra uma ontologia de padroes CWE para identificar lacunas de mitigacao e obrigacoes de seguranca implicitas em nivel de sinal, e o LLM entao revisa o RTL sob essas obrigacoes explicitadas, em um processo de duas etapas que preserva a funcionalidade original. O resultado -- elevar a taxa combinada de aprovacao (funcional e seguranca) de 49,6-51,4% para 61,6%, superando outras baselines de geracao segura -- sugere que decompor 'seguranca' em obrigacoes explicitas e verificaveis, em vez de depender do modelo inferir tudo implicitamente, e uma direcao mais promissora para geracao de codigo de hardware assistida por IA do que simplesmente aumentar a capacidade geral do modelo.