Re: *countable infinities only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 31, 2012 at 1:21 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
> On 05/31/2012 02:17 PM, Jon Ciesla wrote:
>> On Thu, May 31, 2012 at 1:08 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
>>> 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.
>> Is there an implementation of this existing today for HDD?
> Not yet.  But HDD technology is changing rapidly.  Just look at hybrid drives, SSD.
>
> No reason they could not add this capability.

Right.  But it's not there now, which is my point.

>
>>   Because
>> otherwise with existing technology, AFAIK, that limits your media
>> choices for root fs medium to CD/DVD-R, Floppy, Zip/Jaz disc, or some
>> models of USB flash drive.
> Yes, all these would currently support what I'm suggesting.

Actually, if you're willing to flip a lot of switches, you could
probably make your / a raid5 of floppies, but the performance would be
suboptimal.

-J

>
>>
>> Some of these would work better than others. :)
>>
>> -J
>>
>>
>
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux