Max `pBuffer` size for `stse_data_storage_update_data_zone()` unclear due to hidden overhead bytes
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- c
- Lĩnh vực
- embedded-iot, security
Hướng nghiên cứu
Start in api/stse_data_storage.h, then trace stsafea_update_data_zone() in services/stsafea/stsafea_data_partition.c through stsafea_frame_transmit() in stsafea_frame_transfer.c and stse_platform_i2c_send_start(). Verify how payload, command fields, CRC, and response length contribute to frame_length; done means the maximum pBuffer size and the >= check are clearly established.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
I need to write a 639-byte DER certificate into the data partition (NVM zone index 1) of the STSAFE-A110, which has 700 bytes available. I cannot write all 639 bytes in a single call because we configured our Platform Abstraction Layer to use a buffer of STSAFEA_MAX_FRAME_LENGTH_A110 + 3 (507 + 3 = 510) bytes for I2C communication. So I considered implementing a function that writes the certificate by sending it in chunks of up to STSAFEA_MAX_FRAME_LENGTH_A110 (507) bytes via multiple calls to stse_data_storage_update_data_zone().
The problem is that if I try to write a chunk of 507 bytes, STSE_SERVICE_FRAME_SIZE_ERROR is immediately returned because the following condition evaluates to true (507 >= 507). I’m wondering why >= is used instead of simply >, is that a BUG?:
https://github.com/STMicroelectronics/STSELib/blob/7b34b7c9a5cc35eab6bd7c08c29a41efe3d88d8c/services/stsafea/stsafea_data_partition.c#L381-L383
In any case, I reduced the maximum chunk size to STSAFEA_MAX_FRAME_LENGTH_A110 - 1 (506), but then the failure occurs later due to stse_platform_i2c_send_start(), which returns STSE_PLATFORM_BUFFER_ERR, because frame_length is 513 bytes:
stse_ReturnCode_t stse_platform_i2c_send_start(PLAT_UI8 bus_id, PLAT_UI8 dev_addr, PLAT_UI16 speed,
PLAT_UI16 frame_length)
{
/* Check buffer overflow */
if (esc_stse_i2c[bus_id].tx_rx_buffer_length < frame_length) // 510 < 513
{
return STSE_PLATFORM_BUFFER_ERR;
}
esc_stse_i2c[bus_id].tx_rx_frame_length = frame_length;
esc_stse_i2c[bus_id].tx_rx_frame_offset = 0;
return STSE_OK;
}
Note that esc_stse_i2c[bus_id].tx_rx_buffer_length is set by us to STSAFEA_MAX_FRAME_LENGTH_A110 + 3 (507 + 3 = 510).
I would have expected the frame_length argument to be 509 (506 + 3), since here (https://github.com/STMicroelectronics/STSELib/issues/53#issuecomment-3809960369) @TofMassilia13320 mentioned that setting the I2C platform buffer to the maximum value STSAFEA_MAX_FRAME_LENGTH_Axxx + 3 bytes ensures full command coverage of the selected STSAFE-A without overflow at the I2C platform layer.
This led me to assume that STSELib would invoke stse_platform_i2c_send_start() with a frame_length argument that could reach at most STSAFEA_MAX_FRAME_LENGTH_Axxx + 3 (510 in my case).
In other words, I understood that STSELib adds at most 3 bytes to the user data (2 bytes for the response length + 1 byte for the command or response header), as mentioned by @nils-cercariolo-st here: https://github.com/STMicroelectronics/STSELib/issues/53#issuecomment-3802661164. However, this does not seem to hold true, as in my case frame_length is actually 513.
Digging into STSELib, I concluded that the extra 7 bytes are added by stsafea_update_data_zone() and stsafea_frame_transmit(). Specifically:
-
stsafea_update_data_zone()adds 5 bytes at the beginning of the I2C frame: 1 byte header, 1 byte zone access option, 1 byte zone index, and 2 bytes offset:
https://github.com/STMicroelectronics/STSELib/blob/7b34b7c9a5cc35eab6bd7c08c29a41efe3d88d8c/services/stsafea/stsafea_data_partition.c#L374-L379 -
stsafea_frame_transmit()adds 2 bytes of CRC at the end of the I2C frame:
https://github.com/STMicroelectronics/STSELib/blob/7b34b7c9a5cc35eab6bd7c08c29a41efe3d88d8c/services/stsafea/stsafea_frame_transfer.c#L63-L64
So the problem is: how can I determine the maximum length of the buffer pBuffer that I am allowed to pass to stse_data_storage_update_data_zone()?
https://github.com/STMicroelectronics/STSELib/blob/7b34b7c9a5cc35eab6bd7c08c29a41efe3d88d8c/api/stse_data_storage.h#L88-L112
- Ngôn ngữ chính
- C
- Star
- 15
- Fork
- 12
- Merge trung bình
- 1 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 11
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của STMicroelectronics/STSELib
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
STMicroelectronics/STSELib#115 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
# Bug: `stse_perso_info_t` AC status 2-bit mask truncates valid AC valuesCó thể làm lại được @Grom- đã nhận 204 ngày trước và không có pull request nào đang mở. Đang mởbug
STMicroelectronics/STSELib#69 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`stse_platform_Crc16_Accumulate()` is not safeCó thể làm lại được @nils-cercariolo-st đã nhận 192 ngày trước và không có pull request nào đang mở. Đang mở
STMicroelectronics/STSELib#65 · 3 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
STSAFE A120: Reprovisioning is successful, but returns error STSE_INVALID_C_MACCó thể làm lại được @Grom- đã nhận 336 ngày trước và không có pull request nào đang mở. Đang mởbug
STMicroelectronics/STSELib#47 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của STMicroelectronics/STSELib
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
base-files: 82_config_generate: regenerate /etc/board.json if 0-bytes / truncated after power cutĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
openwrt/openwrt#25940 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
FujiNetWIFI/fujinet-lib#186 ·
Maintainer thường phản hồi trong vòng 1 ngày