UEFI를 활용한 베어메탈 프로그래밍 첫걸음

Hacker News 의견들 참고할 만한 UEFI 프로그래밍 자료가 더 있음. UEFI에서 실행하는 IRC 클라이언트: https://github.com/codyd51/uefirc. 이 클라이언트가 사용하는 UEFI 라이브러리: https://github.com/rust-osdev/uefi-rs. 별도의 GRUB·부트로더 코드 경로 없이 UEFI에서 커널을 불러와 Linux를 부팅하는 방법: https://pretalx.com/devconf-cz-2024/talk/W3AVCT/. LLM으로 부트로더부터 시스템 전체를 생성하는 개인 프로젝트를 조금 해봤지만, 본업과 같은 종류의 사고가 필요해서 번아웃을 피하려면 가끔 내려놓아야 함. 궁극적으로는 내 Linux 사용을 모델링한 시스템을 부팅해 커널 ↔ 모델 구조만 두고 싶음. BPF로 가능한 모든 것을 계획·모델링하고 sched_ext용 연산 스케줄로 변환하는 중임. 보안 측면에서는 웹캠과 키 등으로 확인하기 전에는 특정 메모리 영역에 접근하지 못하도록, 모델에 여러 인증 요건을 넣는 방법을 고민하고 있음. https://kevinboone.me/efitest4.html에서 “C 표준 라이브러리가 없는 환경에 익숙해져야 한다”고 하지만, edk2-libc라는 선택지도 있음: https://github.com/tianocore/edk2-libc. EFI가 Windows스럽다는 부분도 우연이 아님. 초기 Intel Boot Initiative에서 EFI, UEFI로 코드와 명세를 발전시키면서 Windows 코딩 방법론을 활용했음. 코딩 스타일 자료: https://computernewb.com/~lily/files/Documents/NTDesignWorkb.... 관련 개발 역사: https://www.intel.com/content/dam/www/public/us/en/documents.... EDK II에 최근 심각한 취약점인 CVE-2026-97631이 있으니 주의해야 함. https://app.opencve.io/cve/CVE-2026-97631 “코딩 방법론을 활용했다”는 결과에 비해 지나치게 긍정적인 표현임. “질병을 퍼뜨렸다”가 더 정확해 보임. UTF-16 문자열과 VFAT를 정말 써야 했을까? PE32+는 정당화할 여지가 있고, 내가 ELF를 선호하는 것도 더 좋아서가 아니라 익숙해서임. 하지만 VFAT는 납득하기 어려움. UTF-16이 문자열 형식으로...