Atividade do GrapheneOS em redes sociais
- O GrapheneOS faz parte de uma rede social descentralizada baseada em Mastodon.
- Está operando um servidor GrapheneOS para a conta oficial do projeto e para membros do projeto.
- O servidor tem 5 usuários ativos.
Suporte a marcação de memória por hardware no Pixel 8 e Pixel 8 Pro
- No Pixel 8 e no Pixel 8 Pro, o suporte a marcação de memória por hardware permitiu descobrir um bug de corrupção de memória no Bluetooth LE do Android 14 QPR2.
- No momento, estão investigando esse bug para corrigi-lo ou encontrar uma solução temporária que desative provisoriamente o recurso recém-introduzido.
Desativar a marcação de memória não é uma solução temporária adequada
- Isso ocorre apenas com certos dispositivos Bluetooth LE, não com todos os dispositivos Bluetooth.
- Desativar a marcação de memória para esse processo não pode ser aceito nem como solução de curto prazo.
Desenvolvimento de patch para o bug no Android 14 QPR2
- Foi descoberto um bug de use-after-free relacionado ao Bluetooth LE e foi desenvolvido um patch.
- A prioridade é incluir a correção nas releases do GrapheneOS, e o problema será reportado como um bug de segurança do Android.
- Espera-se que problemas de áudio BLE também sejam resolvidos.
Confirmação da correção do bug
- Um usuário com Samsung Galaxy Buds2 Pro reproduziu o problema no modo Bluetooth LE e confirmou que a correção funciona.
- Esse problema também afeta o Pixel OS padrão.
- O GrapheneOS detectou isso com o suporte a marcação de memória do
hardened_malloc e adicionou recursos para enviar alertas e relatórios de falhas de MTE.
Reportado como bug de segurança
- O problema de use-after-free foi reportado como bug de segurança (b/328916844 para funcionários do Google).
- Foi fornecido um patch inicial minimamente intrusivo.
- O código precisa de uma grande refatoração e não deveria usar ponteiros brutos, mas querem evitar introduzir novos bugs com um patch apressado.
Portar o código de Bluetooth para Rust
- O Android está portando grande parte do código de Bluetooth para Rust.
- Mais recursos precisam ser dedicados para portar também o restante do código para Rust.
- Builds com HWASan e MTE precisam ser testadas em vários ambientes reais de uso.
A importância do MTE
- Os Pixels oferecem um importante recurso de segurança por hardware chamado MTE, mas ele não é ativado no sistema operacional para economizar 3,125% de uso de memória/cache.
- O GrapheneOS ativa o MTE por padrão para o sistema operacional básico e para apps instalados pelo usuário com compatibilidade conhecida.
- O usuário pode ativar o MTE para todos os apps instalados pelo usuário nas configurações.
Implementação de MTE no GrapheneOS
- O GrapheneOS oferece uma implementação melhor de MTE como parte do
hardened_malloc, usando tags aleatórias padrão e uma tag dedicada para free.
- Corrigiu a integração do Chromium e pretende melhorar o PartitionAlloc.
Uso de MTE no GrapheneOS
- O GrapheneOS é a primeira plataforma a usar MTE em ambiente de produção.
- O navegador Vanadium é o primeiro navegador a usar MTE em ambiente de produção.
- Há planos para adicionar stack MTE, melhorar o PartitionAlloc e criar um novo slab MTE para o kernel.
Agradecimento dos usuários
- Usuários demonstraram agradecimento pelo recurso de desativação automática do Bluetooth no GrapheneOS.
Opinião do GN⁺
- O GrapheneOS é um sistema operacional focado em segurança baseado em Android e demonstrou capacidade de detectar e responder rapidamente a um bug de corrupção de memória encontrado em dispositivos Pixel mais recentes.
- Essa resposta rápida mostra bem as vantagens da comunidade open source e contribui para oferecer um ambiente móvel mais seguro aos usuários.
- A migração de código para a linguagem Rust, que reforça a segurança de memória, é um passo importante para o fortalecimento da segurança no longo prazo.
- Ativar o MTE, um recurso de segurança baseado em hardware, é uma forma eficaz de reforçar a segurança com impacto mínimo no desempenho.
- Ao adotar essa tecnologia, é preciso considerar a compatibilidade com aplicativos existentes, além de realizar testes e manutenção adequados para fortalecer a segurança.
1 comentários
Comentários do Hacker News
A extensão de marcação de memória não vem ativada por padrão, mas qualquer pessoa pode ativá-la nas opções de desenvolvedor. É possível ativá-la uma vez para testar um app específico ou mantê-la ativa pelo tempo que quiser.
Espera uma resposta de usuários do GrapheneOS sobre se é difícil instalar o GrapheneOS, se é necessário um cabo especial, se é preciso entender bem de dispositivos Android ou se basta seguir as instruções.
Pedido para compartilharem experiências sobre se usar o GrapheneOS no dia a dia é inconveniente, se o celular trava com frequência a ponto de exigir dias de depuração, e se apps bancários funcionam.
Questiona como a equipe do Pixel justifica a decisão de não ativar no sistema operacional um recurso importante de segurança de hardware (MTE) para economizar 3,125% de uso de memória/cache. O MTE de heap quase não tem overhead de desempenho no modo assíncrono e, no modo assimétrico, é mais barato do que proteções legadas como SSP, cuja eficácia vem diminuindo.
Pergunta sobre a comparação entre as tecnologias de segurança MTE e CHERI.
O GrapheneOS está tão à frente dos demais em termos de segurança que a escolha de qualquer coisa fora do hardware Pixel parece questionável. Ainda assim, expressa um forte desejo de ter uma bateria substituível.
Pergunta se computadores de placa única como os Raspberry Pi mais recentes implementam Arm MTE.
Aguarda hardware mainstream que possa resolver problemas de corrupção de memória, como o hardware Solaris SPARC de 2015 ou arquiteturas anteriores de marcação de memória. Esses problemas, em sua maioria, são causados por desenvolvedores com pouca habilidade técnica.
Em 2024, são necessários sistemas operacionais, aplicações e ferramentas que sigam o espírito do seL4, mas com verificação formal ainda mais rigorosa. Usar sistemas baseados em codebases excessivamente projetadas e insuficientemente testadas, como ocorre hoje, expõe os usuários a riscos e oferece uma grande superfície de ataque para bugs, malware e invasões.
Se não oferecer uma experiência de usuário (UX) limpa e integrada e recursos utilizáveis, todo o trabalho de engenharia será em vão.
O Android portou uma parte significativa do código de Bluetooth para Rust. Este é um exemplo de que mais recursos deveriam ser investidos em portar ainda mais código para Rust.
Alguém com anos de experiência em C e C++, mas sem experiência com Rust, pergunta quanto refatoramento é necessário no processo de portar de C para Rust. Pergunta também como o Google está abordando isso: se tenta fazer uma "tradução" o mais direta possível ou se trata isso como uma oportunidade para grandes reescritas/refatorações.
Curiosidade sobre se a pilha de Bluetooth do Android pode ser usada em sistemas desktop de distribuições Linux padrão.