Qual é a diferença entre o Userland e o Kernel? [duplicado]

Question

Estou tentando entender exatamente o que é userland? todo mundo que eu pergunto diz: "Qualquer coisa que não seja kernel". mas não é tangível para mim. Quando eu estou lendo esse kernel pode rodar esse driver no userland ou algo parecido; Eu não consigo imaginar o que vai acontecer !. Então, eu apreciarei se alguém me esclarecesse a esse respeito.

    

Answer 1

Em um nível conceitual, o kernel é tudo que é executado em um nível "mais privilegiado" de proteção de hardware. Isso seria como ring 0 em processadores x86, modo de sistema em ARM, modo kernel em MIPS, modo supervisor em 68xxx, etc. O kernel geralmente é baseado em interrupções, tanto interrupções de software (chamadas do sistema) quanto interrupções de hardware (unidades de disco, rede cartões, temporizadores de hardware).

Nesse mesmo nível conceitual, "user land" é o que é executado no modo menos privilegiado (anel 3 em CPUs x86, modo de usuário em ARM ou MIPS, etc.). O user land aproveita a maneira como o kernel suaviza com pequenas diferenças de hardware, apresentando a mesma API para todos os programas. Por exemplo, algumas placas sem fio podem ter registros extras de controle em relação a outros, ou conter mais ou menos buffer interno para os pacotes de entrada. O código do driver considera essas diferenças (às vezes ignorando recursos avançados ou incomuns) e apresenta a mesma API de soquete para todos os programas.

Alguns processadores (por exemplo, x86, VAX, Alpha AXP) têm mais de dois modos, mas a arquitetura Unix genérica não usa os modos intermediários.

Os programas e processos que você vê rodando em Unix ou Linux ou * BSD são o usuário. Como os processos são preemptivos, na verdade você nunca vê o kernel sendo executado, você apenas vê efeitos colaterais, como um retorno de chamada do sistema read() ou uma função de manipulador de sinal em execução.

Para responder à sua pergunta específica, no Unix, Linux, * BSD, um "driver" geralmente é um pequeno software que lida com as peculiaridades específicas de algum hardware: uma placa de rede, uma unidade de disco, uma placa de vídeo. . O software do driver quase sempre precisa ser executado no modo Ring 0 / supervisor / espaço do kernel para ter acesso a interrupções de hardware ou à memória mapeada do hardware ou qualquer outra coisa. O driver cuida de recursos de hardware específicos e faz com que o hardware se encaixe na visão padronizada ou convencionalizada do código do kernel de como o hardware deve funcionar. Portanto, a execução de um driver no terreno do usuário requer que o kernel mostre a um programa de usuário do usuário coisas como memória mapeada ou registros de dispositivos ou interrupções ou outros recursos especiais. Isso pode ser complicado, já que os recursos especiais que um dispositivo pode exigir não se encaixam facilmente na API usual do estilo Unix apresentada aos programas de terra do usuário. Além disso, o agendamento é um problema, já que os programas de usuários geralmente não respondem a interrupções tão rapidamente.

    

Answer 2

A maioria das CPUs modernas tem um kernel ou um modo supervisor, e um modo restrito usuário . Este é um recurso de hardware da CPU. "Userland" é outro nome para o código em execução no modo de usuário.

Uma grande diferença entre os modos é com relação a como a MMU da maioria dos modens de CPUs atua sob eles.

Uma MMU permite que um kernel rearranje blocos (ou páginas) de RAM para que eles pareçam codificar em uma ordem diferente da fisicamente na RAM, e também causar código de modo de usuário para trap ou " falha "de volta ao modo kernel se certas páginas forem acessadas. O modo de usuário não pode alterar o que a MMU faz, apenas o modo kernel pode fazer isso.

Assim, a MMU permite que o código do modo kernel faça todo tipo de coisas legais, como:

• "organize" ou "mapeie" a memória para o código do modo de usuário, de modo que esse código pense que possui RAM contígua.
• implementa um esquema de gerenciamento dinâmico de memória em que um processo precisaria pedir memória antes de tentar usá-lo.
• pare os processos do usuário se eles usarem a memória que eles não deveriam.
• troque as páginas menos usadas para o disco se a memória livre ficar fraca e troque de volta quando um processo tentar acessá-las.

Você pode ver que a MMU, junto com o modo kernel / user, é a base de um sistema operacional multitarefa e, usando essas ferramentas, é possível criar um sistema que funcione com coisas de nível mais alto, como a idéia de processos. Um kernel está mantendo tabelas de páginas para cada processo e basicamente reprogramando a MMU antes de mudar para o modo de usuário e dar controle sobre um processo para o seu timeslice. Coisas como malloc e coisas onde um processo adquire memória está fazendo com que o kernel modifique tabelas de páginas MMU.

Novamente, o modo de usuário não pode fazer nada para as tabelas de páginas (e realmente não precisa saber que elas existem), se precisar de memória, ele precisa chamar o kernel, o que causa uma mudança do modo de usuário para o modo kernel. As CPUs fornecem um mecanismo simples chamado interrupção de software para fazer isso, e existem outras formas mais rápidas que o kernel Linux usa .

Devido a esta proteção que existe no modo de usuário, se um programa faz algo como travar ou ficar maluco e sobrescrever-se, o kernel pode parar este processo. No modo kernel, esta proteção não existe, então o kernel irá parar de funcionar e assim todo o seu sistema também irá parar de funcionar. Quando um erro irrecuperável acontece no modo kernel, ele é chamado de kernel panic. Veja O que é um "kernel panic"? para detalhes.

kernel can run that driver on the userland

O modo kernel ou supervisor de CPUs também impede que o modo de usuário acesse diretamente os dispositivos de E / S, a idéia é que ele tenha que chamar o kernel para fazer isso. No Linux, o código que fala diretamente com dispositivos (eles rodam no modo kernel) são drivers de dispositivos (um tipo de módulo do kernel , você pode manipulá-los com comandos como lsmod , insmod , modprobe e rmmod ).

O que acontece se o seu driver de dispositivo, que estaria rodando no modo kernel sob a configuração mais simples, tiver um bug e fizer algo desagradável como substituir coisas aleatórias na RAM (e como está no modo kernel, ele tem acesso irrestrito a toda RAM e pode sobrescrever o próprio kernel). Seria bom se pudéssemos colocar o driver de dispositivo em execução no modo de usuário, para que ele não pudesse fazer nada ao próprio kernel ou a outros processos.

Infelizmente, mudar de usuário para o modo kernel (chamado de interruptor de contexto ) é lento, já que basicamente todo o estado da CPU precisa ser ligado e desligado para cada processo ou para o próprio kernel. Então, temos duas coisas em desacordo, segurança ou velocidade e, portanto, é um ponto de discórdia e design.

Os kernels que tentam fazer o máximo possível no modo de usuário são chamados microkernels , e o Linux é o oposto, chamado monolítico . Drivers de modo de usuário existem para o Linux (veja FUSE para um exemplo) e há até mesmo um framework que permite isso.

    

Answer 3

Com base no que Bruce disse, todo código que é fornecido ao kernel deve ser confiável. Se existe alguma maneira de o código malicioso poder ser executado pelo kernel, o jogo acaba. É aí que a separação de privilégios do código executado pelo usuário e do código executado pelo kernel entra em ação. Código que é executado por um usuário não necessariamente tem que ser 100% livre do mal. Não é executado diretamente pelo kernel.

Os programas de Userland simplesmente interagem com partes expostas do kernel, como APIs e módulos carregados. Um exemplo seria iptables . Existem vários módulos do kernel (.ko) ou 'drivers' que realmente fazem o trabalho de iptables , eles fazem parte do framework netfilter . Quando você executa comandos usando /sbin/iptables , você está usando o componente userland que, por sua vez, se comunica com os módulos netfilter que são carregados no kernel. Isso permite a separação para que o código do usuário não possa ser inadvertidamente executado pelo kernel.

    

Answer 4

Uma forma de obter uma boa e completa compreensão desses conceitos seria através de um tutorial como os sobre osdev.org ou Tutorial de James Molloy .

O Linux tem um Kernel monolítico, isso significa que seu código é executado inteiramente no anel 0 na arquitetura x86, como Bruce afirmou. Assim, tendo o controle total de todos os recursos, o Kernel irá gerenciar todas as solicitações para eles por aplicativos de nível de usuário (executando no nível de privilégio mínimo 3)

Pense nisso: se os aplicativos do espaço do usuário tivessem acesso total à memória virtual - RAM - eles poderiam destruir tudo, de pilhas ou pilhas de outros processos aos buffers internos do kernel. O kernel mapeia páginas para o diretório de páginas de cada processo, e se o aplicativo se comportar mal ao tentar acessar um local que não pertence ao seu espaço de endereçamento, ele será forçado a desligar.

Em seguida, pense no que aconteceria se cada programa tivesse acesso direto a uma impressora ou outro dispositivo de saída. Duas instâncias simultâneas de processos tentando imprimir na impressora embaralhariam tudo, mas se essas solicitações passarem pelo kernel, elas serão enfileiradas e tratadas separadamente, resultando em duas páginas impressas separadas.

Além disso, como as máquinas geralmente têm um número menor de processadores do que os processos atualmente em execução, o kernel usa um agendador para alternar entre os processos, cada um obtendo seu próprio tempo finito para usar o processador. Quando esse tempo expirar, ele será movido para o final de uma lista de processos ativos ou para uma lista de processos inativos - se o processo estiver aguardando dados de algum dispositivo. Dessa forma, todos os processos parecem estar sendo executados simultaneamente, embora apenas um processo, ou o kernel consiga usar um processador em um dado momento. Este conceito é chamado de pseudo-paralelismo.

Em relação à sua última pergunta sobre drivers no terreno do usuário: isso é possível, ainda assim, o kernel mantém controle total sobre a comunicação com o dispositivo. Por exemplo, o Kernel pode mapear uma região da memória do kernel para a região de memória do driver de espaço do usuário, fornecendo acesso à memória do dispositivo. Kernel ainda tem o poder de encaminhar as alterações para o dispositivo ou não. Este driver de usuário do usuário fornecerá uma interface agradável para controlar o dispositivo para outros aplicativos do usuário, e se de alguma forma o driver travar, ainda haverá boas chances de ser recarregado sem precisar reinicializar a máquina. Se o driver estava no espaço do kernel, digamos um módulo, se o módulo ficou preso e não pode ser descarregado, então ele não pode ser recarregado porque os símbolos já estão lá, então a única chance é redefinir o driver. máquina.

Para concluir, aplicativos como o top cat ou o "hello world" são executados apenas no espaço do usuário, tendo acesso aos recursos do sistema SOMENTE através da API do Kernel, que é um conjunto de funções chamadas de sistema. Assim, quando um aplicativo emite uma chamada de sistema read () para ler de um arquivo, o kernel assume o controle do processador, lê os dados usando o driver apropriado (como o driver HDD) e copia esses dados de volta para o endereço fornecido pelo o ponteiro passou para a chamada do sistema read (), permitindo que o aplicativo continue sendo executado assim que esses dados estiverem disponíveis.

    

Answer 5

Nos sistemas operacionais Unix / Linux, diferimos entre espaço do usuário e espaço do kernel . Isso são apenas sinônimos para userland e onde o kernel pertence.

Você pode entender isso da seguinte maneira. Você pode interagir com tudo o que acontece no espaço do usuário. Qual não é o caso no espaço do kernel. Daemons, bibliotecas e aplicativos pertencem ao espaço do usuário. Todo o código que é executado fora do kernel do sistema operacional pertence ao espaço do usuário (userland).

O espaço do kernel é onde o próprio kernel é executado. É uma área restrita onde nem o root tem acesso. Mas o usuário root pode manipular alguns parâmetros do kernel por uma interface, fornecida pelo kernel (procfs, sysfs).

A memória do sistema é um bom exemplo para explicar a diferença entre o kernel e o espaço do usuário. Um daemon (que é executado no espaço do usuário) precisa de alguma memória para ser executado. O kernel gerencia toda a memória que está disponível. O daemon obtém alguma "memória virtual" do kernel, onde o daemon não está ciente se é memória física ou espaço de troca ou o que quer que seja. O kernel é aquele que determina qual tipo de memória o processo recebe. Porque o gerenciamento de memória acontece no espaço do kernel. Outras coisas que acontecem no espaço do kernel são agendamento de processos, comunicação entre processos, proteção e gerenciamento de memória, chamadas de sistema ...

What exactly is userland?

Portanto, userland é o que o daemon faz (ou pode fazer) ao interagir com os recursos do sistema operacional (E / S, rede, memória, tempo de CPU). Esses recursos são escondidos do processo no espaço do kernel.

A resposta curta:

É o que o cockpit de um avião para o piloto é.

    

Answer 6

Você já recebeu várias boas respostas, mas acho que também há valor em uma resposta curta e concisa:

CPUs modernas permitem restringir o código específico permitido. "Modo kernel" refere-se a código irrestrito com acesso total ao hardware. "Userland" é um código com permissões restritas. Se o código do usuário quiser acessar qualquer coisa que não seja sua própria memória, ele deve chamar o kernel, que então verifica as permissões antes de executar a ação solicitada.

    

Answer 7

Várias camadas no Linux, mostrando também a separação entre o espaço de usuário e o espaço do kernel

para imagem completa - Origem

    

Answer 8

No começo, vou concordar que existem muitas respostas excelentes.
 Minha contribuição será a definição mais curta que encontrei anos atrás sobre o kernel em um livro de administração de sistemas Linux: "kernel: a parte residente na memória do sistema operacional".