Por que os números de chamada do sistema Linux em x86 e x86_64 são diferentes?

Question

Eu sei que a interface de chamada do sistema é implementada em um nível baixo e, portanto, dependente da arquitetura / plataforma, e não do código "genérico".

No entanto, não consigo ver claramente o motivo pelo qual as chamadas de sistema nos kernels x86 de 32 bits do Linux têm números que não são mantidos iguais na arquitetura semelhante Linux x86_64 de 64 bits? Qual é a motivação / razão por trás dessa decisão?

Meu primeiro palpite é que uma razão de fundo tem sido manter aplicativos de 32 bits executáveis em um sistema x86_64, de modo que, através de um deslocamento razoável para o número de chamada do sistema, o sistema saiba que o espaço do usuário é de 32 bits ou 64 bits, respectivamente. Este não é o caso. Pelo menos parece-me que read () sendo número de chamada do sistema 0 em x86_64 não pode ser alinhado com este pensamento.

Outro palpite é que alterar os números de chamada do sistema pode ter um histórico de segurança / proteção, algo que não consegui confirmar.

Sendo ignorante quanto aos desafios de implementação das partes do código dependentes da arquitetura, ainda me pergunto como alterar os números de chamada do sistema, quando parece não haver necessidade (como até mesmo um registro de 16 bits armazenaria em grande parte mais do que os atualmente ~ 346 números para representar todas as chamadas), ajudaria a conseguir qualquer coisa, além de quebrar a compatibilidade (embora usando as chamadas do sistema através de uma biblioteca, libc, atenua).

    

Answer 1

Quanto ao raciocínio por trás da numeração específica, que não corresponde a nenhuma outra arquitetura [exceto "x32" que é realmente apenas parte da arquitetura x86_64]: Nos primórdios do suporte x86_64 no kernel do linux, antes havia qualquer restrição séria de compatibilidade com versões anteriores, todas as chamadas do sistema foram renumeradas para otimizá-la no nível de uso da cacheline .

Eu não sei o suficiente sobre o desenvolvimento do kernel para saber a base específica para essas escolhas, mas aparentemente há alguma lógica por trás da opção de renumerar tudo com esses números em vez de simplesmente copiar a lista de uma arquitetura existente e remover os não usados. Parece que o pedido pode ser baseado em como eles são comumente chamados - por exemplo, read / write / open / close estão na frente. A saída e o garfo podem parecer "fundamentais", mas cada um deles é chamado apenas uma vez por processo.

Também pode haver algo acontecendo sobre manter as chamadas do sistema que são comumente usadas juntas na mesma linha de cache (esses valores são apenas inteiros, mas há uma tabela no kernel com ponteiros de função para cada um, então cada grupo de 8 chamadas de sistema ocupam uma linha de cache de 64 bytes para essa tabela)

    

Answer 2

Veja essa resposta à pergunta "Por que os números de chamada do sistema são diferentes no amd64 linux?" no estouro de pilha.

Para resumir: por uma questão de compatibilidade, a lista de chamadas do sistema é estável e só pode crescer. Quando a arquitetura x86 64 apareceu, a ABI (passagem de argumento, valor retornado) foi diferente, assim os desenvolvedores do kernel aproveitaram a oportunidade para trazer mudanças que há muito aguardavam.

    

Answer 3

Em resumo, porque alguém pensou que " N+1 formas gratuitas incompatíveis de fazer isso são melhores que N ways". Para archs históricos, os números syscall eram geralmente escolhidos para combinar com algum unix proprietário herdado. Mas para x86_64 os desenvolvedores do kernel estavam livres para escolher qualquer numeração que gostassem. Em vez de fazer a escolha simples e reutilizar uma numeração existente, eles optaram por inventar um novo padrão. Então eles fizeram isso novamente por aarch64 e um monte de outros. Este é um padrão frequentemente repetido no desenvolvimento do kernel Linux.