From 47a9f91760bf7a44cb96c386d2b3f32cce5a1d89 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 20 Apr 2022 15:32:10 +0200 Subject: [PATCH] update TODO --- TODO | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/TODO b/TODO index 77eaeb3fc3..5c05a75a48 100644 --- a/TODO +++ b/TODO @@ -202,6 +202,22 @@ Features: as directory manifest. The file would be a standard directory listing as generated by GNU sha256sums. +* sd-boot: maybe add support for embedding the various auxiliary resources we + look for right in the sd-boot binary. i.e. take inspiration from sd-stub + logic: allow combining sd-boot via objcopy with kernels to enumerate, .conf + files, drivers, keys to enroll and so on. Then, add whatever we find that way + to the menu. Usecase: allow building a single PE image you can boot into via + UEFI HTTP boot. + +* maybe add a new UEFI stub binary "sd-http". It works similar to sd-stub, but + all it does is download a file from a http server, and execute it, after + optionally checking its hash sum. idea would be: combine this "sd-http" stub + binary with some minimal info about an URL + hash sum, plus .osrel data, and + drop it into the unified kernel dir in the ESP. And bam you have something + that is tiny, feels a lot like a unified kernel, but all it does is chainload + the real kernel. benefit: downloading these stubs would be tiny and quick, + hence cheap for enumeration. + * initialize machine ID from systemd credential picked up from the ESP via sd-stub, so that machine ID is stable even on systems where unified kernels are used, and hence kernel cmdline cannot be modified locally