Hashcat 海光 DCU
HIP 后端适配与跨平台验证

1. 执行摘要

hashcat v7.1.2 已包含 HIP 后端，但其内置 HIP ABI 与海光 DTK 的 libgalaxyhip.so 存在版本差异，设备初始化流程因而无法完成。本次工作先在 gfx936 + DTK 25.04.2 上完成根因定位与适配，再将同一方案迁移到 gfx906/Z100 + DTK 26.04，形成了一条从 ABI 探测、条件编译、运行时验证到跨版本回归的完整证据链。

跨版本验证环境

2. 测试环境与产物

最终二进制

二进制示例路径为 /path/to/hashcat/。OpenCL 基线版本单独保留，以便开展回归验证与性能对比。

3. 兼容性现象与原因分析

3.1 登录节点与计算节点的区别

登录节点未提供 /dev/kfd，因此该环境仅适合检查二进制中的 HIP 符号，不具备设备运行验证条件。进入已分配的 DCU 计算节点后，rocminfo、hy-smi 与 OpenCL 均可正常识别设备。

rocminfo:
  Name:           gfx936
  Marketing Name: BW
  Device Type:    HCU
  Compute Unit:   80

3.2 适配前的 HIP 初始化现象

./hashcat -II --backend-ignore-cuda --backend-ignore-opencl

hashcat (v7.1.2) starting in backend information mode
hipDeviceGetAttribute(): invalid argument
No devices found/left.

同一环境下 OpenCL 能够识别 BW 设备，可据此排除硬件、任务分配、驱动和设备权限等基础因素，并将分析范围收敛至 hashcat HIP 主机侧 API 兼容层。

3.3 ABI 差异

hashcat 为保持动态加载能力，在 include/ext_hip.h 内复制了 HIP 类型定义，而不是编译时直接依赖系统 HIP 头文件。hashcat v7.1.2 内置定义来自更新的 ROCm ABI；DTK 25.04.2 的 hip_runtime_defines.h 使用不同的旧版布局。

辅助探测程序还确认 DTK 的 sizeof(hipDeviceProp_t) = 792，关键字段偏移包括：totalGlobalMem=256、regsPerBlock=272、warpSize=276、clockRate=308、major=328、multiProcessorCount=336、gcnArchName=396。这与 hashcat 原定义明显不同。

4. 代码修改说明

实现遵循“默认构建行为保持不变、DTK 适配显式启用”的原则，改动集中在构建入口、HIP 类型定义、设备属性初始化、动态加载与适配说明文档。

DTK_HIP ?= 0

ifeq ($(DTK_HIP),1)
CFLAGS += -DHC_HIP_DTK
endif

#if defined (HC_HIP_DTK)
device_param->regsPerMultiprocessor = prop.regsPerBlock;
#else
device_param->regsPerMultiprocessor = prop.regsPerMultiprocessor;
#endif

hipDeviceGetAttribute(dev=0, attrib=69): invalid argument

5. 调试过程与关键转折

1. 确认二进制包含 HIP：检查到 hipInit、hipDeviceGetAttribute、hiprtcCompileProgram 等符号，以及 --backend-ignore-hip 参数。
2. 排除无卡节点误判：登录节点缺少 /dev/kfd；切换到已分配的计算节点后，DCU 与驱动均正常。
3. 建立 OpenCL 基线：原始二进制可通过 OpenCL 识别 BW，并完成 MD5 benchmark，证明硬件与 hashcat 核心功能正常。
4. 增强日志后锁定枚举：首个失败属性从不透明的错误变为 attrib=69，随后使用 DTK 头文件编译探测程序逐项核对数值和结构偏移。
5. 第一次 ABI 修复：同步属性枚举与结构体后，设备枚举推进到寄存器属性；运行时确认属性 69 不受 DTK 支持。
6. 寄存器兼容处理：辅助程序显示 prop.regsPerBlock=196608，而属性 69 返回错误，因此采用该值作为保守兼容数据。
7. HIP 设备枚举成功：hashcat 能显示 HIP 6.3.25422、BW、80 MCU、65520 MB 和 PCI 地址。
8. HIPRTC 验证：MD5 与 NTLM benchmark 成功，证明 gfx936 的运行时编译、module 加载和 kernel launch 链路可用。
9. 发现退出阶段 SIGSEGV：计算结果已经输出，但退出码为 139。使用 GDB 定位到 libstdc++ 的 atexit_thread.cc:75，栈顶为无符号的已卸载地址。
10. 修复 DSO 生命周期：DTK 分支保留 HIP/HIPRTC DSO 到进程退出，随后 benchmark 退出码恢复为 0。
11. 正确性验证：实际 MD5 字典攻击通过 self-test，并恢复 e11c594e6a2f4eb499cceadfca988595:13LEXON。

GDB 关键回溯

Thread 1 "hashcat-hip-dtk" received signal SIGSEGV
0x000015552f2620e0 in ?? ()
#0  0x000015552f2620e0 in ?? ()
#1  (anonymous namespace)::run
    at libstdc++-v3/libsupc++/atexit_thread.cc:75
#2  __run_exit_handlers () from /lib64/libc.so.6
#3  exit () from /lib64/libc.so.6

该回溯与“动态库已卸载，但退出处理器仍保留函数地址”一致。修改 DSO 生命周期后，同一测试正常退出，验证了判断。

6. Git 与编译过程

6.1 Git 建档

为保证适配过程可追溯，可先建立源码基线，再在独立分支记录 DTK HIP 适配变更。以下命令展示一种参考流程。

cd /path/to/hashcat
git init -b dtk-hip-adaptation
git add -A
git commit -m "baseline: import hashcat 7.1.2 source tree"

# 完成修改与验证后
git add .gitignore include/ext_hip.h src/Makefile \
  src/backend.c src/ext_hip.c src/ext_hiprtc.c \
  docs/dtk-hip-adaptation.md
git commit -m "feat: adapt HIP backend for DTK 25.04.2"

6.2 编译步骤

cd /path/to/hashcat

# 保留原始二进制
cp -p hashcat hashcat-opencl-original

# 清理并构建 DTK 专用版本
make clean
make DTK_HIP=1 ENABLE_LTO=0
mv hashcat hashcat-hip-dtk

# 基本检查
./hashcat-hip-dtk --version
sha256sum hashcat-hip-dtk hashcat-opencl-original

ENABLE_LTO=0 用于降低适配调试期间的链接复杂度并保持构建可预测性。核心适配由 DTK_HIP=1 启用。

6.3 DTK 26.04 环境的构建与调度差异

迁移平台的 DTK module 与较新的 GCC module 互斥，系统 GCC 4.8.5 又缺少 bridges 模块所需的 AVX512F 内建函数。实际采用 DTK 自带 dcc（Clang 17）编译源文件、系统 GCC 完成最终归档链接；bridges 未构建不影响本报告覆盖的核心哈希功能。

6.4 在 DCU 节点验证

ssh <compute-node>
cd /path/to/hashcat

# 只启用 HIP
./hashcat-hip-dtk -II \
  --backend-ignore-cuda \
  --backend-ignore-opencl

# 只启用 OpenCL
./hashcat-opencl-original -II \
  --backend-ignore-cuda \
  --backend-ignore-hip

7. 跨版本 ABI 与平台迁移验证

在 DTK 26.04 头文件环境中重新编译 ABI 探测程序，并与 25.04.2 的记录逐项比较。12 个实际使用的设备属性枚举完全一致：18、25、26、27、29、32、36、37、39、40、42、79。

8. 功能与正确性验证

./hashcat-hip-dtk -m 0 -a 0 example0.hash example.dict \
  --backend-ignore-cuda --backend-ignore-opencl \
  --potfile-disable --restore-disable

Recovered:
e11c594e6a2f4eb499cceadfca988595:13LEXON

该字典测试的最终状态码为 1：输入包含 6494 个哈希，小字典耗尽时恢复其中 1 个。self-test 与目标恢复均成功，因此该状态码反映任务完成条件，而非 HIP 后端异常。

迁移平台设备验证

HIP.Version.: 6.3.26113

Backend Device ID #01
  Name...........: Device 66a1
  Processor(s)...: 64
  Preferred.Thrd.: 64
  Clock..........: 1700
  Memory.Total...: 16368 MB
  Memory.Free....: 16101 MB
  Memory.Unified.: 0
  Local.Memory...: 64 KB
  PCI.Addr.BDFe..: <redacted>

该平台完成设备枚举、HIPRTC 内核编译、属性读取、多算法 benchmark 与退出码检查，全部通过。PCI 地址等环境指纹已脱敏。

9. 性能验证与对比

9.1 gfx936 同卡后端测试方法

为了避免短 benchmark 隐藏热稳定和持续调度差异，采用 SHA2-256 的 8 位全字符集暴力攻击，密钥空间为 95^8 = 6,634,204,312,890,625。使用不易命中的目标哈希保证 DCU 持续满载，每个后端运行约 45 秒，并通过 hy-smi 每 2 秒采样功耗、温度和利用率。

# HIP
./hashcat-hip-dtk -m 1400 -a 3 \
  ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
  '?a?a?a?a?a?a?a?a' -O -w 3 --runtime 45 \
  --status --status-timer 5 --potfile-disable --restore-disable \
  --backend-ignore-cuda --backend-ignore-opencl

# OpenCL：攻击参数相同，只切换后端和二进制
./hashcat-opencl-original -m 1400 -a 3 \
  ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
  '?a?a?a?a?a?a?a?a' -O -w 3 --runtime 45 \
  --status --status-timer 5 --potfile-disable --restore-disable \
  --backend-ignore-cuda --backend-ignore-hip

9.2 gfx936 核心结果

速度可视化

9.3 自动调优与资源差异

两个后端选择了不同的工作组和加速组合，但最终吞吐一致，说明两条路径均能充分利用该 DCU。HIP 的主机内存占用明显更高，是本次测试中最明确的资源差异。

9.4 累计进度为何不直接比较

最终记录的 HIP 进度为 266,757,734,400，OpenCL 为 270,092,206,080。OpenCL 看似高约 1.25%，但其最终状态落在约 46 秒，而 HIP 为约 45 秒；初始化、状态刷新和 runtime 停止边界也不完全相同。因此报告以 hashcat 的 10 个持续速度样本作为主比较依据，而不以累计进度得出性能结论。

9.5 gfx906/Z100 多算法 HIP benchmark

迁移平台没有可用的 OpenCL 运行时，因此本组数据用于验证算法覆盖和平台稳定性，不与该平台的 OpenCL 后端做推断性比较。

调度参数依次为 Accel / Loops / Threads / Vector width。

9.6 持续负载与跨设备观察

这组比例是两套整机环境的实测观察，包含计算单元、架构、显存子系统、软件版本与调优参数等多重差异，不能仅由 64/80 的计算单元比例推导，也不代表所有 hash-mode 的固定比例。

10. 结论、建议与已知限制

已知限制

• 适配已验证 DTK 25.04.2 / HIP 6.3.25422 与 DTK 26.04 / HIP 6.3.26113；未来版本仍须重新核对枚举值、结构体大小和字段偏移。
• gfx936 覆盖实际攻击及 HIP/OpenCL 对照；gfx906 覆盖 10 种算法，但缺少同卡 OpenCL 对照。
• regsPerMultiprocessor 使用保守兼容值；当前算法运行正常，但可能影响某些内核的调优上限。
• DTK 构建故意不提前 dlclose HIP/HIPRTC DSO。这不会造成进程生命周期之外的泄漏，但与标准 hashcat 的卸载行为不同。
• 45–60 秒测试适合比较稳定吞吐，不等同于数小时或数天的长期可靠性测试。
• 迁移环境的旧 GCC 未构建 bridges 模块，批处理作业也受站点调度策略影响；两者均不应外推为 hashcat 核心限制。

后续建议

1. 按常用工作负载扩展测试：-m 1000、-m 10900、-m 22000、-m 3200。
2. 对 HIP 和 OpenCL 分别执行 1–4 小时稳定性测试，监控温度、功耗、驱动日志和错误计数。
3. 为 DTK ABI 增加自动化探测或编译期断言，避免 DTK 升级后静默使用错误布局。
4. 如果目标是获得性能提升，应进一步分析 HIPRTC 编译参数、寄存器占用、wavefront 行为和专用 tuning，而不是仅切换后端。

11. 附录：复现与审计命令

查看代码变更

cd /path/to/hashcat
git status
git log --oneline --decorate -5
git show --stat <adaptation-commit>
git show <adaptation-commit>

重新构建

make clean
make DTK_HIP=1 ENABLE_LTO=0
mv hashcat hashcat-hip-dtk

基本验证

ssh <compute-node>
cd /path/to/hashcat

./hashcat-hip-dtk -II --backend-ignore-cuda --backend-ignore-opencl
./hashcat-hip-dtk -b -m 0 --backend-ignore-cuda --backend-ignore-opencl --runtime 10
./hashcat-hip-dtk -b -m 1000 --backend-ignore-cuda --backend-ignore-opencl --runtime 10

关键文件索引