FSP switches SAI

Đang mở
  • Có gì không ổn?
#24 3 bình luận 5 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
c
Lĩnh vực
embedded-iot, security

Hướng nghiên cứu

Bắt đầu bằng cách xác định nơi FSP thay đổi SAI thành POSTBOOT_SAI và so sánh hành vi đó với các bảng thanh ghi EDS; không có tệp nguồn hoặc bài kiểm thử cụ thể nào được nêu. Công việc sẽ được xem là hoàn tất khi đã thống nhất phạm vi để thay đổi hoặc ghi lại tài liệu về việc chuyển đổi SAI và xác thực các tác động của nó đối với quyền truy cập của bootloader và bảo mật.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

FSP switches to POSTBOOT_SAI, there are several issues with that. TL;DR while it probably tries to achieve the opposite, it undermines firmware quality and security.

  • In some bootloaders FSP may run long before EOP, this means most of the bootloader runs with POSTBOOT_SAI.
  • In the EDS, implications of the SAI switch are not documented. Virtually for every register, it is unknown if it is still accessible after the SAI switch.
  • The SAI switch seems to force the bootloader to do some things in SMM. AFAIK, the use of SMM as a more privileged execution mode is generally discouraged, even internally at Intel. This means FSP forces bootloader development to go backwards.
  • Generally, security may be undermined if FSP locks something to early, i.e. in a state that doesn't play well with the security concept of the bootloader.

Especially the lack of documentation leads to many bugs in firmware. Even Intel developers working on bootloaders such as coreboot don't seem to know the implications of the SAI switch or lack the resources to re-evaluate all bootloader code wrt. the SAI switch. I fear there is currently a race to the bottom of firmware quality going on: the need to fix bugs eats too many resources which leads to more bugs for future products, eating even more resources. Plus, these resources are limited because of the lack of public documentation.

Two possible solutions come to mind:

  1. Do the SAI switch in the very last phase of FSP (or maybe even add an additional phase to lock things down?) and comprehensively document all the implications of the switch. For instance, in all the register tables, there could be column that mentions the applicable SAIs.
  2. Make the SAI switch optional in FSP and document how the boot loader can take care of it. This would not only prevent all SAI-switch related bugs but also leave the security concept in a single place, the bootloader. That the configuration of security mechanisms and their locking are currently split between bootloader and FSP makes it very hard to configure an Intel platform reasonably secure (unless you rely on additional security chips in your platform, which is not always affordable).

I think 1. is only feasible in the long run. But maybe it's not too late to set up 2. for all the FSPs that do the SAI switch yet?

Ngôn ngữ chính
C
Star
366
Fork
143
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của intel/FSP

Tất cả issue của intel/FSP

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.