首先需要安装guest addtions
主机端：
为客户机配置共享文件夹，略。
客户机：
列出可用的share folders
1 | $ sudo VBoxControl sharedfolder list |
如果设定了自动挂装, virtualbox会自动挂载之，否则可以手动挂载：
1 | $ sudo mount -t vboxsf Downloads /media/host |
访问权限问题，将当前用户加入vboxsf组
1 | $ sudo adduser $USER vboxsf |
然后注销重新登录，或者使用
1 | $ newgrp vboxsf |
没有GUI的debian buster安装virtualbox guest additions
主机端：
启动客户机，点击菜单Devices->Insert Guest Additons Image…
客户机端：
安装内核模块build依赖:
1 | $ apt-get install -y dkms build-essential linux-headers-$(uname -r) |
挂载cdrom，安装客户附加组件
1 | $ sudo mount /dev/cdrom /media/cdrom |
reboot客户机
1 | # reboot |
校验安装:
1 | $ lsmod grep vboxguest |
安装成功
References:
[1]How to install VirtualBox Guest Additions on a GUI-less Ubuntu server host
一台很老旧的服务器terminal不断吐出一些错误提示：
1 | \[ 1250.944486\] mce: \[Hardware Error\]: Machine check events logged |
可以看到是内存出现了错误，不过错误被纠正了，但内存显然是出现故障了。
先看看系统cpu节点信息
1 | $ lscpu |
共有四个socket，四颗cpu，每颗CPU有八个核心，总共是32核心，对于NUMA结构的机器，一般来讲每颗CPU应该至少有一个本地的内存控制器
安装edac-util，查看内存控制器信息
1 | $ sudo apt install edac-utils |
可以看到有四个内存控制器，再查看每个内存控制器可能存在的错误
1 |
|
或者这样查看:
1 | $ grep \[0-9\] /sys/devices/system/edac/mc/mc*/csrow*/*ce_count |
可以看到出现错误的内存位于MC6,csrow2和csrow3，也就是问题出现在第四个(CPU的)内存控制器的0通道DIMM0内存这里。
References:
[1]How to identify defective DIMM from EDAC error on Linux
[2]内存条物理结构分析
以下示例中只有一台客户机，名称为”buster”，术语虚拟机等同于客户机
虚拟机列表
1 | $ VBoxManage list vms |
无头模式启动虚拟机，自动进入后台模式
1 | $ VBoxManage startvm buster --type headless |
无头模式启动虚拟机，前台模式
1 | $ VBoxHeadless -s buster |
正在运行的客户机列表
1 | $ VBoxManage list runningvms |
关闭客户机电源
1 | $ VBoxManage controlvm buster poweroff |
使用VirtualBox图形界面也可以headless模式启动客户机，选择Start->Headless Start即可。
客户端执行ntpdate同步时间时发生错误：
1 | ntpdate\[10877\]: no server suitable for synchronization found |
debug模式运行ntpdate:
1 | # ntpdate -d 192.168.0.3 |
提示错误Server dropped: Leap not in sync
在ntp服务器上与上游强制同步一次时间即可
1 | # service ntp stop |
然后再在客户端上重新进行时间同步
1 | # ntpdate 192.168.0.3 |
服务器上突然出现很多acpi_pad/*进程,*为0,1,2,3,…，每个进程都占用100%CPU，导致系统极度缓慢
解决办法就是移除acpi_pad模块
1 | # rmmod acpi_pad |
并将其加入模块blacklist，/etc/modprobe.d/blacklist.conf文件中添加
1 | blacklist acpi_pad |
或者
在 grub 的 kernel 配置后面，添加 acpi_pad.disable=1 重启机器之后，开机就不会自动加载 acpi_pad 模块
注：早上跑到机房一看，空调自己关闭了，环境温度40几度，服务器、机柜一片报警，赶快打开两个空调降温，acpi_pad的问题是不是与环境温度过高有关呢？
因为存储归档文件的服务器硬件故障宕机，写入不成功导致postgresql无法归档。这时候可以临时修改配置文件
1 | archive_command='' |
然后reload postgresql
1 | $ sudo service postgresql reload |
这时服务器不会发送归档日志文件，但是服务器在继续累积产生的WAL日志文档，直到提供一个合适的归档命令，重新开始归档，这样不会丢失WAL日志文档。
如果提供如下归档命令
1 | archive_command='/bin/true' |
这样归档进程总是认为归档成功，但实际上并没有真正写归档文件，但服务器上的WAL会被删除掉(与参数wal_keep_segments有关)，当硬件恢复或者换用其他硬件时，必须重新制作基础备份，因为WAL归档日志文件已经缺失了。
amd64架构linux kernel使用四级页表映射结构，但是存在两套terminology来描述这个事情
其一：
PML4(Page Map Leve4)(Level 4) -> PDP(Page Directory Pointer) (Level 3) -> PD(Page Directory) (Level 2) -> PTE(Page Table Entry)(Level 1)
另一：
PGD(Page Global Directory)(Level 4) -> PUD(Page Upper Directory)(Level 3) -> PMD(Page Middle Directory)(Level 2) -> PTE(Page Table Entry) (Level 1)
这两套术语其实表达的都是一样的东西,CR3寄存器保存Level 4表的物理地址，Level 4只有一页，4K大小，总共512个表项，每个表项可以寻址512GB内存，总共可以寻址256TB内存。
当前amd64处理器只是用了64位中的48位来寻址，因此使用四级页表时，虚拟地址的低48位为9+9+9+9+12映射结构，每个物理页框(Page Frame)为4K，4K地址对齐。
当使用2M的大页/巨页时，使用三级页表映射，虚拟地址的低48位为9+9+9+21映射结构，每个物理页框为2M,2M地址对齐。
参见下面两图：
4K页面地址转换
2M 页面地址转换
为了支持更大的线性地址空间，以后的CPU会扩展到57位虚拟地址寻址。linux目前已经提供5级页表映射，如果启用5级页表，会在PGD和PUD之间插入新的一级页表，叫做P4D(Page 4 Directory)，这样PGD会成为第五级页表,参见[1]。
References:
[1]Five-level page tables
To make this simpler, let’s first just consider CPL and DPL:
RPL is a privilege level associated with a segment selector. A segment selector is just a 16-bit value that references a segment. Every memory access (implicitly2 or otherwise) uses a segment selector as part of the access.
When accessing a segment, there are actually two checks that must be performed. Access to the segment is only allowed if both of the following are true:
So even if CPL is sufficiently privileged to access a segment, the access will still be denied if the segment selector that references that segment is not sufficiently privileged.
What’s the purpose of this? Well, the reasoning is a bit dated now, but the Intel documentation offers a scenario that goes something like this:
An application would ordinarily not be able to access the memory in segment X (because CPL > DPL). But depending on how the system call was implemented, an application might be able to invoke the system call with a parameter of an address within segment X. Then, because the system call is privileged, it would be able to write to segment X on behalf of the application. This could introduce a privilege escalation vulnerability into the operating system.
To mitigate this, the official recommendation is that when a privileged routine accepts a segment selector provided by unprivileged code, it should first set the RPL of the segment selector to match that of the unprivileged code3. This way, the operating system would not be able to make any accesses to that segment that the unprivileged caller would not already be able to make. This helps enforce the boundary between the operating system and applications.
Segment protection was introduced with the 286, before paging existed in the x86 family of processors. Back then, segmentation was the only way to restrict access to kernel memory from a user-mode context. RPL provided a convenient way to enforce this restriction when passing pointers across different privilege levels.
Modern operating systems use paging to restrict access to memory, which removes the need for segmentation. Since we don’t need segmentation, we can use a flat memory model, which means segment registers CS, DS, SS, and ES all have a base of zero and extend through the entire address space. In fact, in 64-bit “long mode”, a flat memory model is enforced, regardless of the contents of those four segment registers. Segments are still used sometimes (for example, Windows uses FS and GS to point to the Thread Information Block and 0x23 and 0x33 to switch between 32- and 64-bit code, and Linux is similar), but you just don’t go passing segments around anymore. So RPL is mostly an unused leftover from older times.
You asked why it was a necessity to have both DPL and RPL. Even in the context of the 286, it wasn’t actually a necessity to have RPL. Considering the above scenario, a privileged procedure could always just retrieve the DPL of the provided segment via the LAR instruction, compare this to the privilege of the caller, and preemptively bail out if the caller’s privilege is insufficient to access the segment. However, setting the RPL, in my opinion, is a more elegant and simpler way of managing segment accesses across different privilege levels.
To learn more about privilege levels, check out Volume 3 of Intel’s software developer manuals, particularly the sections titled “Privilege Levels” and “Checking Caller Access Privileges”.
1 Technically, the DPL can have different meanings depending on what type of segment or gate is being accessed. For the sake of simplicity, everything I describe applies to data segments specifically. Check the Intel docs for more information
2 For example, the instruction pointer implicitly uses the segment selector stored in CS when fetching instructions; most types of data accesses implicitly use the segment selector stored in DS, etc.
3 See the ARPL instruction (16-bit/32-bit protected mode only)