Redfish multipart 文件解析崩溃问题

[zhenghaowei (河南昆仑-郑豪伟)]

【求助】OpenUBMC Redfish multipart 文件解析崩溃问题

问题描述

在 OpenUBMC 的 Redfish UpdateService 固件升级接口（/redfish/v1/UpdateService/update-multipart）开发过程中，遇到 multipart 请求解析的内存崩溃问题：

• 使用 multipart/form-data 时，http.agent 层会尝试解析请求体，大文件上传时服务崩溃（返回 500，且无日志输出）。
• 使用 multipart/mixed 时，http.agent 不解析，原始 body 字符串透传到 controller，可以正常进入业务逻辑（返回 200 ）。
  
  

当前测试命令使用 multipart/mixed 绕过了 http.agent 的解析问题
核心问题是：multipart/form-data 在大文件场景下导致服务崩溃，但规范要求该接口必须使用 multipart/form-data。

环境信息

• 操作系统：OpenUBMC（基于 OpenBMC）
• 软件版本：OpenUBMC260330
• 相关模块：Redfish UpdateService、http.agent、form_data 解析模块

相关代码

function u_utils.post(ctx)
    if ctx.req.body.error then
        p_utils.log_operation(ctx.user, 'Upload file failed')
        return RET_ERR
    end

    local req_body
    local form_data_flag, boundary = form_data.is_form_data_req(ctx.req.header)
    if form_data_flag then
        req_body = form_data.decode_form_data(ctx.req.body, boundary)
    else
        req_body = ctx.req.body
    end
    -- ...
end

重现步骤

1. 使用 multipart/form-data 发送固件升级请求（含大文件 .hpm）：

curl -k --location --request POST 'https://<BMC_IP>/redfish/v1/UpdateService/update-multipart' \
    --header 'Authorization: Basic <credentials>' \
    --form 'UpdateParameters={"Targets":[...]}' \
    --form 'UpdateFile=@/path/to/large_file.hpm'

2. 服务返回 500 Internal Server Error，无错误日志输出。

3. 改用 multipart/mixed 绕过 http.agent 解析：

curl -k --location --request POST 'https://<BMC_IP>/redfish/v1/UpdateService/update-multipart' \
    --header 'Authorization: Basic <credentials>' \
    --form 'UpdateParameters="...";type=application/json' \
    --form 'UpdateFile=@/path/to/file.hpm' \
    -H 'Content-Type: multipart/mixed'

4. 服务返回 200

期望结果

1. 接口能够正确处理 multipart/form-data 格式的大文件上传请求，不崩溃。

实际结果

服务崩溃（500），无日志

尝试过的解决方案

1. 使用 multipart/mixed 绕过 http.agent 解析 —— 部分有效，绕过了崩溃点。
2. 检查 form_data.decode_form_data 实现 —— 闭源模块，失败

[ubmc_assistant (openUBMC_Assistant)]

答案内容由AI生成，仅供参考：

### 总结

根据现有信息，**崩溃的根本原因很可能是当前 OpenUBMC 版本对 `multipart/form-data` 的大文件解析支持不完善**，属于已知限制或未实现的场景。建议：
- 升级到官方推荐的最新稳定版本（如 25.12 LTS SP1 或后续 26.03 补丁）。
- 同时确保构建配置完整，并参考社区最新评审通过的 `MultipartUriSuffix` 定制化方案进行适配。

点击此处查看详细分析解答

根据您提供的上下文信息，对于 OpenUBMC Redfish multipart 文件解析崩溃问题，目前没有找到直接的诊断或修复方案。但可以从已有信息中梳理出相关线索，帮助您定位问题根源。

---

相关上下文线索

1. 社区讨论中明确提及“当前不支持该场景”
   在文档片段 2（topic_id 4293）中，用户 kunlun-lishen 询问如何实现一个请求体为表单形式的 Redfish POST 接口（即 multipart/form-data），最终回复者 vyasa 直接说明：

   “当前不支持该场景”
   这表明在特定版本中，multipart/form-data 上传固件的功能尚未完整实现，可能正是导致服务崩溃的根本原因。

2. 新增 MultipartUri 后缀定制化项的评审
   在搜索结果第 3 条【已评审】中描述：

   “当前 openUBMC 在处理带有 multipart/form-data 类型的 http 请求时，均需要通过手写的 Controller 进行处理（如果是完全定制的 URI 则需要单独定制 app 进行实现）……”
   这暗示原始代码对 multipart/form-data 的支持比较薄弱，依赖手动处理，大文件场景下容易出错。

3. 大文件可能引发内存或存储问题
   搜索结果第 6 条讨论了 /dev/shm 目录下大文件未被清除的问题，指出：

   “磁盘空间耗尽 → 升级失败（因空间不足）… 影响后续固件激活”
   虽然不直接对应您描述的崩溃，但大文件上传时的缓冲、临时文件处理可能触发类似的内存分配失败或 OOM（Out of Memory）导致服务崩溃，并且无日志输出。

4. 固件解析阶段的已知问题
   文档片段 7 中日志显示：

   firmware_mgmt ERROR: … parse package failed, ret: … logging.lua:253: bad argument #2 to ‘format_msg’ (number expected, got nil)
   这是在 parse package 时出现的空值异常，属于固件管理模块的缺陷。虽然与您遇到的 http.agent 层崩溃不同，但说明当前版本存在多处数据处理逻辑的健壮性问题。

---

问题分析

• 直接原因：http.agent 在遇到 multipart/form-data 且携带大文件时，其内部的 form_data.decode_form_data 函数（闭源）可能存在内存越界、缓冲区溢出或对超大请求体处理不当的问题，导致进程直接崩溃（返回 500 且无日志）。
• 为什么 multipart/mixed 能绕过：http.agent 仅对 multipart/form-data 进行主动解析（如尝试解码表单字段），而对 multipart/mixed 则作为原始 Body 透传给 Controller，从而跳过了有问题的解析路径。
• 规范要求：Redfish 标准中，MultipartHttpPushUri 要求使用 multipart/form-data，因此不能长期依赖 multipart/mixed 作为替代。

---

建议行动

根据上下文中的推荐做法，您可以尝试以下步骤：

1. 确认版本是否已提供官方支持
   查看您使用的 OpenUBMC 版本（26.03.30）的发布说明或社区公告，确认 multipart/form-data 的 UpdateService 接口是否已经正式支持。如果尚未支持，建议升级到包含该功能的新版本（如后续的 26.03 LTS SP1 或 25.12 LTS 相关补丁）。

2. 参考新版本的实现方式
   搜索结果第 2、3 条提到已新增 MultipartUriSuffix 定制化和配置项，说明该功能已在开发中或已经合入。可参考 【已评审】新增 MultipartUri 后缀定制化项和配置项 等资料，了解如何正确配置和使用。

3. 检查构建配置
   文档片段 1 强调：

   “检查 manifest.yml 是否启用必需组件（特别是 redfish 和 web_backend）”
   并建议启用制造模式（manufacture: true）。确保您的构建配置完整，避免因服务缺失导致行为异常。

4. 临时调试措施

   • 升级前清空日志并禁用自动回滚，以便捕获更详细的错误信息。
   • 使用 ipmcget -d dump 收集完整日志，重点查看 framework.log 和 app.log 中是否有 http.agent 或 form_data 相关的崩溃痕迹。
   • 如果 form_data 模块为闭源，建议联系 OpenUBMC 社区或 PAE（平台应用工程师）获取补丁或已知问题列表。

5. 若问题持续
   请在 OpenUBMC 论坛提交话题，提供：

   • 完整重现步骤
   • 使用的固件包（.hpm）的 SHA256 哈希
   • 尝试 Content-Type: multipart/form-data 时的 curl 命令输出和 BMC 日志（尤其是崩溃前后的日志）
   • 标识引用相关话题（如 #4293）。

---

总结

根据现有信息，崩溃的根本原因很可能是当前 OpenUBMC 版本对 multipart/form-data 的大文件解析支持不完善，属于已知限制或未实现的场景。建议：

• 升级到官方推荐的最新稳定版本（如 25.12 LTS SP1 或后续 26.03 补丁）。
• 同时确保构建配置完整，并参考社区最新评审通过的 MultipartUriSuffix 定制化方案进行适配。

[vyasa (欧文健)]

可以尝试修改redfish服务的日志级别为debug查看具体错误信息