关于A20地址线的那些事情

从前在BIOS里面见过关于A20地址线的选项,后来启动FreeDOS什么的时候好像也见过A20的事情,一直不知道是干嘛的……后来某天看BSD loader代码的时候,看见启用A20地址线的事情…… 于是去wiki上查了一下,原来是这么回事……8086那个时候,地址线只有20位,叫做A0~A19,也就是没有A20地址线的。2^20=1M,因此那时能够访问的内存范围是1M。那个时候也分段,地址由段寄存器左移4位,加上基地址,得到物理地址。段寄存器和基地址都是16位的,这样就能够访问20位的空间了。但是有个问题……段寄存器最大FFFF,基地址也是。所以地址最大是FFFF:FFFF,但是FFFF左移四位得到FFFF0,加上FFFF,得到10FFEF,也就是FFFFF+FFF0。但是物理内存只有1M,最大物理地址范围应该是0~FFFFF,因此多了FFF0,超出了物理地址范围。这样,访问到超出范围的时候,8086会自动做一个处理,把高位的1删掉,也就是10xxxx->xxxx,然后返回对应位置。 按理来说,这是个bug,8086应该返回个错误啥的。但是,既然这已经是事实了,有的程序就开始用这一点,来访问0~FFEF的内存范围,差不多是前64K少一些的范围。这就为日后的新CPU出了难题…… 80286,80386等等更NX的处理器出现了,他们支持访问更大的内存范围。自然,10xxxx和xxxx也就指向了不同的地方。但是,跑那些用到从前bug的老程序的时候,就出问题了…… 改了10xxxx的xxxx不变,导致乱七八糟的问题……IBM他们就脑残了一下,说,我们在A20地址线(也就是那个1的位置……)装个开关吧~ 然后又脑残一下,看见键盘控制器正好有一根线空着,就说,我们让键盘控制器来管这个开关吧~于是,著名的Gate A20就这么产生了……打开:输出0xd1到0x64端口,等8042(键盘控制器)空了,再输出0xdf到0x60端口 保护模式的操作系统,自然都需要访问1M以上的内存,而且不希望某一位地址一直是0。所以保护模式的操作系统启动步骤之一,就是打开A20。但是,IBM那些人们没想到,日后有些环境需要频繁切换A20端口,而键盘控制器是如此之慢…… 他们当初认为,这个切换发生频率很低,因此慢一点没关系…… 于是就有了Fast Gate A20的事情。利用0x92端口,读入之后,把第二位改成1,然后写回去,能快一点。但这个引起了新的bug。毕竟只有某些系统支持0x92端口的这个用发,而有些系统…… 改了0x92会导致没有显示之类的,所以有危险……后来么,intel也不爽了,就搞了个0xee端口,读打开A20,写关闭…… 速度比从前更快了…… 于是,这样就有了3中方法,由慢到快。某些程序就一个一个试,试了一个验证一下。但是,缓存又来捣乱。有的系统虽然开了A20,还是会把几个字节缓存起来,10xxxx和xxxx一样…… 总的来说,A20就是个麻烦的事情,当初搞个BIOS调用之类的也就over了么…… 不过现在的新的系统,基本上都没有A20的问题了,虽然打开A20还是系统启动的必要步骤之一……参见A20 – a pain from the past

80×86 保护模式 内存访问 学习总结

话说这个80286搞出来的保护模式,又是分段又是分页,从前没好好研究过,从来就没有搞清楚过……家里翻到一本老教材,《微型计算机技术及应用——从16位到32位》,里面讲80386的章节,终于基本上讲清楚了……假设现在是即分段又分页的情况…… 首先,程序里面引用一个地址,其实指的都是逻辑地址。这样的引用需要两部分数据:段选择子以及段内偏移量。然后么,段选择子基本上就放在老的段寄存器里面,不过现在是起一个索引的作用。段选择子其实分几部分。总共16位,前13位是个索引,接下来1位指定是到LDT还是GDT里面找。最后两位是特权级。LDT和GDT,一个是局部描述符表,一个是全局描述符表,反正是两张表,存了一大堆的段描述符。表的位置放在LDTR和GDTR两个寄存器里面。现在研究内存访问,所以只讨论存储段描述符,每个8个字节,包括了段的开始地址(32位)、界限(20位),还有一堆标志什么的。用前面那个索引,从LDT或GDT里面找到描述符,然后就有了段基地址。之前需要检查偏移量符合界限,以及其他各种权限之类的检查。最后加上偏移量,我们就得到了线性地址~ 分段部分完成~ 然后,线性地址有32位。把它分为3段:10位,10位,12位。系统有一堆控制寄存器,其中,CR3里面,保存着页目录的基地址。页目录也是一个表,每项4个字节,每个里面都有一个页表基地址…… 当然还有一堆别的东西,什么权限、标志之类的……线性地址的第一段,10位,就是这个表的索引。把它乘以4(每项4个字节么……),加上CR3里面的基地址,就有了页表的基地址……页表的结构也差不多,也是4个字节一项。用线性地址第二段,10位,乘以4,加上页表基地址,就有了页基地址……最后,拿第三段,12位,加上业基地址,终于…… 我们得到了物理地址! 接下来么,做一些数学计算。页内偏移量(线性地址第三段)有12位,2^12=4*1k=4k,和一页大小为4k吻合~线性地址前两段,每段10位,对应的表可以有1k项。所以,经过这两级,可以索引1M个页。每个页4k那么大,所以…… 总共4G。其实这个计算很NC对吧…… 总共32位,没有1位浪费,全都用来索引的情况下,当然可以索引2^32=4G……然后,一个页表有多大呢?一项4字节,共1024字节,所以一个页表4k大。总共1k个页表,所以页表总共占4M那么多地方。页目录表么,就4k大啦,比起页表也不算什么……然后,段的界限只有20位,2^20=1M,难道一个段只有1M那么大?其实剩下的标志里面有一个粒度位G,能够指定界限以1字节还是4k为单位。以4k为单位的时候,就能有1M*4k=4G那么大的段,这个就很完美了么~段选择子有16位,因此最多有2^16=65536个段,真多…… 然后,这样n级转换不是很慢么,所以系统里还有转换缓冲区。貌似这个区操作系统还可以控制,让哪些转换结果留在缓冲里面,这样下次碰见一个逻辑地址就不用多级转换了……另外,程序用到段选择子的时候,必然都在6个段寄存器里。所以,每次把东西扔到段寄存器里面去,CPU就把对应的段描述符装到一个隐藏的寄存器里面,这样,大部分时间就不用去查LDT/GDT之类的了……

Blog Moved

新的Blog: MSN Space: 这个Blog就用来发技术性的文章了~ 这个blog没救了,最晚也就2008/12/31,之后就回滚成1991年了…… 走了走了…… Old Blog Link: http://computer.mblogger.cn/henryhu/posts/49530.aspx 评论 # 回复: Moved to MSN 2006-1-3 8:54 Hearson 请教一下,你怎么到未来的? # 回复: Moved to MSN 2006-1-4 12:19 HenryHu 这里的时间可以设置的~用于置顶~

Sogou 的浏览器(2)

刚才又搜了一下,然后搜修改HTTP头的时候,有人提到privoxy。对啊,privoxy不是可以乱改HTTP头的么。所以,这样配置privoxy就可以了:首先,建立user.filter,内容: CLIENT-HEADER-FILTER: change-host-to-intel Change the Host to Intel!s/Host:.*/Host: www\.intel\.com/ 随后,建立sogou.action,内容: {+add-header{X-Sogou-Auth:4D929DA9BB4DF2966799B7761245A98B/55/bad36d282a55d332}}.*{+add-header{X-Sogou-Domain: 24181F5B2C160409035C061D3E}}.*{+add-header{X-Sogou-Timestamp: 494f30c4}}.*{+add-header{X-Sogou-Tag: 5bccdce35ecd20cab326fb0b746cce7b}}.*{+client-header-filter{change-host-to-intel}}.* 最后,在privoxy配置文件里面加上: actionsfile sogou.actionfilterfile user.filterforward / 118.228.148.27:80 之后,把 firefox 的代理设为 privoxy ,over!经验证,这样可以上IBM,Adobe等,应该是没问题了。这样就的确可以在 firefox 里面上了~接下来要考虑修改user-agent了~ PS: 修改user-agent: 在action文件里面加上: +hide-user-agent {Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)} 就可以了……

Sogou 的浏览器

上次说到的 Sogou 浏览器终于公开了,搜狗浏览器 1.0 beta。还是测试版,的确能够在教育网上外国网站。但是这个东西是ie内核的,我这里不能用。所以只好研究一下。先用 tcpdump 看一眼,发现是和118.228.148.27~30的几个服务器的80端口通信,于是怀疑这个东西用了个http代理。然后用 wireshark 抓下来,果然是代理。用nmap知道,那个代理是个linux,跑着squid。找了个包头,然后一行一行删掉,剩下不能删的: GET http://www.intel.com/ HTTP/1.1Host: www.intel.comX-Sogou-Auth: 4D929DA9BB4DF2966799B7761245A98B/55/bad36d282a55d332X-Sogou-Domain: 24181F5B2C160409035C061D3EX-Sogou-ResponseCode: 200X-Sogou-Tag: 5bccdce35ecd20cab326fb0b746cce7bX-Sogou-Timestamp: 494f30c4 把第一行的GET后面的地址替换成随便什么地方,貌似都行~ 也就是说,想去哪里就去哪里。改了 GET 后面的值,然后用 nc,验证通过。sogou 的弱的地方,在于只检查了 Host 后面的域,目前怀疑 X-Sogou-Domain 是 Host 后面的值的某种散列。但是 squid 依靠 GET 后面的地址确定目标地址,而且不要求和Host一致…… 这样 sogou 的检查就等于白干。实际到firefox里面,装个 Live HTTP Headers,然后把除了 GET 之外的东西复制到点Replay…出来的那个框里面,然后点 Replay,并且指定118.228.148.27之类的作为代理,就能够获取网页内容~有了这样的信息,开发一个能够直接利用那个代理的浏览器应该也很容易了,只要在每个请求后面加上那堆东西就可以了……我怀疑一个脚本就能搞定……另外,那个 squid 好像不care cookie一类的东西,本来 intel.com 就是有 cookie 的,删了也没有关系~所以说,sogou 太弱了……还有,那个包是虚拟机里的xp下抓的,所以应该看不出 IP 吧~