Quoting from a previous post on this subject (thread) not from me:
UEFI is part of the old "Palladium" project from Microsoft, relabeled as
"Trusted Computing". It is aimed squarely at DRM and vendor lock-in, not
security
End quote.
Is the above language inflammatory? If not, how is my language
inflammatory? Mine merely restates in plain blunt English "DRM and
vendor lock-in", or so I intended.
Yasha Karant
On 09/24/2013 09:44 PM, jdow wrote:
> I don't think that's directly what has been said, Yasha. In less loaded
> terms it appears there are motherboard vendors who are not strictly
> compliant with the UEFI specification and do not allow you to turn off
> UEFI without using some software with Microsoft roots. They have elected
> to leave out, or so thoroughly obscure, any BIOS based means of disabling
> the UEFI "protections." This is neither a Linux or Microsoft issue. It is
> an issue to take up with the motherboard vendor and get a fix for it.
>
> In this sense your last paragraph is true of couched in inflammatory
> terms that place the blame on the wrong party. The party responsible
> is the motherboard vendor for violating the UEFI specification as I
> understand it. And that only holds if you cannot find some place in
> the BIOS that disables secure boot, UEFI, or whatever else the board
> manufacturer calls it AND the mother board vendor will not provide you
> with the required information that is not OS based on any OS.
>
> {^_^} Joanne
>
> On 2013/09/24 17:20, Yasha Karant wrote:
>> Let me see if I understand the current situation. This question was
>> prompted by
>> the question of a colleague attempting to use OpenSuSE (not SL nor
>> TUV) on UEFI
>> Secure Boot who was not able to get a reliably booted running operating
>> environment. The colleague wondered if SL would fare better.
>>
>> Depending upon the particular BIOS or BIOS equivalent, using MS
>> Windows 8, it
>> may be possible to disable Secure Boot and allow for SL to be booted.
>> Secure
>> Boot, and many other technologies put forward by, through, or under
>> the auspices
>> of the monopoly primarily exist to move forward the market share,
>> return on
>> investment, and general economic wealth of the monopoly (not a
>> surprise in
>> oligopolistic non-market economics).
>>
>> SL with Fermilab participation is participating in projects that will
>> allow SL
>> to boot on UEFI Secure Boot hardware without the use of any monopoly
>> operating
>> environment software or applications -- Microsoft not required.
>> Presumably, TUV
>> is participating as well as TUV supported-for-fee environments must be
>> able to
>> reliably boot and run on UEFI Secure Boot platforms without the use of
>> monopoly
>> software to enable the booting process. Apple is not a matter for
>> discussion
>> because Apple provides the entire hardware and software package, and
>> does not
>> allow the use of MacOS on non-Apple hardware platforms. Presumably
>> VirtualBox
>> and other means to allow MS Windows to run as a guest environment has
>> or will
>> have some means to provide UEFI Secure Boot to MS Windows guests
>> requiring such.
>>
>> At present, there is no production Linux that will reliably run on all
>> hardware
>> platforms that use UEFI Secure Boot, but only MS Windows envirnoments
>> will do so
>> on any hardware platform that proclaims compliance with the monopoly
>> ("certification").
>>
>> Is the above substantially correct as of this instant?
>>
>> Yasha Karant
>>
>> On 09/24/2013 04:40 PM, Connie Sieh wrote:
>>> On Tue, 24 Sep 2013, Nico Kadel-Garcia wrote:
>>>
>>>> --001a11c379ecc5abcb04e7297e9d
>>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>>
>>>> Down, boy.
>>>>
>>>> Scientific Linux is behind the times on available tools, because our
>>>> favorite upstream vendor has not yet released tools. Tools to work with
>>>> have been tested, effectively, with Fedora, and I expect our favorite
>>>> upstream vendor will include tools with release 7.x, which is not
>>>> yet in
>>>> alpha or beta release. Check out
>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html-single/UEFI_Secure_Boot_Guide/index.htmlfor
>>>>
>>>>
>>>>
>>>> a good breakdown of the issues and trade-offs.
>>>>
>>>> UEFI is part of the old "Palladium" project from Microsoft,
>>>> relabeled as
>>>> "Trusted Computing". It is aimed squarely at DRM and vendor lock-in,
>>>> not
>>>> security, for reasons that I could spend a whole day discussing.In the
>>>> meantime, yes, you can disalbe it for SL booting if needed, and
>>>> reasonably
>>>> expect our favorite upstream vendor to have shims available when
>>>> version 7
>>>> is publishedL they're already working well with recent Fedora
>>>> releases. I'd
>>>> also *expect* those shims to be workable for SL 7, but someone may
>>>> have to
>>>> plunk down some cash to get some keys signed, and spend some extra
>>>> effort
>>>> to maintain the security needed for the relevant shims to work well
>>>> with SL
>>>> kernels and environments.
>>>
>>> Last week at LinuxCon North America the shim developers were still
>>> developing.
>>>
>>> I attended the UEFI Plugfest last week as part of Linux Con. Microsoft
>>> gave a presentation on UEFI signing. The presentation will be posted to
>>> uefi.org website.
>>>
>>> We are working on this. Fermilab is a member of the UEFI forum .
>>>
>>> -Connie Sieh
>>>
>>>>
>>>>
>>>> On Tue, Sep 24, 2013 at 11:53 AM, Yasha Karant <[log in to unmask]>
>>>> wrote:
>>>>
>>>>> Secure boot is enabled. Evidently, the only means to disable secure
>>>>> boot
>>>>> requires that a secure boot loader/configuration program be running --
>>>>> e.g., the MS proprietary boot loader (typically, supplied as part
>>>>> of MS
>>>>> Windows 8) must be used to disable secure boat if the UEFI actually
>>>>> permits
>>>>> this to be disabled (I have heard of some UEFI implementations that
>>>>> do not
>>>>> permit secure boot truly to be disabled).
>>>>>
>>>>> If Linux cannot handle this issue, then Linux is finished on all
>>>>> generic
>>>>> (e.g., not Apple that supplies both the hardware and operating
>>>>> environment
>>>>> software under a restrictive proprietary for-profit intellectual
>>>>> property
>>>>> license) X86-64 hardware, as (almost?) all current such hardware is
>>>>> MS 8
>>>>> (UEFI secure boot) compliant.
>>>>>
>>>>> Yasha Karant
>>>>>
>>>>> On 09/23/2013 10:29 PM, Connie Sieh wrote:
>>>>>
>>>>>> On Mon, 23 Sep 2013, Yasha Karant wrote:
>>>>>>
>>>>>> A colleague who uses SuSE non-enterprise for his professional
>>>>>>> (enterprise) workstations has now attempted to load the latest SuSE
>>>>>>> on a
>>>>>>> machine with a new generic (aftermarket) "gamer" UEFI X86-64
>>>>>>> motherboard. It does not properly boot. I do not have any UEFI
>>>>>>> motherboards, and thus no experience with SL6x on such motherboards.
>>>>>>>
>>>>>>
>>>>>> Is "secure boot" enabled in the UEFI ?
>>>>>>
>>>>>>
>>>>>>> Does anyone? Does SL6x boot correctly (and easily) on a UEFI
>>>>>>> motherboard? If so, he may switch to SL.
>>>>>>>
>>>>>>
>>>>>> Yes as long as "secure boot" is disabled .
>>>>>>
>>>>>>
>>>>>>> Yasha Karant
>>>>>>>
>>>>>>>
>>>>>> -connie sieh
>>>>>>
>>>>>
>>>>
>>>> --001a11c379ecc5abcb04e7297e9d
>>>> Content-Type: text/html; charset="ISO-8859-1"
>>>> Content-Transfer-Encoding: quoted-printable
>>>>
>>>> <div dir=3D"ltr"><div><div><div>Down, boy.<br><br></div>Scientific
>>>> Linux is=
>>>> behind the times on available tools, because our favorite upstream
>>>> vendor =
>>>> has not yet released tools. Tools to work with have been tested,
>>>> effectivel=
>>>> y, with Fedora, and I expect our favorite upstream vendor will include
>>>> tool=
>>>> s with release 7.x, which is not yet in alpha or beta release. Check
>>>> out <a=
>>>> href=3D"http://docs.fedoraproject.org/en-US/Fedora/18/html-single/UEFI_Sec=
>>>>
>>>>
>>>> ure_Boot_Guide/index.html">http://docs.fedoraproject.org/en-US/Fedora/18/ht=
>>>>
>>>>
>>>> ml-single/UEFI_Secure_Boot_Guide/index.html</a> for a good breakdown
>>>> of the=
>>>> issues and trade-offs.<br>
>>>> <br></div>UEFI is part of the old "Palladium" project from
>>>> Micros=
>>>> oft, relabeled as "Trusted Computing". It is aimed squarely
>>>> at DR=
>>>> M and vendor lock-in, not security, for reasons that I could spend a
>>>> whole =
>>>> day discussing.In the meantime, yes, you can disalbe it for SL booting
>>>> if n=
>>>> eeded, and reasonably expect our favorite upstream vendor to have
>>>> shims ava=
>>>> ilable when version 7 is publishedL they're already working well
>>>> with r=
>>>> ecent Fedora releases. I'd also *expect* those shims to be
>>>> workable for=
>>>> SL 7, but someone may have to plunk down some cash to get some keys
>>>> signed=
>>>> , and spend some extra effort to maintain the security needed for the
>>>> relev=
>>>> ant shims to work well with SL kernels and environments.<br>
>>>> </div></div><div class=3D"gmail_extra"><br><br><div
>>>> class=3D"gmail_quote">O=
>>>> n Tue, Sep 24, 2013 at 11:53 AM, Yasha Karant <span dir=3D"ltr"><<a
>>>> href=
>>>> =3D"mailto:[log in to unmask]"
>>>> target=3D"_blank">[log in to unmask]</a>></=
>>>> span> wrote:<br>
>>>> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
>>>> .8ex;border-left:1p=
>>>> x #ccc solid;padding-left:1ex">Secure boot is enabled. =A0Evidently,
>>>> the on=
>>>> ly means to disable secure boot requires that a secure boot
>>>> loader/configur=
>>>> ation program be running -- e.g., the MS proprietary boot loader
>>>> (typically=
>>>> , supplied as part of MS Windows 8) must be used to disable secure
>>>> boat if =
>>>> the UEFI actually permits this to be disabled (I have heard of some
>>>> UEFI im=
>>>> plementations that do not permit secure boot truly to be disabled).<br>
>>>>
>>>> <br>
>>>> If Linux cannot handle this issue, then Linux is finished on all
>>>> generic (e=
>>>> .g., not Apple that supplies both the hardware and operating
>>>> environment so=
>>>> ftware under a restrictive proprietary for-profit intellectual
>>>> property lic=
>>>> ense) X86-64 hardware, as (almost?) all current such hardware is MS 8
>>>> (UEFI=
>>>> secure boot) compliant.<br>
>>>>
>>>> <br>
>>>> Yasha Karant<br>
>>>> <br>
>>>> On 09/23/2013 10:29 PM, Connie Sieh wrote:<br>
>>>> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
>>>> .8ex;border-left:1p=
>>>> x #ccc solid;padding-left:1ex">
>>>> On Mon, 23 Sep 2013, Yasha Karant wrote:<br>
>>>> <br>
>>>> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
>>>> .8ex;border-left:1p=
>>>> x #ccc solid;padding-left:1ex">
>>>> A colleague who uses SuSE non-enterprise for his professional<br>
>>>> (enterprise) workstations has now attempted to load the latest SuSE on
>>>> a<br=
>>>>>
>>>> machine with a new generic (aftermarket) "gamer" UEFI
>>>> =A0X86-64<b=
>>>> r>
>>>> motherboard. =A0It does not properly boot. =A0I do not have any
>>>> UEFI<br>
>>>> motherboards, and thus no experience with SL6x on such
>>>> motherboards.<br>
>>>> </blockquote>
>>>> <br>
>>>> Is "secure boot" enabled in the UEFI ?<br>
>>>> <br>
>>>> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
>>>> .8ex;border-left:1p=
>>>> x #ccc solid;padding-left:1ex">
>>>> <br>
>>>> Does anyone? =A0Does SL6x boot correctly (and easily) on a UEFI<br>
>>>> motherboard? =A0If so, he may switch to SL.<br>
>>>> </blockquote>
>>>> <br>
>>>> Yes as long as "secure boot" is disabled .<br>
>>>> <br>
>>>> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
>>>> .8ex;border-left:1p=
>>>> x #ccc solid;padding-left:1ex">
>>>> <br>
>>>> Yasha Karant<br>
>>>> <br>
>>>> </blockquote>
>>>> <br>
>>>> -connie sieh<br>
>>>> </blockquote>
>>>> </blockquote></div><br></div>
>>>>
>>>> --001a11c379ecc5abcb04e7297e9d--
>>>>
>>
|
