<div dir="ltr"><div dir="ltr">On Tue, Nov 22, 2022 at 12:20 PM Jason A. Donenfeld <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pedro,<br> <br> On Tue, Nov 22, 2022 at 12:35 PM Pedro Falcato <<a href="mailto:pedro.falcato@gmail.com" target="_blank">pedro.falcato@gmail.com</a>> wrote:<br> > Given this patch plus the corresponding linux-efi patches wrt RNG, I'm<br> > mildly concerned about buggy RDRAND implementations compromising the<br> > kernel's RNG. Is this not a concern?<br></blockquote><div> </div><div>Hi,<br></div><div><br></div><div>Thank you for your thorough response, glad to have you in this thread.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Speaking with my kernel RNG maintainer hat on, no, this is not really a<br> concern, for several reasons:<br> <br> - The kernel's RNG takes input from multiple sources, continuously, and<br> tries to mix in new inputs rather quickly, especially at early boot.<br></blockquote><div><br></div><div>I am aware, but I'm more scared when it comes to very early boot (think linux's EFI stub or some other bootloader) I can see how</div><div>an ill-advised RNG_PROTOCOL user can try to exclusively rely on it (if it's available, which I don't believe it is atm on non-virtio-rng OVMF) vs</div><div>mixing in the few sources you can get at that point, making important things like KASLR addresses or possibly even a stack canary 100% guessable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - The kernel will use RDRAND on its own, even in the case that EFI<br> doesn't provide it, so it's not gaining anything here.<br></blockquote><div><br></div><div>Yes, but as you said, the kernel mixes RDRAND with a lot of other entropy sources and also does proper sanity checking on it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - EFI on actual baremetal firmware, as opposed to OVMF, already provides<br> EFI, so this is par for the course.<br></blockquote><div><br></div><div>Hm? What do you mean? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - Most of those RDRAND bugs have concerned coming in and out of various<br> sleep states, which doesn't really apply to early boot EFI.<br> <br> - And again, just to reinforce the first point, the kernel takes inputs<br> from many sources. Having EFI provide its own thing -- via RDRAND or<br> any other mechanism -- is complementary and will only help.<br> <br> Regarding your "corresponding linux-efi patches wrt RNG", I'm not quite<br> sure what you're referring to. If anything, recent work during this<br> cycle has been aimed around shuffling more sources of randomness in from<br> elsewhere. The EFI RNG protocol stuff has been in there already for a<br> long time. So maybe you misunderstood those? Or I'm misunderstanding<br> what you're referring to?<br></blockquote><div><br></div><div>Ah yes, I haven't been paying much close attention to the RNG patches themselves but now that I took a closer look I can see you're right.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> As a general point, this question of "do we have enough entropy?" or<br> "are we initialized yet?" is an impossible proposition. Entropy<br> estimation is impossible, and is only ever a guess, and that guess can<br> be sometimes wrong, even wildly wrong. So the kernel is increasingly<br> moving away from /relying/ on that, and is more focused on getting more<br> sources faster -- incorporating anything it can find, and mixing it into<br> the output stream more continuously. To that end, if EFI's got a DXE to<br> do something or another, please hook it up.<br> <br> Lastly, I think the concern you raised is inappropriate for Ard's<br> patchset, as it actually doesn't apply to it at all. This patchset is<br> about hooking an existing DXE up to OVMF, one that is hooked up<br> elsewhere, but wasn't for OVMF. This alone has nothing to do with the<br> concern. Rather, the concerns you raised are about the DXE itself. So to<br> that end, perhaps you should start a new thread or send some patches or<br> do something to the DXE that you're concerned about (e.g. a basic boring<br> power-on selftest like what the kernel has or something, if you're extra<br> worried). Or maybe not, for the reasons I listed above of things being<br> basically fine.<br></blockquote><div><br></div><div>I know, I'm not yelling at Ard for the (questionable?) choices done in the BaseRngLib code, but I'm concerned this patch may negatively influence any sort of early boot RNG,</div><div>particularly for the more naive users of RNG_PROTOCOL, by providing the possibly flawed RDRAND code. If the efi subsystem/EFISTUB code handles this case well by still mixing</div><div>in whatever sources it can get before using this entropy, then that's great, but providing things like a non-random RNG_PROTOCOL sounds very broken and very unsafe to me (again invoking</div><div>that possible KASLR at very early boot example).</div><div><br></div><div>Also the CPUID check seems like an important step towards not-breaking-old-CPUs.<br></div><div>All I'm saying is that we shouldn't just hook up the RNG DXE driver without carefully considering what the code is doing.<br></div></div><div><br></div><div>Thanks,<br></div><div>Pedro<br></div></div> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links:<p> You receive all messages sent to this group. <p> <a target="_blank" href="https://edk2.groups.io/g/devel/message/96551">View/Reply Online (#96551)</a> | | <a target="_blank" href="https://groups.io/mt/94935843/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a><br> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com]<br> <div width="1" style="color:white;clear:both">_._,_._,_</div>