20 anos com a AWS: nunca disse que “não era meu trabalho”

• Colin Percival, responsável pela segurança do FreeBSD e fundador da Tarsnap, relembra em ordem cronológica como, desde a criação de sua primeira conta AWS em 2006 até hoje, esteve amplamente envolvido na evolução da AWS da posição de colaborador externo, e não funcionário oficial: desde a construção do suporte ao FreeBSD no EC2 até a descoberta e o reporte proativo de vulnerabilidades de segurança e feedback sobre o design dos serviços
• No início, a AWS exigia ativação separada para cada serviço, e os primeiros serviços habilitados por padrão eram o Amazon SQS e o pouco conhecido Amazon E-Commerce Service
• Para executar o FreeBSD no EC2, foi preciso superar ao longo de anos obstáculos técnicos como compatibilidade de versões do Xen, suporte a PAE e a transição para HVM; o primeiro funcionamento bem-sucedido ocorreu em 2010, no t1.micro
• Ele descobriu e reportou preventivamente vários problemas de segurança, incluindo a vulnerabilidade de colisão de normalização no esquema de assinatura de requisições da AWS, o risco de exposição de credenciais via IMDS (que se materializou no incidente da Capital One em 2019) e problemas de segurança no Seekable OCI
• Desde 2024, continua mantendo o FreeBSD/EC2 com apoio do GitHub Sponsors da Amazon, num caso em que, mesmo sem acesso interno aos sistemas da empresa, obteve resultados com a colaboração de engenheiros da Amazon

---

Criação da conta AWS e serviços iniciais

• Em 10 de abril de 2006, após ver o anúncio do Amazon S3, criou sua primeira conta AWS; o interesse por um serviço de armazenamento online foi o gatilho, e ele já trazia experiência desde 1998 na construção de serviços web baseados em HTTP
• Na AWS inicial, era preciso solicitar a ativação de cada serviço separadamente na conta, e os únicos serviços oferecidos por padrão eram o Amazon SQS e o Amazon E-Commerce Service (API de catálogo de produtos para afiliados da Amazon)
  • O Amazon E-Commerce Service foi, na prática, o primeiro serviço da AWS, mas era pouco conhecido e acabou sendo discretamente apagado da própria história da AWS

Interesse inicial em segurança e feedback

• Com base em sua experiência como FreeBSD Security Officer, passou a se interessar imediatamente pela arquitetura de segurança da AWS e apontou que, embora as requisições AWS fossem assinadas com chaves de API para garantir autenticação e integridade, as respostas não tinham assinatura
• Como na época era comum fazer requisições AWS por HTTP, a possibilidade de adulteração das respostas era um risco real; mesmo após a adoção do TLS, ele manteve a posição de que assinaturas ponta a ponta são superiores à segurança da camada de transporte

FreeBSD no EC2 — desafios iniciais

• Logo após o lançamento do Amazon EC2, decidiu fazer o FreeBSD rodar nele e, por meio de Jeff Barr, foi apresentado a responsáveis internos da Amazon; no começo de 2007 assinou seu primeiro Amazon NDA
  • Na época a Amazon ainda usava fax, mas como ele não tinha um, enviou a via assinada pelo correio, o que atrasou o primeiro briefing
• O EC2 foi lançado inicialmente sem suporte a kernel customizado (de forma parecida com o AWS Lambda atual), e em novembro de 2007, com a ativação desse recurso junto do suporte ao Red Hat, sua conta FreeBSD também passou a ter acesso à API interna de “publicar Amazon Kernel Images”

Auditoria de segurança do Xen e alerta sobre ataques por canal lateral

• Em março de 2007, levantou com um contato da Amazon a necessidade de uma auditoria de segurança do Xen e, quando não sabiam quem poderia fazê-la, recomendou Tavis Ormandy
  • No mesmo ano, Tavis reportou duas vulnerabilidades no Xen (CVE-2007-1320, CVE-2007-1321), embora não esteja claro se houve relação com essa recomendação
• Em um encontro de usuários da AWS no Second Life organizado por Jeff Barr, pediu recursos como disco raiz somente leitura e garantia de limpeza da memória ao reiniciar, pensando em cenários de execução de código não confiável, como builds de pacotes FreeBSD; o EC2 Instance Attestation só seria lançado 18 anos depois
• Na re:Invent de 2012, explicou a um Principal Engineer do EC2 uma pesquisa sobre roubo de chaves RSA usando HyperThreading e recomendou fortemente que instâncias EC2 não fossem executadas em paralelo nos dois threads do mesmo núcleo
  • Diz-se que essa recomendação ajudou a explicar por que muitas famílias de instância do EC2 pulavam o tamanho “medium” e começavam diretamente em 2 vCPUs (“large”)

Consistência eventual e propostas teóricas

• No fim de 2007, em uma postagem de blog amplamente lida dentro da Amazon, apontou problemas da Eventual Consistency e defendeu um modelo um pouco mais forte chamado Eventually Known Consistency
  • Um modelo que manteria o caminho “A” (disponibilidade) do teorema CAP, mas ainda exporia o estado interno para também garantir “C” (consistência) no caminho normal
  • O Amazon S3 mais tarde mudou de uma otimização voltada à disponibilidade para uma otimização voltada à consistência, e o DynamoDB passou a oferecer opção entre leituras Eventual e Strongly Consistent

Problemas de compatibilidade com Xen e falha de boot do FreeBSD

• No início de 2008, Kip Macy escreveu um kernel FreeBSD com suporte a Xen PAE, e levaram várias semanas para portar para FreeBSD as ferramentas internas de AMI
  • Ele comenta que uma estrutura em que scripts Ruby geram e executam scripts bash talvez justificasse repensar a escolha de linguagens
• A AMI de FreeBSD não inicializava no EC2, e a causa era um bug no Xen 3.0 usado pelo EC2, que não suportava a tabela de páginas recursiva do código de VM do FreeBSD
  • O problema foi corrigido no Xen 3.1, mas como não havia ABI estável, a Amazon preferiu permanecer no Xen 3.0 para manter compatibilidade com as AMIs existentes

Descoberta e correção de vulnerabilidade na assinatura da AWS

• Em abril de 2008, ao usar o Amazon SimpleDB para a beta do Tarsnap, descobriu uma colisão de normalização no esquema de assinatura
  • Como a Amazon ainda não tinha um canal para reportar problemas de segurança, ele repassou o caso por meio de Jeff Barr
• A Amazon pediu que ele revisasse o design da Signature Version 2; após correções de ambiguidades na documentação, ajustes de decisões de design e inclusão de allowlists por conta, o problema foi corrigido em dezembro

Problema de higiene de segurança no NextToken do SimpleDB

• Em junho de 2008, descobriu que o valor de NextToken do SimpleDB era apenas um objeto serializado em Java codificado em base64
  • Reportou que seria necessário criptografá-lo para evitar vazamento de informações internas e assiná-lo para impedir adulteração, mas não recebeu resposta
  • Seis meses depois, voltou a reportar o problema por meio de outro engenheiro, que abriu um ticket interno, mas ainda assim nunca houve retorno oficial

Teste alfa do EBS e o timing do feedback de design

• Em março de 2008, Matt Garman, da equipe do EC2, o convidou para o alfa fechado do Elastic Block Storage (hoje Elastic Block Store)
  • Na visão dele, o momento mais útil para dar feedback sobre um novo serviço é a fase de design, antes da implementação; vindo de uma formação em matemática e teoria, revisar documentos de design seria mais eficaz do que participar do teste alfa

Episódio da entrevista para entrar na Amazon

• Em 2008, por sugestão de Jeff Barr, considerou entrar na Amazon, e numa entrevista por telefone com Al Vermeulen passou 30 dos 45 minutos debatendo os prós e contras de exceptions
  • Ele segue sustentando que tratamento por exceções é uma forma inerentemente inadequada de lidar com erros, por facilitar bugs difíceis de detectar em revisões casuais de código

IAM e chaves de acesso limitadas — o caminho até o SigV4

• Em novembro de 2008, no Seattle AWS Start-up Tour, encontrou engenheiros da Amazon e discutiu a necessidade de chaves de acesso AWS com escopo limitado
  • Defendeu um esquema de chaves derivadas criptograficamente, em que chaves por serviço seriam derivadas por hash a partir de um segredo mestre; a Amazon preferia um design baseado em regras
• Em janeiro de 2010, foi convidado para a beta fechada do IAM; quando o SigV4 foi lançado em 2012, o método com chaves derivadas acabou sendo adotado

Problema no firewall do EC2 e Path MTU Discovery

• Em 2009, descobriu e reportou que as regras padrão de firewall do EC2 bloqueavam mensagens ICMP Destination Unreachable (Fragmentation Required), impedindo o funcionamento do Path MTU Discovery
  • Em dezembro de 2009, um gerente do EC2 concordou com a solução, mas a correção real só veio depois que ele levantou o problema publicamente em 2012

Desvio via NetBSD e transição para HVM

• No início de 2010, como o EC2 ainda permanecia em uma versão antiga do Xen, tentou migrar para o NetBSD e em apenas uma semana já havia conseguido boot, montagem de sistema de arquivos, configuração de rede e execução do sshd
• Em julho de 2010, as instâncias Cluster Compute passaram a oferecer suporte a HVM, trazendo esperança para o FreeBSD e deixando claro que PV (paravirtualização) era um beco sem saída técnico

Primeiro funcionamento do FreeBSD/EC2 — t1.micro

• A família de instâncias t1.micro, lançada em setembro de 2010, rodava internamente Xen 3.4.2, eliminando o bug que impedia o boot do FreeBSD
• Em meados de novembro de 2010, conseguiu acessar por SSH uma instância FreeBSD/EC2 t1.micro; em 13 de dezembro veio o anúncio oficial do suporte ao FreeBSD EC2 t1.micro

Expansão dos tipos de instância e o hack “Defenestration”

• Um Solutions Architect da Amazon o conectou a usuários de FreeBSD que queriam instâncias maiores, permitindo implementar suporte às instâncias Cluster Compute
• Aproveitando o fato de que o EC2 não sabia de fato qual SO estava rodando, tornou possível usar FreeBSD em todos os tipos de instância 64-bit por meio de defenestration (disfarçando-se como instância Windows)
  • Era preciso pagar o “imposto Windows”, e a Amazon também não gostava da situação, mas isso era essencial para atender a demanda dos clientes; em julho de 2014, quando as instâncias T2 completaram o suporte a HVM “Linux”, esse hack deixou de ser necessário

Diagnóstico de falha de hardware de roteador do S3

• Em abril de 2012, começaram a ocorrer várias falhas de requisição, incluindo erros SignatureDoesNotMatch, em um endpoint específico do S3
• Ao identificar um padrão em que o valor StringToSign nas respostas de erro não correspondia ao valor enviado, detectou um stuck bit e, com traceroute e milhões de pings, localizou uma falha de hardware em um roteador na rota
  • Após relatar o caso nos AWS Developer Forums, a Amazon confirmou o problema em poucos dias e substituiu o hardware

re:Invent 2012 e alerta sobre ataques por canal lateral

• A primeira re:Invent tinha pouco conteúdo técnico e muita gente de terno, mas ofereceu oportunidades de contato presencial com vários engenheiros da Amazon
• Depois que um VP da Intel palestrando sobre “segurança de máquinas virtuais” respondeu que não conhecia ataques por canal lateral, ele foi ao estande do EC2 explicar diretamente a pesquisa relacionada a um Principal Engineer

Oficialização do FreeBSD/EC2 e engenharia de release

• Em abril de 2015, o processo de build de AMIs do FreeBSD/EC2 foi integrado à árvore src do FreeBSD, transferindo a geração de imagens para a equipe de engenharia de release do FreeBSD e transformando o trabalho de projeto pessoal em parte do projeto oficial do FreeBSD
• Em setembro de 2020, a pedido de Glen Barber, líder de engenharia de release do FreeBSD, aceitou o papel de Deputy Release Engineer
  • No fim de 2022, Glen foi hospitalizado com pneumonia e, por sequelas de longo prazo, não conseguiu retornar; em 17 de novembro de 2023, ele assumiu diretamente como FreeBSD Release Engineering Lead
  • Passou a tocar builds semanais de snapshot, apertar cronogramas, estabelecer um ciclo de releases rápido e previsível e gerenciar quatro releases por ano

Alerta de segurança sobre IMDS e o incidente da Capital One

• Em outubro de 2016, ao analisar o IAM Roles for Amazon EC2, publicou em blog que a exposição de credenciais via IMDS era perigosa, pois o mecanismo operava sobre HTTP não autenticado e a própria documentação alertava para “não armazenar dados sensíveis”
• Em julho de 2019, a Capital One sofreu exatamente esse tipo de exploração, com vazamento de dados de 106 milhões de clientes; após conversar com a Amazon em novembro daquele ano, duas semanas depois foi lançado o IMDSv2
  • Na visão dele, o IMDSv2 mitiga certos vetores de ataque, mas não resolve o problema fundamental de expor credenciais por uma interface inadequada

Programa AWS Heroes

• Em maio de 2019, foi convidado para o AWS Heroes, programa que reconhece pessoas fora da Amazon que fizeram contribuições importantes para a AWS
  • Foi uma escolha incomum, já que o programa era focado principalmente em contribuidores de educação para desenvolvedores (blogs, YouTube, workshops), e sua nomeação foi aprovada com recomendação de um Distinguished Engineer e um Senior Principal Engineer

Boot UEFI e BootMode=uefi-preferred

• Em março de 2021, o EC2 passou a suportar boot UEFI em instâncias x86, e no FreeBSD a mudança para UEFI eliminou a necessidade de I/O em modo 16-bit, reduzindo o tempo de boot em 7 segundos
  • Como nem todos os tipos de instância suportavam UEFI, ele pediu uma configuração BootMode=polyglot para imagens capazes de iniciar tanto em BIOS legado quanto em UEFI
  • Em março de 2023, isso foi implementado com o nome BootMode=uefi-preferred

Descoberta de problema de segurança no Seekable OCI e atraso na correção

• Em agosto de 2023, no Heroes Summit, viu o design do Seekable OCI e percebeu que, em certos casos de uso, a alegação de segurança não se sustentava; reportou o problema à equipe de segurança da AWS
• Recebeu promessa de correção interna, mas nada avançou de fato; voltou a cobrar na re:Invent de 2024 e, após novo reporte em janeiro de 2025, confirmou-se que um commit de 2023 evitava apenas corrupção acidental de dados, sem bloquear ataques intencionais
  • Depois disso, a reação foi rápida e, até o fim de fevereiro de 2025, o recurso havia sido desativado para a maioria dos clientes, ficando no aguardo de uma “major revision”

Patrocínio da Amazon e modelo de colaboração

• Em abril de 2024, avisou à Amazon que não estava conseguindo dedicar tempo suficiente à manutenção do FreeBSD/EC2 e pediu apoio financeiro; em poucas semanas, foi confirmado um patrocínio de 10 horas por semana por 1 ano via GitHub Sponsors
  • Depois de resolver vários problemas pendentes e passar por uma pausa de seis meses (em grande parte não remunerada, dedicada à engenharia de release do FreeBSD 15.0), iniciou um segundo patrocínio de 12 meses
• Ele enfatiza que essas contribuições de 20 anos não foram fruto apenas de seu esforço individual: mesmo sem acesso aos sistemas internos da AWS, engenheiros da Amazon atuaram como “mãos remotas”, abrindo tickets, localizando contatos internos, investigando logs de API e obtendo documentação técnica

[GN⁺]

Comentários no Hacker News

• O autor brincou que os ‘Heroes são basicamente funcionários não remunerados da Amazon’, mas isso não é piada, é realidade
  Eu não publico minha pesquisa pessoal. Não quero fornecer P&D grátis para uma máquina de extração de valor que já é eficiente o bastante
  A Amazon destruiu os pressupostos econômicos do open source, e como resultado muitos projetos estão migrando para a Business Source License
  Esses desenvolvedores sabem o quão gananciosa a Amazon é. No fim, as contribuições da comunidade viram trabalho não remunerado para megacorporações, e a Amazon absorve usuários com serviços gerenciados, enfraquecendo o suporte e a comunidade do projeto original

  • Se você não quer que a Amazon use seu código, basta excluir explicitamente a Amazon na licença
    Se você escrever “qualquer um pode usar livremente, exceto a Amazon”, a Amazon não vai usar por causa do risco jurídico
    Mas, se considerar necessário, a Amazon provavelmente criará uma nova versão própria
  • Grandes empresas de SaaS conseguem implementar a mesma interface de API mesmo com Business Source License
    Como mostrou o caso do Redis, a proteção legal da superfície da API não é clara
    Pelo que me lembro, o precedente Google v. Oracle acabou adiando o estabelecimento dessa proteção
  • Também é possível usar licenças como AGPL ou GPL3. Essas licenças são praticamente proibidas pelos hyperscalers
    Na verdade, empresas que escolhem BSL provavelmente publicaram o código mais por gestão de imagem ou para ganhar simpatia de desenvolvedores do que por um espírito genuíno de open source
  • “Por sorte”, eu não sou inteligente ou importante o bastante para pensar nisso tão a fundo
    Ainda assim, concordo totalmente. Agora, o código que eu publico é ou completamente open source ou completamente fechado
    Se houver a possibilidade de alguém ganhar dinheiro com isso, eu não publico

• Eu entendo a visão de não querer doar tempo para grandes empresas, mas gostaria de oferecer outra perspectiva
  Em 2006, entreguei de bom grado o nome de um projeto que eu havia criado quando outro desenvolvedor quis usá-lo em 2012
  Esse projeto era o scrypt, e o desenvolvedor era Colin
  Esse tipo de gentileza comunitária acaba gerando bom karma mesmo sem expectativa comercial

• É bem interessante a parte sobre “o meetup de usuários da AWS do Jeff Barr aconteceu no Second Life”
  O Second Life era um usuário inicial da AWS, e Jeff Bezos participou pessoalmente da rodada de investimento de 2005
  Por causa disso, Jeff Barr realizou meetups da AWS dentro do Second Life, e naquela época grupos como Reuters e Jonathan Coulton também estavam entrando em espaços virtuais

  • Ainda me lembro de ter visto o Second Life pela primeira vez em uma conferência, por volta de 2002~2003
    Nós estávamos no estande da Evolution Robotics demonstrando o robô ER1, e o Second Life realmente impressionava
    Ficou como uma boa lembrança
  • Quando a re:Invent 2020 aconteceu em espaço virtual, senti um forte déjà vu dos tempos de Second Life
    Claro, o Second Life na tela do notebook e um headset de VR eram experiências totalmente diferentes

• O enquadramento de “trabalho grátis para a Amazon” erra o ponto principal
  Colin não estava fazendo caridade; ele estava melhorando algo de que o Tarsnap depende em FreeBSD/EC2
  Esse modelo é uma das formas mais saudáveis de open source — você corrige a base do seu próprio produto, e o resultado beneficia todo mundo
  Esperar até que a Amazon se interesse diretamente é o mesmo que esperar para sempre

• Fiquei surpreso ao ler que a Amazon patrocinou via GitHub Sponsors por 10 horas por semana durante 1 ano
  $300 por hora é nível de remuneração de um engenheiro L6 do Google
  Espero que hoje ele receba ainda mais

  • As taxas por hora no setor de tecnologia dos EUA são realmente anormais
    Na Europa de língua alemã, com 120 euros você consegue um ótimo engenheiro. No Leste Europeu é ainda mais barato

• Não concordo com a crítica do autor ao IAM Roles for EC2
  O IAM é um recurso essencial que permite gerenciar credenciais com base em políticas
  É muito mais seguro do que Outlook, Slack ou Teams, e dá até para provar matematicamente que membros da equipe não podem ver a chave de assinatura
  O Azure também aplica um conceito parecido para lidar de forma limpa com acesso ao MSSQL

  • Eu não sou contra IAM Roles em si. Só acho que fizeram a pior escolha possível na interface para entregar as credenciais da role
    Antigamente eu sugeria passar as credenciais ao kernel via XenStore. Com base em Nitro, hoje seria ainda mais fácil implementar isso
    Bastaria o kernel receber as credenciais e expô-las como um sistema de arquivos virtual capaz de definir propriedade e permissões
  • A Scaleway permite obter o token apenas em portas abaixo de 1024
    É curioso que só processos com a permissão CAP_NET_BIND_SERVICE consigam acessar
    Se usar sockets vsock(7), isso vira uma forma de conexão mais difícil de enganar e mais segura
    Indo além, se você colocar credenciais de bootstrap nos dados DMI, elas ficam em um diretório sysfs legível apenas por root

• Verifiquei e-mails de 2007, e era verdade que no começo o acesso aos serviços da AWS precisava ser solicitado individualmente
  Primeiro fui aprovado apenas para o “Amazon E-Commerce Service”, e depois obtive acesso ao S3 e ao beta do EC2 nessa ordem
  Na época, o “Alexa Web Information Service” não era assistente de voz, e sim uma API de busca na web. Tempos realmente interessantes

• É um registro histórico-técnico realmente interessante
  Impressiona ver que até engenheiros famosos como Tavis Ormandy podem cometer erros em entrevistas
  Gosto muito desse tipo de post de blog com relatos de experiência

• É revelador que, numa retrospectiva de 20 anos, não haja menção a Hetzner ou OVH
  Eu uso AWS, Hetzner e nuvens menores ao mesmo tempo, e a diferença de preço é enorme
  A AWS custa $350 por mês; a Hetzner sai por 20~25 euros com especificações parecidas e 20 TB de tráfego incluídos
  O que a AWS vende hoje já não é compute, e sim o modelo de IAM, a infraestrutura global e o consenso organizacional
  A percepção de que “ninguém é demitido por escolher AWS” é o verdadeiro produto
  Gostaria de perguntar a quem migrou workloads recentemente para fora da AWS — o que acabou sendo mais doloroso do que o esperado?