On 08.12.22 14:36, Jan Kiszka wrote: > On 08.12.22 10:25, Christian Storm wrote: >> Hi, >> >>>>> All that should be signed, so this is "just" a safety measure, right? >>>> >>>> yes, this is just a convenience feature to give the user a proper >>>> error message instead of (hundreds of thousands) synchronous >>>> exceptions. >>>> >>>>> Is that enough, or should we look systematically for such things? >>>> >>>> Well, I think this one was particularly "nasty" because it seems you >>>> will get a synchronous exception for *every* invalid memory access >>>> (of which there are many due to the underflow). So I'd say it's >>>> enough for the time being. However, I had to insert quite a few >>>> logging statements into the kernel stub to find out what's going on. >>>> My custom kernel stub was quite verbose, which is probably not what >>>> you want by default, but I'd fancy a mechanism to turn on verbose >>>> logging for the kernel stub (without having to recompile). I'm not >>>> too familiar with UEFI programming, so I don't know how feasible >>>> that is. >>>> >>> >>> Rather than adding lots of runtime checks to the image, which is >>> specifically questionable in secure boot scenarios where the integrity >>> check comes first anyway, I wonder if we should rather improve the >>> generator script in this regard. >> >> Both, if you ask me ;) >> >> The generator script would ideally check this ― but you cannot rely on >> every boot artifact being built by "our" script, and then the run-time >> check(s) come in handy as last resort so to say. >> >> I don't see how that touches integrity in Secure Boot scenarios? You can >> boot perfectly integer artifacts that simply don't boot... It's more about >> sematics here not syntax which is what integrity enforces. >> > > I don't mind adding runtime checks if they help in debugging not > completely unlikely issues. > > But I'm even more interested in finding and avoiding issues between the > artifact production, UKI generation and finally signing possibly > corrupted things. >
I mean, checking for this obvious issue that there is an integer overflow does not catch cases of a corrupted and too large SizeOfImage field. Jan -- Siemens AG, Technology Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/6abe24b9-af0f-ce22-b3aa-8b8adeb4a971%40siemens.com.
