Bug 6949

Summary:	Linux does not differentiate between memory faults and privileged instruction faults
Product:	Platform Specific/Hardware	Reporter:	Evan Teran (eteran)
Component:	i386	Assignee:	other_other
Status:	REJECTED INVALID
Severity:	normal	CC:	akpm, mingo, protasnb, tglx
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.17	Subsystem:
Regression:	---	Bisected commit-id:

Description Evan Teran 2006-08-02 12:44:32 UTC

Intel(R) Pentium(R) M processor 2.00GHz

Linux does not differentiate between memory faults and privileged instruction
faults. I am not sure if this is truly a bug, as it is more a matter of taste. 

However, I am currently developing a debugger with Linux as my primary platform,
and i noticed that when a faulty program attempts to execute an instruction
which is not allowed in ring3 (HLT for example), a SIGSEGV signal is produced. I
found this to be unintuitive at best.

My initial feeling would be that it would be more closely matched to the SIGILL
(illegal instruction signal), even though that is for op-codes which are not
legal in any context, it is a bit of a closer match to what is really happening.

Obviously, in a perfect world, there would be a separate signal for this sort of
situation, but I can see that being an issue with regard to backwards
compatibility if any programs count on this behaviour.

Like I said, it's arguable whether it's a bug at all, but I thought I'd at least
mention it.

Comment 1 Natalie Protasevich 2008-03-26 23:09:02 UTC

Evan, is the signal disposition still same?
Maybe you can raise this question on the LKML, since it requires discussion.
Thanks.

Comment 2 Ingo Molnar 2008-03-27 01:26:15 UTC

we always raised SIGSEGV on instructions that are "legal" but where 
sufficient permission is not present to execute them in the current 
context. SIGILL is for "invalid opcode" exception where the CPU says 
that it does not know the opcode at all.

so this is not a bug nor an inconsistency in my opinion.

	Ingo

Comment 3 Thomas Gleixner 2008-03-27 01:52:32 UTC

Memory fault and privileged instruction in user space are raising the same exception vector on x86 (idt 13 general protection fault), which makes sense as it protects against using privileged instructions from the wrong context.

The general protection fault can have several dozen root causes (See Intel Software Deveopler manual Volume 3A, Chapter 5.15) and decoding it in the trap handler would be a horrible spaghetti code with no obvious benefit.

Thanks,
       tglx

Comment 4 Natalie Protasevich 2008-03-27 09:46:55 UTC

Thanks you. Closing the bug.