分类目录归档:硬件

关于处理器漏洞Meltdown(熔断)和Spectre(幽灵)

关于该重大漏洞的发现,源于Google公司的Project Zero安全团队的论文https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

漏洞是由于Intel 处理器设计的一个BUG,利用漏洞能够允许具有用户态权限的进程执行未经过授权的CPU缓存数据读取,这有可能导致攻击者获取到用户设备上的一些敏感数据,例如密码、登录密钥、用户的私人照片、邮件、即时通讯信息甚至是商业秘密文件等。

针对英特尔处理器涉及到两种攻击方法,分别为Meltdown和Spectre,Meltdown涉及CVE编号CVE-2017-5753和CVE-2017-5715,而Spectre涉及CVE编号CVE-2017-5754。

Meltdown破坏了位于用户和操作系统之间的基本隔离,此攻击允许程序访问内存,因此其他程序以及操作系统的敏感信息会被窃取。这个漏洞“熔化”了由硬件来实现的安全边界。允许低权限用户级别的应用程序“越界”访问系统级的内存,从而造成数据泄露。

Spectre则是破坏了不同应用程序之间的隔离。问题的根源在于推测执行(speculative execution),这是一种优化技术,处理器会推测在未来有用的数据并执行计算。这种技术的目的在于提前准备好计算结果,当这些数据被需要时可立即使用。在此过程中,英特尔没有很好地将低权限的应用程序与访问内核内存分开,这意味着攻击者可以使用恶意应用程序来获取应该被隔离的私有数据。

继续阅读

如何判断 Linux 是否运行在虚拟机上/zz/

 

在 WebHostingTalk 论坛上有些国外奸商会把虚拟机当作独立服务器卖,去年7月份的时候就有一位中国同胞上当受骗, 并在 WHT 上发帖声讨,证据确凿,甚至连服务商自己也承认,回帖达355篇。这家独立服务器/VPS 提供商 HostATree.com 居然大胆的把 OpenVZ VPS 这种一看就知道是虚拟机的虚拟机当作独立服务器卖,晕,至少也要弄个 VMWare/KVM/Xen HVM 吧(更难发现是虚拟机),用 OpenVZ 这种容器也太欺负人了:)昨天恰好收到网友一封邮件问到了如何判断自己买的是独立服务器还是虚拟机的问题。这里 VPSee 简单介绍一下市面上常用虚拟技术(包括容器技术)的判别小技巧。

继续阅读

Linux内核报错日志与硬盘I/O故障对应关系/zz/

 

 

日志信息 故障现象描述 与硬盘关系
scsi1: ERROR on channel 0, id 7, lun 0, CDB: Read (10) 00 73 fc 62 bf 00 00 80 00

Info fld=0x73fc6326, Current sdi: sense key Medium Error

Additional sense: Unrecovered read error

SMART规范定义“Medium Error”错误是一种不可恢复的错误,可能由于介质的缺陷或记录的数据错误。该错误有别于“Hardware Error”。

出现Medium Error的主要原因是硬盘坏,或者硬盘的数据无法读写。

  1. 硬盘扇区坏
  2. 硬盘与磁盘控制器连接信号质量不稳定,导致数据出现异常
mptbase: ioc1: IOCStatus=804b LogInfo=31080000

Originator={PL}, Code={SATA NCQ Fail All Commands After Error}, SubCode(0×0000)

原生指令排序(Native Command Queuing,简称NCQ),原先是改善服务器硬盘存取控制技术,应用在SCSI和SATA 1.0/2.0/3.0接口硬盘读写的加速技术,其接口开启磁盘阵列RAID亦有所提升。透过硬盘固件、硬盘控制器以及操作系统三者的互相配合,改善硬盘内部磁区的读取顺序,可以提高硬盘效能约30%,亦能够轻微减轻硬盘损耗的速率。NCQ对用于服务器上的硬盘的效率提升尤为明显。

PL:Protocol Layer,指磁盘控制器中的协议层

该信息与硬盘是否故障无直接联系
end_request: I/O error, dev sdi, sector 1945920256

EXT2-fs error (device sdi1): read_inode_bitmap: Cannot read inode bitmap – block_group = 222, inode_bitmap = 14547217

EXT2-fs error (device sdi1): ext2_get_inode: unable to read inode block – inode=951895, block=15202501

内核不能从硬盘上的文件系统读取数据。
  1. 硬盘扇区坏。
  2. 硬盘与磁盘控制器连接信号质量不稳定,导致数据出现异常。
mptbase: ioc1: IOCStatus=8000 LogInfo=31110d00

Originator={PL}, Code={Reset}, SubCode(0x0d00)

mptbase: ioc1: IOCStatus=804b LogInfo=31110d00

Originator={PL}, Code={Reset}, SubCode(0x0d00)

驱动准备让磁盘控制器IOC单元复位,出现该操作原因为驱动发现多次读写硬盘数据失败。

IOCStatus=0×8000

磁盘控制器配置页面处于共享的递归方式。

IOCStatus=0×8048

尝试读取不存在的超级配置数据。

IOCStatus=0x804b

超级数据序列号由0xffffffff变为0

该信息不能作为硬盘故障的依据。打印该信息的原因,与硬盘/磁盘控制器IOC单元/硬盘与控制器之间的链路有关。IOC错误码含义见前面。
mptscsih: ioc1: attempting task abort! (sc=000001007b4cf340)

scsi1 : destination target 8, lun 0

command = Read (10) 00 5f 2a 4d 3f 00 10 00 00

磁盘控制器驱动尝试取消读写任务。本示例代码中,表明取消在target 8,lun 0的读数据任务。 该信息与硬盘是否故障无直接联系
mptbase: ioc1: IOCStatus=8048 LogInfo=31130000

Originator={PL}, Code={IO Not Yet Executed}, SubCode(0×0000)

磁盘控制器驱动报告报告当前IOC(I/O Controller)单元状态码 该信息与硬盘是否故障无直接联系
mptscsih: ioc1: task abort: SUCCESS (sc=000001007b4cf340) 磁盘控制器驱动报告读写任务取消成功 该信息与硬盘是否故障无直接联系
mptscsih: ioc1: attempting target reset!

mptscsih: ioc1: attempting bus reset! (sc=000001007b4cf340)

mptscsih: ioc1: Attempting host reset! (sc=000001007b4cf340)

mptbase: Initiating ioc1 recovery

磁盘控制器驱动尝试复位target/bus/host,并重新恢复IOC(I/O Controller)单元 该信息不能作为硬盘故障的依据。打印该信息的原因,与硬盘/磁盘控制器IOC单元/硬盘与控制器之间的链路有关。
scsi: Device offlined – not ready after error recovery: host 1 channel 0 id 8 lun 0 硬盘offline,硬盘的位置为host 1 channel 0 id 8 lun 0 硬盘处于故障状态或丢失
SCSI error : <1 0 8 0> return code = 0×10000

end_request: I/O error, dev sdj, sector 1596607807

scsi1 (8:0): rejecting I/O to offline device

SCSI层报告在host 1 channel 0 id 8 lun 0设备上读写错误,返回码为0×10000,表明设备已不在位。 硬盘处于故障状态或丢失
mptsas: ioc1: attaching sata device, channel 0, id 11, lun 0, phy 0 系统新加入新的硬盘,硬盘所在位置为phy 0,即第一个物理槽位。 插入新的硬盘
mptsas: ioc0: removing sata device, channel 0, id 21, phy 2 从系统中拔掉一块硬盘,硬盘对应的物理位置为phy 2,即第3个物理槽位。 拔除一块硬盘
Remounting filesystem read-only 文件系统变为只读,原因为文件系统遭到破坏 与硬盘是否故障无直接关系