Systemd-swap: Problemas com a recente adição de SystemCallFilters em alguns sistemas baseados em ARM

Interessante, sua mudança não corrige realmente o problema subjacente (pelo que posso dizer), apenas faz com que se systemd-swap execute algo que não está na SystemCallFilter whitelist há erros em vez de encerrar o processo.

Gostaria de saber qual chamada de sistema causa esse erro e adicioná-la à lista de permissões.:pensando:
Você poderia:

1. Veja se a remoção de SystemCallArchitectures=native corrige o problema?
2. Na linha 3 em systemd-swap adicione um x para que leia set -xuo pipefail e tente novamente? (E forneça logs completos (embora eles possam ser muito longos para carregar em um comentário, então você pode querer usar um pastebin)).

Infelizmente, eu só possuo hardware x86, então não posso testar isso sozinho.

Sim, essa é minha opinião também. A adição de SystemCallErrorNumber = EPERM apenas retornará um erro e não encerrará imediatamente o processo. Talvez não seja o ideal - eu entendo.

Eu colei três testes no Odroid-XU4 depois de alterar a linha 3 no script para set -xuo pipefail aqui: https://pastebin.com/UZk74aKx

Teste 1 - SystemCallArchitectures removido = nativo. Mesma falha / coredumps de sort e mkswap
Teste 2 - executado com um arquivo systemd-swap.service não modificado do systemd-swap 4.2.3. Mesma falha / coredumps.
Teste 3 - SystemCallErrorNumber = EPERM ... adicionado novamente e, claro, funciona bem.

Todos os 3 testes estão incluídos no mesmo pastebin. Pesquise em "Teste" para localizar cada um.

Se houver mais alguma coisa que eu possa testar ou tentar, fico feliz em ajudar.

Você pode tentar com SystemCallFilter=@system-service <strong i="5">@swap</strong> <strong i="6">@module</strong> uname e tudo mais não modificado?

E se isso produzir um travamento, forneça um rastreamento de pilha de mkswap. Deve aparecer no diário logo após a falha. Alternativamente, você pode obtê-lo através do núcleo despejado usando gdb usando algo como gdb -c <dumped core> e thread apply all bt full .

Você também pode tentar obter um reprodutor mínimo usando uma unidade transitória, o que pode ser mais conveniente para depuração:

dd if=/dev/zero of=test count=32 bs=1M
sudo systemd-run -t -d -p Type=exec -p "SystemCallFilter=@system-service <strong i="13">@swap</strong> @module" -p SystemCallArchitectures=native mkswap test`

Não consegui reproduzir em AArch64 / ARM64, ARMv8.

Infelizmente, adicionar uname a SystemCallFilter ainda resulta em um despejo. :( Veja abaixo o rastreamento da pilha. Não há símbolos, infelizmente.

FWIW, eu executo zswap_enabled = 0 e zram_enabled = 1 - não tenho uma partição swap real, então uso zram apenas como swap.

Eu tenho um Odroid-N2 também executando archlinuxarm e sua configuração quase idêntica ao Odroid-XU4 e Pi3. Eu não estava usando o systemd-swap no N2. Só para ver o que acontece, instalei o systemd-swap com o arquivo de serviço "stock" no N2. Desativei o zswap e ativei o zram exatamente como no XU4. Funciona bem no N2 - sem coredumps. O N2 é ARMv8 / aarch64. O XU4 / Pi3 são ambos ARMv7. Como você, também não consigo reproduzir no ARMv8 / aarch64.

Posso desenterrar outro cartão SD para o antigo Pi3 e tentar Raspbian (ou ???) em vez de archlinuxarm nele. Talvez este seja algum problema específico do archlinuxarm estranho com suas compilações ARMv7?

Ainda feliz em tentar qualquer outra sugestão ... mas entendo totalmente se você estiver sem ideias.

Jul 01 20:20:59 xu4 systemd-swap[256]: /usr/bin/systemd-swap: line 52: 
   335 Bad system call         (core dumped) mkswap "${zram_dev}" &> /dev/null
Jul 01 20:20:59 xu4 systemd-swap[256]: + systemctl daemon-reload
Jul 01 20:21:00 xu4 systemd-coredump[338]: Process 335 (mkswap) of user 0 dumped core.

                                           Stack trace of thread 335:
                                           #0  0x00000000b6e04e58 posix_fadvise64 (libc.so.6 + 0xd2e58)


           PID: 335 (mkswap)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 31 (SYS)
     Timestamp: Wed 2020-07-01 20:20:59 MDT (18min ago)
  Command Line: mkswap /dev/zram0
    Executable: /usr/bin/mkswap
 Control Group: /system.slice/systemd-swap.service
          Unit: systemd-swap.service
         Slice: system.slice
       Boot ID: 734e377074d04e70a5da783259d3fb10
    Machine ID: b16181464c2c4ea7adb0a759515a8a9a
      Hostname: xu4
       Storage: /var/lib/systemd/coredump/core.mkswap.0.734e3770[...]00.lz4
       Message: Process 335 (mkswap) of user 0 dumped core.

                Stack trace of thread 335:
                #0  0x00000000b6e04e58 posix_fadvise64 (libc.so.6 + 0xd2e58)



Thread 1 (LWP 335):
#0  0xb6e04e58 in posix_fadvise64 () from /usr/lib/libc.so.6
No symbol table info available.
#1  0xb6e8fe68 in blkid_probe_set_device () from /usr/lib/libblkid.so.1
No symbol table info available.
#2  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
quit

Talvez este seja algum problema específico do archlinuxarm estranho com suas compilações ARMv7?

Pode ser.

@system-service deve incluir a chamada de sistema fadvise64 , portanto, se eles não modificaram os grupos de chamadas de sistema para systemd e os removeram (consulte systemd-analyze syscall-filter @system-service ), isso não deveria acontecer qualquer diferença em tentar colocá-lo na lista de permissões, mas você pode tentar se ainda não o fez.
Isso, é claro, presumindo que ele sempre trava naquele syscall exato.

Visto que não parece diretamente relacionado a systemd-swap e devido à documentação do systemd realmente recomendar a adição de SystemCallErrorNumber=EPERM , ele deve apenas ser adicionado à unidade de serviço em minha opinião.

Seria ótimo se você pudesse obter sinalizadores de depuração e postar o coredump aqui para que possamos ver qual função em mkswap causa o erro.

Ainda sou parcial para a solução original de apenas adicionar SystemCallErrorNumber=EPERM - hahaha. Estou feliz por você ter ido em frente e feito isso. Muito apreciado! Economiza uma substituição de serviço do systemd para uma versão futura. 👍

Também estou um tanto curioso sobre por que é bombardeado nos dispositivos ARMv7. Não é apenas mkswap , mas também sort e blkid . Vou pegar um par de ARMv7 R-Pis antigo e fazer instalações novas / atuais do ArchlinuxARM e Raspian / Debian. Irá testar ambos com systemd-swap e ver se o problema ocorre em ambos os sistemas operacionais. Vou ver se consigo mais lixões carnudos.

Embora não haja símbolos de depuração presentes, ainda sabemos quais funções foram chamadas antes da falha devido às tabelas de símbolos dinâmicas.

mkswap chama blkid_probe_set_device que chama posix_fadvise (um invólucro fino em torno do syscall) para desabilitar a leitura antecipada realizada pelo kernel.

E, até onde eu sei, todos os utilitários de travamento mencionados usam o fadvise64 syscall de uma forma ou de outra.

Ainda tenho algumas perguntas que podem ser respondidas sem símbolos de depuração / uma nova instalação:

• Eu gostaria de ver alguns dos outros rastreamentos de pilha de mkswap (é semelhante?), sort e blkid .
• Eles travam em todas as invocações?
• Qual é o resultado de invocá-los autônomos com a unidade transitória, conforme mencionado em meu post anterior?
• A lista de permissões de fadvise64 ajuda?

Sim, mkswap , sort e blkid travam todas as vezes - sempre com um rastreamento de pilha apontando para posix_fadvise64 . O mesmo acontece com o teste de unidade transiente mkswap.

Eu verifiquei que fadvise64 (e fadvise64_64) estão ambos na lista de filtros padrão @system-service systemd syscall. Colocar na lista de permissões não faz diferença. :(

Também fiz um teste rápido em uma nova instalação do Raspbian com os mesmos resultados ... então parece que não é um problema específico do ArchlinuxARM.

Executar strace mkswap temp fora do systemd e quaisquer filtros syscall não mostra nenhum problema - como você esperava:

fadvise64_64(3, 0, 0, POSIX_FADV_RANDOM) = 0

Executando strace mkswap temp via systemd (sua unidade transitória modificada - ótima ideia!) Com @system-service <strong i="19">@swap</strong> <strong i="20">@module</strong> @debug todos os programas da lista de permissões systemd relatando o processo diretamente na chamada fadvise64_64:

fadvise64_64(3, 0, 0, POSIX_FADV_RANDOM) = ?
+++ killed by SIGSYS (core dumped) +++

Estou bem no final do meu conhecimento / habilidade para descobrir o que está acontecendo. 😄

Obrigado.

Isso soa como alguma estranheza do systemd / seccomp no ARMv7.

Se você permitir que o systemd instale um filtro seccomp para um syscall não relacionado (por exemplo, algo de @obsoleto ou @depurar via lista negra, como SystemCallFilter=~ptrace ), ele trava?

Além disso, não conheço nenhuma outra maneira de depurar isso sem entrar em detalhes. Acho que o melhor curso de ação seria relatar isso ao mantenedor / devs do systemd.

Colocar algo não relacionado na lista negra ainda causa um travamento, a menos que SystemCallErrorNumber=EPERM também seja adicionado ao serviço.

... mas como você mencionou, isso parece ser um problema estranho do systemd / seccomp com ARMv7.

Como mais um teste para minha própria curiosidade, editei systemd-swap.service com estas configurações SystemCall *:

SystemCallArchitectures=native
SystemCallFilter=@system-service <strong i="10">@swap</strong> <strong i="11">@module</strong>
SystemCallFilter=~finit_module
SystemCallErrorNumber=EPERM

Eu especificamente coloquei finit_module lista negra - então o módulo zram NÃO deve carregar.

No Odroid-N2 (aarch64) executando ArchlinuxARM w / systemd 245.6 ele falha como você esperaria - não é possível carregar o módulo zram . Com ou sem SystemCallErrorNumber=EPERM tudo parece estar funcionando normalmente no N2 / aarch64 & seccomp.

Jul 02 19:08:26 n2 systemd[1]: Starting Manage swap spaces on zram, files and partitions....
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Load: /etc/systemd/swap.conf
Jul 02 19:08:27 n2 systemd-swap[3924]: WARN: Combining zram with zswap/swapfc/swapd_auto_swapon [...]
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Zram: check availability
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Zram: not part of kernel, trying to find zram module
Jul 02 19:08:27 n2 systemd-swap[3963]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:27 n2 systemd[1]: Started Manage swap spaces on zram, files and partitions..
Jul 02 19:08:28 n2 systemd-swap[4040]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:29 n2 systemd-swap[4042]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:30 n2 systemd-swap[4043]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:31 n2 systemd-swap[4044]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:49 n2 systemd-swap[4052]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:50 n2 systemd-swap[4053]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:51 n2 systemd-swap[4054]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:52 n2 systemd-swap[4056]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:53 n2 systemd-swap[4057]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: module successfully loaded
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: trying to initialize free device
Jul 02 19:08:54 n2 systemd-swap[3924]: WARN: Zram: zramctl can't find free device
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: using workaround hook for hot add
Jul 02 19:08:54 n2 systemd-swap[3924]: ERRO: Zram: this kernel does not support hot adding zram devices [...]
Jul 02 19:08:54 n2 systemd[1]: systemd-swap.service: Main process exited, code=exited, status=1/FAILURE
Jul 02 19:08:54 n2 systemd[1]: systemd-swap.service: Failed with result 'exit-code'.

Em um antigo Pi2 (armv7l) também rodando ArchlinuxARM w / systemd 245.6 ele não falha! zram módulo

Jul 02 19:14:07 alarmpi systemd[1]: Starting Manage swap spaces on zram, files and partitions....
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Load: /etc/systemd/swap.conf
Jul 02 19:14:08 alarmpi systemd[1]: Started Manage swap spaces on zram, files and partitions..
Jul 02 19:14:08 alarmpi systemd-swap[299]: WARN: Combining zram with zswap/swapfc/swapd_auto_swapon [...]
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Zram: check availability
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Zram: not part of kernel, trying to find zram module
Jul 02 19:14:09 alarmpi systemd-swap[299]: INFO: Zram: module successfully loaded
Jul 02 19:14:10 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:10 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram0
Jul 02 19:14:12 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:13 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram0
Jul 02 19:14:14 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:14 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram1
Jul 02 19:14:16 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:16 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram2
Jul 02 19:14:17 alarmpi systemd-swap[299]: INFO: swapD: pickup devices from systemd-gpt-auto-generator
Jul 02 19:14:17 alarmpi systemd-swap[299]: INFO: swapD: searching swap devices

Parece que o material SystemCallFilter / seccomp está quebrado / ignorado no dispositivo armv7l ... E definitivamente desmorona, a menos que SystemCallErrorNumber=EPERM também esteja configurado no arquivo .service. Testes muito breves usando o mesmo Pi2 e Raspbian (versus ArchlinuxARM) exibem o mesmo problema. Em um Odroid-XU4 (armv7l também) - mesmo problema.

Portanto, agradeço que você esteja adicionando SystemCallErrorNumber=EPERM , pois isso não parece causar nenhum problema em outras plataformas e conserta magicamente uma situação muito danificada no armv7l. 👍 Vou fazer mais pesquisas / leituras / testes no Google. Se eu puder escrever algo que não soe ridículo com algumas evidências e / ou provas, posso enviar um problema com o pessoal do systemd para ver o que eles podem sugerir. 😄

Agradecemos sua ajuda e paciência! Obrigada.

Colocar algo não relacionado na lista negra ainda causa um travamento, a menos que SystemCallErrorNumber=EPERM também seja adicionado ao serviço.

... mas como você mencionou, isso parece ser um problema estranho do systemd / seccomp com ARMv7.

Sim, é isso que eu estava tentando teste com lista negra única uma chamada não relacionada, sem filtrar qualquer outra coisa.

SystemCallErrorNumber=EPERM apenas retorna EPERM para o processo infrator em vez de enviar SIGSYS e despejar o núcleo como consequência.

Eu acho que isso poderia introduzir algum comportamento indefinido se o processo depender do syscall para funcionar e não verificar o sucesso. Portanto, eu chamaria isso de solução alternativa, não de solução.

A próxima etapa pode ser habilitar a depuração do systemd, já que seu teste de lista negra mostra que há algo errado.

https://freedesktop.org/wiki/Software/systemd/Debugging/

Boa sorte.

Eu acho que isso está sendo fechado como um bug do ArchlinuxARM? Isso afeta outras distros também?

Deve afetar as plataformas ARM independentemente da distro.

É uma coisa de hardware ou linux?

Coisa do Linux, o problema é que a proteção do nosso serviço depende da lista de permissões do systemd que está configurada incorretamente para algumas syscalls ARM, então embora as syscalls devam ser permitidas, elas não são.