Genode (x86_64) reboots on Thinkpad T420

[Valery V. Sedletski]

Alexander Boettcher wrote:
> On 08.03.19 12:29, Valery V. Sedletski wrote:
>> On Fri Mar   8 15:57:20 2019 Alexander Boettcher <alexander.boettcher at genode-labs.com> wrote:
>>> On 08.03.19 11:25, Valery V. Sedletski via users wrote:
>>>> On 07.03.19 23:10, Valery V. Sedletski via users wrote:
>>>>> Alexander Boettcher wrote:
>>>> P.S.: I wondered why 32-bit works fine, but cnuke on the irc channel
>>>> supposed that it could be because of NX bit, which is enabled on 32-bit
>>>> normally only if PAE is enabled.
>>> Some kernels don't use PAE in 32bit, or in the kernel configuration it
>>> is not enabled. That means the kernels in 32bit just don't use it and
>>> therefore they booted up.
>>>
>>> In 64bit mode the NX-bit is supposed to be supported by all CPUs, never
>>> have seen (until today) that you can disable such a security feature. It
>>> makes no sense for modern OSes at all.
>>>
>> IIRC, the bit prevents execution of code in DATA segments (?), It's supposed as a measure against viruses. Usually, such measures break some programs, which aren't viruses. So, I suspected that enabling the NX bit could break something, not vice versa, but it appears, I'm not right. I am still wondering why disabling it can cause traps or reboots. Do the kernels functionality depend on the NX bit somehow?
> The kernel could/should check whether the NX feature is available by
> hardware, and solely if, then should actually use it. The kernels
> obviously don't do that.
>
> When you look on how the NX bit is actually implemented, you will see
> that the 63bit in the page table entry is used. With NX enabled, the 63.
> bit decides whether code is executable (0) or not (1). If NX is
> disabled, the 63 bit is part of your normal address lookup procedure.
>
> If the kernel now set the 63. bit, but actually it is part of the normal
> address page table walk (NX not supported), you will end up in wrong
> addresses. Additionally, you also get non-canonical addresses, which is
> not permitted and leads to hardware exceptions raised (see CPU
> documentation of Intel/AMD).
Thanks for the explanation. So, probably, this bit was included into the 
page address, which is invalid, and there was a trap because of an 
incorrect address.

WBR,
valery
>
> Cheers,
>