How can I trigger a general protection fault in X86 Linux?

[wangt13]

I am triaging a bug in Unix-like OS, and i hit GP fault in that kernel, and system reset.
I don't know what should Linux do in this case, I want to have a try.

So, in X86 Linux, how can I trigger a GP fault?

Many thanks,
-Tao

[egranata]

This should be sufficient

Code: Select all

section .text
global _start
_start: lgdt [0x0]

FWIW, what it does for me when run is

Code: Select all

$ ./file
Segmentation fault (core dumped)

and in the kernel log:

Code: Select all

[10832.987652] traps: file[32233] general protection ip:8048060 sp:ffdcd2a0 error:0 in file[8048000+1000]

Basically, a "standard" UNIX-like OS should probably catch the GPF interrupt, decide that it happened because a userspace program is being naughty and not due to a kernel bug, and kill the offending process with as much/little logging as needed

[wangt13]

By reading the Wiki for general protection, i can trigger the GP fault in Linux by setting a reserved bit in CR4.
The kernel will panic, then reboot.

Thanks,
-Tao

[lkurusa]

Are you setting that bit in a kernel module or are you doing that in userspace? If the latter, that's a serious security issue.

[Schol-R-LEA]

I am triaging a bug in Unix-like OS, and i hit GP fault in that kernel, and system reset.
I don't know what should Linux do in this case, I want to have a try.

Could you please give us more information about the cause of the problem? Under what circumstances does it happen, and what are trying to do to triage it (by which I assume you mean track it down so you can fix it, rather than trying to decide the priority with which it should be treated )?

Also, why are you then trying to create an analogous situation in Linux? Are you certain that the specific cause of the fault can occur in Linux at all? Are you trying to find out how Linux handles it, so you can apply the same approach (which may or may not be a good idea, depending on the details of your own OS and how it differs from Linux)?

I have a sense that there might be an XY Problem in this post - that what you are asking for isn't necessarily what you need, and that you are presupposing the answer in a way that excludes a better one. If X is 'find and fix the fault in my OS', then asking for Y ('how do I replicate the error in a related but significantly different OS?') is shifting the problem in a way that may not really solve X.