【问题标题】:Can RAM modification damage hardware? [closed]RAM修改会损坏硬件吗? [关闭]
【发布时间】:2016-01-31 11:18:25
【问题描述】:

可以写入任意内存区域的实模式程序会损坏硬件吗?这种情况下不包括中断调用或其他可以在实模式下完成的事情——只是纯粹的写入内存。

This page 显示了 x86 系统的内存映射,我看到了 BIOS 数据区之类的东西;所以我担心写入这个区域可能会对 BIOS 进行持续更改,或者至少将 BIOS 设置更改为意外值。可能更多的东西可以被摧毁。

我经常读到实模式下的硬件访问会破坏硬件;但他们没有解释必须做出的情况。

由于我只询问写访问而不调用中断,我的主要问题是,如果对内存的更改可以进行持久更改;如果是,是哪个,为什么?

【问题讨论】:

  • 我认为您尝试写入 ROM 是安全的。 (看看它代表什么。)
  • 我知道 ROM 是什么意思。但是你可以刷一个ROM。您可以更改可能不一致的 BIOS 设置,从而在下次启动时崩溃。可能还有更多可能出错的地方
  • 如果“ROM区”实际上是由ROM芯片构成的,则无法更改。你不能刷 ROM 芯片。
  • ...无论谁投了我的票,都应该向我展示我所做的研究不足。例如stackoverflow.com/questions/6813636/…,一个 6 次赞成的问题提出了相同的问题,而关于实模式的答案是“任何访问都可能损坏任何东西”。这对我来说还不够! :-( 我想了解哪个内存区域的什么变化会造成什么损坏,以及为什么。
  • 我不知道 Bios 数据区或扩展 BDA 中的任何内存位置如果写入会导致 PC 物理损坏。但是,如果您写入这些区域,您的 PC 可能无法按预期运行,可能需要重新启动才能解决。如果您使用 IO 端口直接与硬件交互,那么您可能会做一些令人讨厌的事情,这些事情可能会使您的 PC 在某些较旧/有缺陷的 BIOS 上无法工作。许多 BIOS 可以用新代码重新刷新,如果该代码是错误的,那么您的 PC 将来可能无法启动。许多系统现在都带有工作 BIOS 的备份副本以防万一。

标签: assembly x86 hardware bios hardware-programming


【解决方案1】:

假设现代 80x86 硬件;不会导致持续变化和/或损坏的事情包括:

  • 在计算机重置时更改任何重置的内容;包括 RAM、缓存、CPU 的微代码等所有内容。

  • 写入将旧版 ROM 复制到 RAM 的区域(从 0x000C0000 到 0x000FFFFF 的区域)。 请注意,这实际上是 RAM,但在 POST 之后在内存控制器中设置为“忽略写入”。

  • 写入实际包含固件的区域(以 0xFFFFFFFF 结尾的“n MiB”区域)。

会导致“暂时性持续变化”(可以修复)的因素包括:

  • 将垃圾写入 CMOS 寄存器;这并不比在旧系统上使用扁平的 CMOS 电池更糟糕,并且可能会在您下次启动时导致“CMOS 设置无效”错误(由于校验和不匹配);并且可以通过修复。启动时固件的配置实用程序。

  • 在存储设备(硬盘、USB 闪存等)上丢弃数据。可以通过从备份恢复和/或重新安装软件来修复。

可能导致无法修复的持久更改的因素包括:

  • 写入固件的闪存。这通常(但不总是)涉及一个复杂的序列来解锁它,然后“猜测”一个正确的加密密钥和/或数字签名。 请注意,如果您有意尝试这样做,这将非常困难,而且几乎不可能偶然发生。

  • 写入设备的闪存 ROM(如果有),可能包括硬盘的内部控制器、打印机等。这通常(但不总是)涉及防止它的保护。 请注意,这也几乎不可能偶然发生。

可能造成实际物理损坏的事情包括:

  • 反复将软盘驱动器磁头撞到它们的挡块上(例如,通过寻找可能几个小时不存在的“99 柱面”)以试图减少软盘驱动器的预期寿命。

  • 试图在一些非常老旧的“仅 VGA CRT”显示器上使用高分辨率视频模式(这些显示器无法处理更高的频率并且会爆炸)。 请注意,炸毁这些古老的显示器是它们唯一的好处。

  • 尝试在一些廉价且令人讨厌(且稀有)的笔记本电脑上设置不受支持的视频模式(例如,刷新率高于正常刷新率);在哪里可以煮沸液晶显示器中的液体。

请注意,上面的大多数事情要么需要使用保护模式或长模式(并且不能在实模式下工作),要么以某种方式涉及 IO 端口(不仅仅是内存写入)。

【讨论】:

  • 感谢您提供详细而有用的回答。 “几乎不可能偶然做到”的部分对我来说听起来非常好,所以如果在实模式下的内存访问由于错误而出错,我可能不应该担心。
  • @DanielMarschall:如今,除非您需要代码与特定硬件交互来测试它,否则使用 bochs 之类的模拟器进行编译/调试/编辑周期应该会容易得多,内置调试器。它应该能够单步执行任何操作。但是,是的,在真实硬件上启动有缺陷的代码不太可能导致重启无法解决的问题,也极不可能造成物理损坏。
猜你喜欢
  • 2016-06-02
  • 2014-06-05
  • 2021-07-13
  • 1970-01-01
  • 2010-10-04
  • 2012-12-13
  • 2013-10-19
  • 2014-02-17
  • 2014-09-08
相关资源
最近更新 更多