On 05/31/2012 01:57 PM, Jon Ciesla wrote: > On Thu, May 31, 2012 at 12:52 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >> On 05/31/2012 01:48 PM, Jon Ciesla wrote: >>> On Thu, May 31, 2012 at 12:42 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>> On 05/31/2012 01:34 PM, Jon Ciesla wrote: >>>>> On Thu, May 31, 2012 at 12:22 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>> On 05/31/2012 01:19 PM, Jon Ciesla wrote: >>>>>>> On Thu, May 31, 2012 at 12:16 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>> On 05/31/2012 01:10 PM, Gregory Maxwell wrote: >>>>>>>>> On Thu, May 31, 2012 at 1:07 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>>>> Could be any of a thousand ways to implement this. >>>>>>>>>> Maybe it checks the BIOS to determine whether some SecureBoot flag is set. >>>>>>>>> While it pains me to argue with someone on my side— you're incorrect. >>>>>>>>> The compromised system would just intercept and emulate or patch out that test. >>>>>>>> Then what's missing here is a way for booted OS's to test themselves for integrity. >>>>>>> Maybe some sort of cryptographic signature stored in the hardware? >>>>>>> >>>>>>> <ducks> >>>>>>> >>>>>>> -J >>>>>>> >>>>>>> </sarcasm> >>>>>>> >>>>>> Just not dictated by one monopoly. >>>>> Ideally, no. But you see the problem. I'm divided on the solution >>>>> myself, but I've yet to see one I feel better about. >>>>> >>>>> -J >>>>> >>>>> >>>> This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where >>>> known good code resides. >>> We have that, ISO9660. Known good == known good to whom? >>> >>> >> Nah, can't be iso. >> >> Has to be HDD partitions whose ro/rw state is controlled by hardware. > Which brings us back to the issue of how the hardware knows what to > trust for that ro/rw state. The hardware is under control of the user. At some point the user has to know what they consider trusted. During installation from a known good installation source: DVD, network, whatever, the user enables the install to write on the partition by actively pressing a hardware button that allows the write. After the installation is finished the user switches it back to read-only through pressing the hardware button. The user now has a known good read-only installation to boot from. . -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel