Encontrei uma pergunta semelhante, mas ainda não responde às minhas perguntas Os espaços de endereço virtual de todos os processos têm o mesmo conteúdo em suas partes "Kernel"?
Primeiro, considerando que os processos do usuário não têm acesso a essa parte e acho que se eles tentarem acessá-la, isso levaria a um erro, então por que incluir essa parte no espaço virtual do processo do usuário? Vocês podem me dar um cenário da vida real dessa parte sendo essencial e útil?
Além disso, mais uma pergunta é que eu sempre pensei que a parte do kernel da memória é dinâmica, o que significa que pode crescer, por exemplo, quando usamos bibliotecas dinâmicas em nossos programas, então é verdade? Em caso afirmativo, como o sistema operacional pode determinar o tamanho do kernel no espaço virtual de nossos processos?
E quando nosso kernel na memória física cresce ou muda, o mesmo efeito acontece na parte do kernel da memória virtual para todos os processos? O mapeamento desse kernel virtual para o kernel real é um mapeamento de um para um?
O mapeamento do kernel existe principalmente para os propósitos do kernel, não para os processos do usuário. Do ponto de vista da CPU, qualquer endereço de memória física que não seja mapeado como um endereço linear pode não existir. Mas a CPU precisa ser capaz de chamar o kernel: para atender interrupções, lidar com exceções... Ela também precisa ser capaz de chamar o kernel quando um processo de usuário emitir uma chamada de sistema acontecer, então não entrarei em detalhes). Na maioria, se não em todas as arquiteturas, isso acontece sem a oportunidade de alternar tabelas de páginas — veja por exemplo
SYSENTER. Portanto, no mínimo, os pontos de entrada no kernel precisam ser mapeados no espaço de endereço atual o tempo todo.As alocações de kernel são dinâmicas, mas o espaço de endereço não é. No x86 de 32 bits, várias divisões estão disponíveis, como a divisão de 3/1 GiB mostrada no diagrama; em x86 de 64 bits, a metade superior do espaço de endereço é reservada para o kernel (consulte o mapa de memória na documentação do kernel). Essa divisão não pode se mover. (Observe que as bibliotecas são carregadas no espaço do usuário. Os módulos do kernel são carregados no espaço do kernel, mas, novamente, isso apenas altera as alocações, não a divisão do espaço de endereço.)
No modo de usuário, há um único mapeamento para o kernel, compartilhado por todos os processos. Quando um mapeamento de página do lado do kernel é alterado, essa alteração é refletida em todos os lugares.
Quando o KPTI está habilitado, o kernel tem seus próprios mapeamentos privados, que não são expostos ao executar o código do espaço do usuário; portanto, com o KPTI, há dois mapeamentos e as alterações no kernel privado não serão visíveis para o espaço do usuário (que é o ponto principal do KPTI).
O mapa de memória do kernel sempre mapeia todo o kernel (no modo kernel ao executar KPTI), mas não é necessariamente um para um — em x86 de 64 bits, por exemplo, ele inclui um mapa completo de memória física, portanto, todos os endereços físicos do kernel são mapeado pelo menos duas vezes.
Outra pequena dica para um entendimento mais comum por definição de kernel ele deve estar ativo o tempo todo para realizar serviços administrativos e fornecer serviços para aplicações de usuários. Essa atividade é praticamente alcançada vinculando logicamente o kernel em todos os processos.
Isso também faz sentido, considerando que vários processos estão sendo executados em um ambiente de máquina com um único processador e também considere que a estrutura do processo não contém o mapeamento do kernel . Como há apenas um processador, uma vez que um processo está agendado para execução, isso definitivamente significa que o kernel não está ativo, pois a CPU está ocupada pelo processo, além disso, assumimos que não há mapeamento de kernel disponível no processo. Agora a questão lógica é como o kernel realizaria seus serviços, então a solução é mapear o kernel em cada processo.
É assim que eu acho que todo ser humano tem um mapeamento para o criador.