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

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

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

Meu primeiro palpite foi que um motivo de segundo plano foi manter aplicativos de 32 bits executáveis ​​em um sistema x86_64, para 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 ou 64 bits. respectivamente. No entanto, este não é o caso. Pelo menos parece-me que read () sendo o número de chamada do sistema 0 em x86_64 não pode ser alinhado com esse pensamento.

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

Ignorando os desafios da implementação das partes de código dependentes da arquitetura, ainda me pergunto como alterar os números de chamada do sistema , quando parece não haver necessidade (pois mesmo um registro de 16 bits armazenaria muito mais que os atualmente ~ 346 números para representar todos os chamadas), ajudaria a conseguir qualquer coisa, além de quebrar a compatibilidade (embora o uso das chamadas do sistema por meio de uma biblioteca, a libc a atenue).

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

Eu não sei o suficiente sobre o desenvolvimento do kernel para saber a base específica para essas opções, mas aparentemente existe alguma lógica por trás da escolha de renumerar tudo com esses números específicos, em vez de simplesmente copiar a lista de uma arquitetura existente e remover os não utilizados. Parece que o pedido pode se basear na frequência com que são chamados - por exemplo, leitura / gravação / abertura / fechamento são antecipados. Saída e bifurcação podem parecer "fundamentais", mas cada uma delas é chamada apenas uma vez por processo.

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

Veja a 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) era diferente, assim os desenvolvedores do kernel aproveitaram a oportunidade para trazer mudanças que há muito esperavam.

Em resumo, porque alguém pensou que " N+1maneiras incompatíveis de fazê-lo são melhores do que Nmaneiras". Para arcos históricos, os números de syscall geralmente eram escolhidos para corresponder a algum unix proprietário herdado. Mas para o x86_64, os desenvolvedores do kernel foram livres para escolher qualquer numeração que quisessem. Em vez de fazer a escolha simples e reutilizar uma numeração existente, eles fizeram a escolha de inventar um novo padrão. Então eles fizeram isso novamente para aarch64 e muitos outros. Esse é um padrão frequentemente repetido no desenvolvimento do kernel do Linux.