Linux0.00内核为什么要自己设置0x80号陷阱门来调用write_char过程？

    我一开始没注意这个问题，只是通过陷阱门觉得很绕弯子，为何不在3级用户代码里直接调用write_char，今天自己写程序想用call调用代码段，才发现了大问题。我写了类似于write_char的过程，代码如下：

dividing_line:
	push %gs
	pushl %ebx
	pushl %ecx
	
	movl $1,%ecx/*输出1个空格‘  ‘*/
	movl $SCRN_SEL,%ebx
	movw %bx,%gs
1:	movl scr_loc,%ebx
	shl $1,%ebx
	movb $32,%gs:(%ebx)/*‘ ‘空格ASCII码*/
	shr $1,%ebx
	incl %ebx
	cmpl $2000,%ebx
	jb	2f
	movl $0,%ebx
2:	movl %ebx,scr_loc
	loop 1b

	popl %ecx
	popl %ebx
	pop %gs
	ret

    其功能为在屏幕上输出一个空格而已。简直和write_char几乎一样，只不过我指定了要输出的字符，不是通过ax获取罢了。还有一个不同就是我要通过call来调用dividing_line，而不是像write_char一样被陷阱门调用。

    结果程序挂了，没法运行。

    后来分析了下，原因很简单。我在task1里面直接调用write_char也是不行。这两者原因是相同的，那就是这两行代码：

movl $SCRN_SEL,%ebx
movw %bx,%gs

    在源代码中SCRN_SEL= 0x18是GDT中显示数据段的selector，甭管他是什么数据段，反正他是数据段就对了，这个数据段描述符DPL=0，属于高特权级，但是我们现在用特权级3级的代码去调用这个过程，那么这个处理过程此时就算作3级程序的一员，即他的特权级也是3级，CPL=3，尽管SCRN_SEL= 0x18中的RPL=0，但是CPL不够级别，这种加载SCRN_SEL= 0x18的请求必将被处理器驳回。处理器在加载selector进段寄存器时会将当前运作程序的CPL、selector的RPL、被指向描述符的DPL做综合比较，除非CPL和RPL在数值上都小于DPL，也就是特权级较高。否则，这种加载selector的行为都将被处理器拦截并产生保护异常。

    回到我的程序，所以只要这个加载0x18 这个selector的行为存在，这个过程的调用就必然失败，因为0x18 这个selector所指向的数据段描述符DPL超高。于是乎，在3级程序里直接调用write_char也好，dividing_line也好，都会失败，无权访问此数据段，有意图也不行。

    这就是为什么要通过陷阱门去调用write_char，处理器规定通过陷阱门只能向高特权级代码段转移，不得转入低特权级代码段，意思就是我从3级用户代码转入内核0级代码这是天经地义的。但是注意，3级代码的确可以通过陷阱门转入0级代码，但前提是陷阱门的门描述符DPL=3才行。不然用户程序根本没权限去访问陷阱门。好了，我们假设陷阱门描述符DPL=3，陷阱门描述符里面的目标代码selector指向一段内核0级代码。

    这样当3级程序去加载陷阱门描述符，完全可行，因为CPL=3,我们再用RPL=3的selector去访问陷阱门，陷阱门DPL=3，这样完全可以访问陷阱门。然后陷阱门里面的目标selector部分指向0级代码，这没有关系，通过陷阱门我们完全可以转过去，处理器就要我们这样做！这才是应该的过程。低级程序访问低级陷阱门，低级陷阱门里有高特权级的代码段selector，这样可以通过陷阱门转入高特权级的内核代码当中去。这为一些系统调用提供了方便。

    最后有一点，我们把这两行导致问题的代码去掉，能不能正常调用呢？答案是肯定的，既然把这这两行去了，那么这个处理过程的功能就废了，好不如写个简单点的，比如：

example:
	pushl %eax
	movl $0x250,%eax
	pop %eax
	ret

    这个够简单，在3级用户代码里call example就可以调用了，没有输出提示所以我们可以通过bochs调试来确认，结果就是调用成功，执行过程成功进入此example代码。这就是个普通近调用，没啥特殊的。关于陷阱门特权级我们就说到这里。

    说完了。

本文出自 “mirage1993” 博客，请务必保留此出处http://mirage1993.blog.51cto.com/2709744/1576602