SCIENTIFIC-LINUX-USERS Archives

September 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Tue, 24 Sep 2013 21:44:51 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (272 lines)
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 &quot;Palladium&quot; project from
>>> Micros=
>>> oft, relabeled as &quot;Trusted Computing&quot;. 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&#39;re already working well
>>> with r=
>>> ecent Fedora releases. I&#39;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">&lt;<a
>>> href=
>>> =3D"mailto:[log in to unmask]"
>>> target=3D"_blank">[log in to unmask]</a>&gt;</=
>>> 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) &quot;gamer&quot; 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 &quot;secure boot&quot; 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 &quot;secure boot&quot; 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--
>>>
>

ATOM RSS1 RSS2