pte

Windows内核分析索引目录 ：https://www.cnblogs.com/onetrainee/p/11675224.html 10-10-12 分页机制 1. CPU是如何通过线性地址查找物理地址的？ 2. MMU是什么？ 3.CPU内存管理内部大体结构框架？ 4.会写、直接、不缓存什么概念？ 5.CR3、PDE、PTE之间的关系？ 6.用一进程的内存结构分析 7.操作系统与CPU的页密度 8.使用!vtop指令解析物理地址 9.通过挂物理页来实现0地址读写 10.修改PDE与PTE属性来实现对只读内存(字符串)的操作 11.页属性的A位、D位(Dirty脏位)与G位的说明 12.PDE的PS位(大页) 1. CPU是如何通过线性地址查找物理地址的？ 　　通过一块MMU内存控制单元 2. MMU是什么？ 　　内存管理单元，是一个模块（我们也可以看成一个函数）。 　　物理地址 func(CR3，线性地址); 　　其就是将线性地址按我们的步骤拆分成物理地址(10-10-12)。 3.CPU内存管理内部大体结构框架？ 　　 4.回写、直接、不缓存什么概念？ 　　三者都是针对缓存来讲的。 　　1)回写：先写到缓存，等一会数据量够了再写到内存中。 　　2)直写：写到缓存的同时直接写到内存中。 　　3)不缓存：不经过缓存，直接写到内存中。 5.CR3、PDE、PTE之间的关系？ 6

ucore lab2 练习2&3 回忆一下之前的练习1，我们填写了default_pmm.c中的一些函数，也实现了内存分配的first fit算法。但是，其实我们并不是很清楚，default_pmm.c这个文件在整个lab2中的位置，也就是说，这个文件中的函数，到底在哪些地方被调用了呢？想要解决这个问题，首先要搞清楚物理内存管理器pmm_manager。 1 物理内存管理器pmm_manager pmm_manager在pmm.h中被声明： struct pmm_manager { const char * name ; void ( * init ) ( void ) ; void ( * init_memmap ) ( struct Page * base , size_t n ) ; struct Page * ( * alloc_pages ) ( size_t n ) ; void ( * free_pages ) ( struct Page * base , size_t n ) ; size_t ( * nr_free_pages ) ( void ) ; void ( * check ) ( void ) ; } ; 这里出现了函数指针，这是以前我们比较少接触的，它是实现面向对象编程的一种很重要的手段，因为它给提供了接口，而在实现这些接口的时候

目录 实验总结 0. 实验准备 1. vmprint 2. 实现 lazy sbrk 3 & 4. 冒烟 & 修复 实验总结 本次实验用时约八个小时。 收获是对线性地址的理解更深入了。 遇到的困难包括： 懒。 xv6-riscv 默认开了 kpti（内核和用户态页表分离） ，故需要在各种系统调用头部手动模拟 traverse 页表的过程，以及模拟处理缺页异常。（我现在觉得这不是一个很好的设计） 测试结果： $ make grade running lazytests: (3.7s) lazy: pte printout: OK lazy: map: OK lazy: unmap: OK usertests: (95.8s) usertests: pgbug: OK usertests: sbrkbugs: OK usertests: argptest: OK usertests: sbrkmuch: OK usertests: sbrkfail: OK usertests: sbrkarg: OK usertests: stacktest: OK usertests: all tests: OK Score: 100/100 0. 实验准备 实验指导链接 上来直接： $ cd xv6-riscv-fall19 $ git checkout lazy 实验分为四个子任务（实际更多个）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我们前面说过几种隐藏进程的方法： 遍历进程活动链表（ActiveProcessLinks） 遍历PspCidTable表检测隐藏进程 但还是不能防止别人通过各种方法来隐藏进程，所以下面来介绍一种通过暴力搜索内存枚举进程的方法。 一个进程要运行，必然会加载到内存中。基于这个事实，隐藏进程要在目标机运行，在内存中一定会存在对应的EPROCESS结构体。基于系统内存搜索的进程监测技术利用EPROCESS结构体特征找到EPROCESS地址指针进而输出进程信息，可以有效地对进程进行全面的监测。 那我们应该搜索进程的什么结构？进程的PEB（PEB(Process Environment Block)——进程环境块）。主要原因是PEB地址的高4位是相同的。 image 可以看到除了system，其他进程的PEB都是0x7ffdxxxx.为什么？ 找到wrk源码，MiCreatePebOrTeb这个函数负责分配peb和teb的地址。 贴出关键代码： //判断是不是分配PEB地址，通过与PEB的大小比较 if (Size == sizeof(PEB) #if defined(_WIN64) || (Size == sizeof(PEB32)) #endif ) { PVOID HighestVadAddress; LARGE

## OS课程 ucore_lab3实验报告 练习零：填写已有实验   本实验依赖实验1/2。请把你做的实验1/2的代码填入本实验中代码中有“LAB1”,“LAB2”的注释相应部分。 下面三个, 复制过去就ok pmm.c default_pmm.c trap.c 练习1：给未被映射的地址映射上物理页（需要编程）   完成do_pgfault（mm/vmm.c）函数，给未被映射的地址映射上物理页。设置访问权限 的时候需要参考页面所在 VMA 的权限，同时需要注意映射物理页时需要操作内存控制 结构所指定的页表，而不是内核的页表。注意：在LAB2 EXERCISE 1处填写代码。执行 make qemu 后，如果通过check_pgfault函数的测试后，会有“check_pgfault() succeeded!”的输出，表示练习1基本正确。 do_pgfault(){ ptep = get_pte(mm->pgdir, addr, 1); // 根据引发缺页异常的地址 去找到 地址所对应的 PTE 如果找不到 则创建一页表 if (*ptep == 0) { // PTE 所指向的 物理页表地址 若不存在 则分配一物理页并将逻辑地址和物理地址作映射 (就是让 PTE 指向 物理页帧) if (pgdir_alloc_page(mm->pgdir, addr, perm) ==

实验目的： 掌握内存分页机制 对应章节： 3.3 实验内容： 1.认真阅读章节资料，掌握什么是分页机制 2. 调试代码，掌握分页机制基本方法与思路 – 代码3.22中，212行---237行，设置断点调试这几个循环，分析究竟在这里做了什么？ 3. 掌握PDE，PTE的计算方法 – 动手画一画这个映射图 4. 熟悉如何获取当前系统内存布局的方法 5. 掌握内存地址映射关系的切换 – 画出流程图 6. 基础题：依据实验的代码， – 自定义一个函数，给定一个虚拟地址，能够返回该地址从虚拟地址到物理地址的计算 过程，如果该地址不存在，则返回一个错误提示。 – 完善分页管理功能，补充alloc_pages, free_pages两个函数功能 7. 进阶题（选做） – 设计一个内存管理器，选择其一实现：首次适应算法、最佳适应算法、伙伴算法，要 求实现内存的分配与回收。（提示，均按照页为最小单位进行分配、对于空闲空间管 理可采用位图法或者双向链表法管理） 完成本次实验要思考的问题： 1. 分页和分段有何区别？在本次实验中，段页机制是怎么搭配工作 的？ 2. PDE、PTE，是什么？例程中如何进行初始化？CPU是怎样访问 到 PDE、PTE，从而计算出物理地址的？ 3. 为什么PageTblBase初始值为2M+4K？ 4. 怎么读取本机的实际物理内存信息？ 5. 如何进行地址映射与切换？ 6.

练习零：填写已有实验    本实验依赖实验1。请把你做的实验1的代码填入本实验中代码中有“LAB1”的注释相应部分。提示：可采用diff和patch工具进行半自动的合并（merge），也可用一些图形化的比较/merge工具来手动合并，比如meld，eclipse中的diff/merge工具，understand中的diff/merge工具等。 其实 lab1 中只有 kern/debug/kdebug.c kern/init/init.c kern/trap/trap.c 被改过了 所以只用把这三个文件复制到lab2中就可以了。 练习一：实现 first-fit 连续物理内存分配算法（需要编程）    在实现first fit 内存分配算法的回收函数时，要考虑地址连续的空闲块之间的合并操作。提示:在建立空闲页块链表时，需要按照空闲页块起始地址来排序，形成一个有序的链表。可能会修改default_pmm.c中的default_init，default_init_memmap，default_alloc_pages， default_free_pages等相关函数。请仔细查看和理解default_pmm.c中的注释。   查看注释后，发现代码已经写了，于是 make qemu 了一发，发现错了，断言失败。仔细看了后，代码是不完整的。   断言失败之前的检查都是针对页分配成功、失败的测试

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: I'm trying to write some simple test code as a demonstration of hooking the system call table. "sys_call_table" is no longer exported in 2.6, so I'm just grabbing the address from the System.map file, and I can see it is correct (Looking through the memory at the address I found, I can see the pointers to the system calls). However, when I try to modify this table, the kernel gives an "Oops" with "unable to handle kernel paging request at virtual address c061e4f4" and the machine reboots. This is CentOS 5.4 running 2.6.18-164.10.1.el5. Is

ucore Lab2 lab 2 直接执行 make qemu-nox 会显示 assert 失败: kernel panic at kern/mm/default_pmm.c:277: assertion failed: (p0 = alloc_page()) == p2 - 1 对物理内存的管理,为了节省空间,也是为了配合接下来的虚拟内存管理,通常以某个比 byte 大一些的单位进行管理,我们称这一单位内存为一" ҳ(page) ",通常是 4KB.待 pages 初始化完毕后,物理内存示意图如下: 其中绿色代表可以分配的内存,红色代表不可被分配的内存.注意, ucore 规定物理内存可用范围最大不超过 KERNSIZE .函数 page_init 的主要作用就是初始化 pages 也就是所有 page 的所有信息. 注意, pages 以全局指针的形式存在,因为最开始无法知道 page 的数量,所以无法写成数量确定的数组.此数量必须尽快确认,否则后期无法管理. 如何确定 page 的数量 npage 呢? npages 可由最大物理内存边界/PGSIZE 得出. 而最大物理内存边界可以借助 BIOS 可以探测并计算出来,参考 探测系统物理内存布局 和 实现物理内存探测 .可以获取到最大可用物理内存边界 maxpa , 但 maxpa 最终必须<= KMEMSIZE .

Lab 5: File system, Spawn and Shell tags: mit-6.828 os 本lab将实现JOS的文件系统，只要包括如下四部分： 引入一个 文件系统进程（FS进程） 的特殊进程，该进程提供文件操作的接口。 建立RPC机制 ，客户端进程向FS进程发送请求，FS进程真正执行文件操作，并将数组返回给客户端进程。 更高级的抽象，引入 文件描述符 。通过文件描述符这一层抽象就可以将 控制台，pipe，普通文件 ，统统按照文件来对待。（文件描述符和pipe实现原理） 支持从磁盘 加载程序 并运行。 File system preliminaries 我们将要实现的文件系统会比真正的文件系统要简单，但是能满足基本的创建，读，写，删除文件的功能。但是不支持链接，符号链接，时间戳等特性。 On-Disk File System Structure JOS的文件系统不使用inodes，所有文件的元数据都被存储在directory entry中。 文件和目录逻辑上都是由一系列数据blocks组成，这些blocks分散在磁盘中，文件系统屏蔽blocks分布的细节，提供一个可以顺序读写文件的接口。JOS文件系统允许用户读目录元数据，这就意味着用户可以扫描目录来像实现ls这种程序，UNIX没有采用这种方式的原因是，这种方式使得应用程序过度依赖目录元数据格式。 Sectors