Libseccomp: ERRO: seccomp_arch_add () retorna -EEXISTS na incompatibilidade de endian

Criado em 20 jun. 2017  ·  18Comentários  ·  Fonte: seccomp/libseccomp

(observe que minha descrição do problema começa com golang, mas na verdade é um problema C, veja abaixo)

Eu estava escrevendo alguns testes de unidade hoje que exercem ScmpFilter.AddArch (seccomp.ArchPPC) em meu sistema amd64. Isso não retornou nenhum erro, no entanto, a arquitetura não foi adicionada ao filtro (conforme visível por meio de exportPFC).

Aqui está um reprodutor trivial (precisa ser executado em amd64 ou i386):

package main

import (
    "os"
    "github.com/seccomp/libseccomp-golang"
)

func main() {
    secFilter, err := seccomp.NewFilter(seccomp.ActKill)
    if err != nil {
        panic(err)
    }
    err = secFilter.AddArch(seccomp.ArchPPC)
    if err != nil {
        panic(err)
    }
    secFilter.ExportPFC(os.Stdout)
}

Depois de um pouco de depuração, descobriu-se que seccomp_arch_add () retornará EEXIST se houver uma incompatibilidade de endian. Em db.c: db_col_db_add () existe:

if (col->endian != 0 && col->endian != db->arch->endian)
        return -EFAULT;

O código golang (com razão) ignora EEXIST, o que leva ao comportamento que observei.

Eu me pergunto se faria sentido que seccomp_arch_add () retornasse um código de erro diferente, talvez EINVAL ou algo assim? Se isso for muito perigoso (pois pode quebrar os aplicativos existentes), talvez possa ser melhor documentado. Estou feliz em fornecer um PR.

bug prioritmedium
Fonte
picture mvo5

Todos 18 comentários

Obrigado por relatar isso, vou ter que dar uma olhada mais de perto.

pcmoore picture pcmoore em 21 jun. 2017

Lamento muito ter demorado tanto para retornar a este @ mvo5 . Agradeço sua paciência.

Para esclarecer um pouco as coisas, o db.c atual relevante: db_col_db_add () se parece com isto:

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... Acho que a versão acima no relatório de problema original era uma cópia com patch local para solucionar o problema. Dito isso, alterar o erro retornado aqui parece razoável; temos usado EDOM em pelo menos alguns dos outros códigos arch / endian, isso parece razoável para você?

O que você acha @mheon?

Parece que provavelmente também devemos atualizar db.c: db_col_merge () enquanto estamos nisso.

pcmoore picture pcmoore em 15 jan. 2019
👍1

Do ponto de vista da API, definitivamente acho que faz sentido fazer a alteração - sobrecarregar códigos de erro é sempre problemático para depuração.

No lado libseccomp-golang, isso não deve exigir nenhuma alteração de código, desde que a convenção ERRNO negativa seja mantida; talvez algumas linhas de comentários sobre AddArch para explicar o que significa o novo erro, portanto, a documentação da API será completa.

mheon picture mheon em 15 jan. 2019

Travis ainda está executando um kernel muito antigo, portanto, o teste # 47 falhou novamente. Como @pcmoore mencionou há algum tempo, tentarei adicionar alguns recursos ao teste para evitar isso.

Caso contrário, todo o resto desta mudança parece bom no meu livro

drakenclimber picture drakenclimber em 4 fev. 2019

@drakenclimber Acho que você quer dizer o teste 46, não o 47, certo?

Há alguns meses, adicionei a verificação de nível de API para os testes ao vivo, mas não acho que precisamos disso para os testes bpf-sim, certo? Os testes do bpf-sim estavam funcionando sem problemas ...?

pcmoore picture pcmoore em 4 fev. 2019

Travis definitivamente vomitou no teste # 47 (KILL_PROCESS) para a execução acima. Também vi a mesma falha no CABEÇA do mestre esta manhã, quando o empurrei para um branch separado como uma verificação de integridade.

Resultado do teste 47-live-kill_process %% 001-00001: FALHA 47-live-kill_process 3 KILL_PROCESS rc = 12

Nós conversamos sobre isso há algum tempo, então minha memória pode estar nebulosa, mas eu pensei que Travis teve problemas com o teste KILL_PROCESS porque o kernel do Travis era mais antigo do que 4.14 quando esse recurso foi introduzido.

Ou estou louco ... e me esquecendo completamente?

drakenclimber picture drakenclimber em 5 fev. 2019

Hmm, estamos olhando para o mesmo log? Estou olhando para a compilação e o registro abaixo:

... que mostram os seguintes resultados (copiei apenas os testes "c" aqui, os resultados "python" foram os mesmos):

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... e sim, os kernels mais antigos têm problemas com alguns dos testes ativos, mas isso deveria ter sido corrigido em 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW, o último Travis build no branch master foi executado sem problemas:

Acabei de acionar uma nova construção usando o branch master apenas para verificar se tudo está "OK" com o Travis:

pcmoore picture pcmoore em 5 fev. 2019

Eu admito que agora estou _realmente_ confuso. Seu link definitivamente mostra que o teste # 46 é o problema. Mas quando eu clico no link "Raw Log" no canto superior direito, ele me diz que # 47 falhou. Para o link que você listou acima, é aqui que o registro bruto me redirecionou:

drakenclimber picture drakenclimber em 5 fev. 2019

Olhando mais de perto, acho que ambos estamos certos.

46 está retornando ERROR como você apontou. E # 47 está retornando FAILURE (que é o que eu havia pesquisado originalmente).

E isso também é visível nos resumos:

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0
drakenclimber picture drakenclimber em 5 fev. 2019

Sou capaz de reproduzir os problemas do TravisCI em um dos meus sistemas se inicializar em um kernel 3.x. O teste 46 acaba tendo problemas em sys_chk_seccomp_action () . Isso faz com que seccomp_init () retorne um contexto NULL de volta ao teste.

Eu imagino que os problemas do Teste 47 sejam semelhantes, mas não investiguei seu caminho de falha. (Embora a alteração @pcmoore adicionada para verificar a API deva ter evitado isso. Hmmm ...)

Eu ficaria curioso para saber o que mudou em Travis para causar isso. Eles voltaram para um kernel realmente antigo? Algo do nosso lado?

Parece que precisaremos adicionar alguma inteligência aos testes bpf-sim para lidar com isso. Queremos imitar a coluna API adicionada ao arquivo * .tests ou fazer algo totalmente diferente?

drakenclimber picture drakenclimber em 5 fev. 2019

Sim, estou realmente confuso sobre por que estava funcionando, mas agora não está. Ubuntu 14.xx é muito antigo hoje em dia, vou ver se existe uma versão mais recente disponível no Travis.

pcmoore picture pcmoore em 5 fev. 2019

Parece que o Ubuntu 16.04 (Xenial) está disponível, vamos tentar isso ...

pcmoore picture pcmoore em 5 fev. 2019

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 nos leva ao Ubuntu 16.04. Estou fazendo isso no branch master, não como PR, porque quero forçar essa troca; se a compilação quebrar, nós consertaremos.

pcmoore picture pcmoore em 5 fev. 2019
👍1

Essa compilação parecia ter corrigido o problema com os testes, mas o clang acabou de encontrar um vazamento de memória em um caminho de código de tratamento de erros. Vou consertar isso em apenas um minuto.

pcmoore picture pcmoore em 5 fev. 2019

Incrível! Obrigado pela ajuda, @pcmoore

drakenclimber picture drakenclimber em 5 fev. 2019

Ok, com o commit f8854f990004e71ccb9955c33d88d82cdb97ea42, devemos ter um branch master de construção limpo. Funcionou bem no meu branch pessoal, aguardando a compilação principal agora.

pcmoore picture pcmoore em 5 fev. 2019

@drakenclimber Vejo que você tem um patch pronto para isso no registro de problemas acima, mas não vejo um PR ainda - você ainda está procurando alguns problemas com o patch ou está pronto para um PR?

pcmoore picture pcmoore em 18 fev. 2019

Isso deve ser resolvido com o commit 4a35b6ea6f7c836734536420c50a2745a9e24c69, encerrando agora. Se alguém encontrar um problema com isso, reabra o problema ou crie um novo.

pcmoore picture pcmoore em 18 fev. 2019
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

cgwalters picture cgwalters  ·  14Comentários
kloetzl picture kloetzl  ·  19Comentários
Xyene picture Xyene  ·  15Comentários
vasanthaganeshk picture vasanthaganeshk  ·  9Comentários
drakenclimber picture drakenclimber  ·  10Comentários