No x86, não há necessidade real de outra maneira de descobrir em qual anel um processo está sendo executado, porque o registrador do CS determina completamente o anel ativo. Como você está executando VMs, dependendo do hipervisor que você tem, pode ser possível usar recursos de depuração para ver o valor atual do CS virtual dentro de uma VM, de fora.
O grande problema com a recuperação do valor de CS dentro de um sistema em execução é que o valor de CS será inteiramente determinado pela natureza do probe usado para recuperar o valor. Se você usar um probe de espaço do usuário, sempre verá um valor correspondente ao espaço do usuário. Se você usar um probe no nível do kernel ( kprobe ou ftrace ), sempre verá um valor correspondente ao espaço do kernel.
Em qualquer caso, no Linux no bare metal, a situação é bastante direta: o código do usuário é executado no anel 3, o kernel é executado no anel 0 e é isso. Isso não tem nada a ver com os privilégios no nível do usuário: os processos em execução como root ainda são na maioria códigos de nível de usuário, portanto, eles serão executados no anel 3 na maioria das vezes. A única vez que um processo do usuário é executado no anel 0 é quando ele chama uma chamada de sistema e você não pode interromper isso usando gdb
para ver o toque ativo como o toque 0.
No Xen com VMs para-virtualizadas, a situação é ligeiramente diferente; o hypervisor é executado no anel 0, o espaço do usuário é executado no anel 3 e o kernel é executado no anel 1 (em x86 de 32 bits) ou no anel 3 (em x86 de 64 bits).