Checkpoint de dados do usuário

O Android 10 apresenta o User Data Checkpoint (UDC), que permite que o Android reverta para o estado anterior quando um dispositivo OTA (OTA) falha. Com o UDC, se uma atualização OTA do Android falhar, o dispositivo poderá reverter com segurança ao estado anterior. Embora As atualizações A/B resolvem esse problema para inicialização antecipada e reversão. não é compatível quando a partição de dados do usuário (montada em /data) é modificada.

O UDC permite que o dispositivo reverta a partição de dados do usuário mesmo após ser modificado. O recurso UDC faz isso com funcionalidades de checkpoint para o uma implementação alternativa quando o sistema de arquivos não oferecer suporte checkpoints, a integração com o mecanismo A/B do carregador de inicialização, além de suporte atualizações não A/B e suporte para vinculação de versão de chave e reversão de chave prevenção.

Impacto no usuário

O recurso UDC melhora a experiência de atualização OTA para os usuários à medida que menos usuários perdem quando uma atualização OTA falha. Isso pode reduzir o número de chamadas de suporte de usuários que enfrentam problemas durante o processo de atualização. No entanto, quando uma OTA falha, os usuários podem notar que o dispositivo reinicia várias vezes.

Como funciona

Funcionalidade de checkpoint em diferentes sistemas de arquivos

Para o sistema de arquivos F2FS, o UDC adiciona a funcionalidade de checkpoint ao upstream 4.20 Kernel do Linux e backport para todos os kernels comuns suportados pelos dispositivos com o Android 10.

Para outros sistemas de arquivos, o UDC usa um dispositivo virtual mapeador de dispositivo chamado dm_bow. para a funcionalidade do checkpoint. dm_bow fica entre o dispositivo e o arquivo. sistema. Quando uma partição é montada, um corte é emitido, fazendo com que o sistema de arquivos emita comandos de corte em todos os blocos livres. dm_bow intercepta esses cortes e usa para configurar uma lista de bloqueio sem custo financeiro. As leituras e gravações são enviadas ao dispositivo sem modificações, mas, antes que uma gravação seja permitida, há um backup dos dados necessários para a restauração em um bloco livre.

Processo de checkpoint

Quando uma partição com a flag checkpoint=fs/block é montada, o Android chama restoreCheckpoint na unidade para permitir que o dispositivo restaure arquivos atuais de segurança. Em seguida, init chama a função needsCheckpoint para determinar se o dispositivo está no estado A/B do carregador de inicialização ou definiu a configuração contagem. Se uma delas for verdadeira, o Android chamará createCheckpoint para adicionar a montagem. ou criar um dispositivo dm_bow.

Depois que a partição é montada, o código do checkpoint é chamado para emitir cortes. O processo de inicialização continua normalmente. Em LOCKED_BOOT_COMPLETE, Android chama commitCheckpoint para confirmar o checkpoint atual e a atualização; continua normalmente.

Gerenciar chaves mestras

As chaves do Keymaster são usadas para criptografia de dispositivos ou outras finalidades. Para gerenciar chaves, o Android atrasa as chamadas de exclusão de chaves até que o checkpoint seja confirmado.

Monitorar a integridade

Um daemon de integridade verifica se há espaço em disco suficiente para criar de segurança. O daemon de integridade está localizado em cp_healthDaemon em Checkpoint.cpp.

O daemon de integridade tem os seguintes comportamentos que podem ser configurados:

APIs do Checkpoint

As APIs de checkpoint são usadas pelo recurso UDC. Para outras APIs usadas pelo UDC, consulte IVold.aidl

void startCheckpoint(inteira de tentar novamente)

Cria um checkpoint.

O framework chama esse método quando está pronto para iniciar uma atualização. A o checkpoint é criado antes que sistemas de arquivos com checkpoint, como userdata, sejam com conexão de R/W ativada após a reinicialização. Se a contagem de novas tentativas for positiva, a API processará novas tentativas de rastreamento, e o atualizador chama needsRollback para verificar se uma reversão da atualização é necessária. Se a contagem de novas tentativas for -1, a API vai adiar para a do carregador de inicialização.

Esse método não é chamado ao fazer uma atualização A/B normal.

void commitChanges()

Confirma as alterações.

O framework chama esse método após a reinicialização, quando as mudanças estão prontas para serem comprometido. É chamado antes dos dados (como imagens, vídeos, SMS, servidores recebimento do recebimento) é gravado nos dados do usuário e antes de BootComplete.

Se não houver atualização do checkpoint ativa, esse método não terá efeito.

abortChanges()

Força a reinicialização e reverte para o checkpoint. Abandona todas as modificações de dados do usuário desde a primeira reinicialização.

O framework chama esse método após a reinicialização, mas antes de commitChanges. A retry_counter é reduzida quando esse método é chamado. As entradas de registro gerada.

bool needRollback()

Determina se uma reversão é necessária.

Em dispositivos que não são de checkpoint, retorna false. Em dispositivos de checkpoint, retorna true. durante uma inicialização fora do checkpoint.

Implementar UDC

Implementação de referência

Para conferir um exemplo de como o UDC pode ser implementado, consulte dm-bow.c (link em inglês). Para acessar a documentação adicional sobre o recurso, consulte dm-bow.txt.

Configurar

Em on fs, no arquivo init.hardware.rc, verifique se você tem:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

Em on late-fs, no arquivo init.hardware.rc, verifique se você tem:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

No arquivo fstab.hardware, verifique se /data está marcado como latemount.

/dev/block/bootdevice/by-name/userdata              /data              f2fs
noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier
latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs

Adicionar partição de metadados

O UDC exige uma partição de metadados para armazenar a contagem de tentativas que não são do carregador de inicialização e chaves. Configure uma partição de metadados e ative-a antecipadamente em /metadata.

No arquivo fstab.hardware, verifique se /metadata está marcado como earlymount ou first_stage_mount.

/dev/block/by-name/metadata           /metadata           ext4
noatime,nosuid,nodev,discard,sync
wait,formattable,first_stage_mount

Inicializar a partição com todos os zeros.

Adicione as linhas abaixo a BoardConfig.mk:

BOARD_USES_METADATA_PARTITION := true
BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata

Atualizar sistemas

Sistemas F2FS

Para sistemas que usam F2FS para formatar dados, verifique se sua versão do F2FS oferece suporte a checkpoints. Para mais informações, consulte Funcionalidade de checkpoint no diferentes sistemas de arquivos.

Adicione a sinalização checkpoint=fs à seção <fs_mgr_flags> do fstab para o dispositivo montado em /data.

Sistemas não F2FS

Para sistemas não F2FS, dm-bow precisa estar ativado na configuração do kernel.

Adicione a sinalização checkpoint=block à seção <fs_mgr_flags> do fstab para o dispositivo montado em /data.

Verificar registros

As entradas de registro são geradas quando as APIs Checkpoint são chamadas.

Validação

Para testar a implementação de UDC, execute o conjunto VtsKernelCheckpointTest de VTS provas.