[gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[William Kenworthy]

http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html

and something I had not considered with the whole idea was even bootable
cd's and usb keys for rescue will need the same privileges ...

BillK

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

Am 02.06.2012 04:26, schrieb William Kenworthy:
> http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html
> 
> and something I had not considered with the whole idea was even bootable
> cd's and usb keys for rescue will need the same privileges ...
> 
> BillK
> 
> 
> 
> 

I find this article lacking in substance. You get a much more reasonable
view reading the original blog post by Matthew Garrett [1].

A few points:
> "meaning that unless Microsoft has blessed your favorite flavor of
> GNU/Linux or BSD, you won't be able to just install it on your
> machine, or boot to it from a USB stick or CD to try it out."

You don't have to be "blessed". You could call your distribution
BallmerSucks and still get a certificate. You just have to register,
authenticate and pay the fee. Anything else would earn them an antitrust
law suite they wouldn't forget.

> "There is a work-around for some systems involving a finicky and
> highly technical override process, but all that means is that
> installing proprietary software is easy and installing free/open
> software is hard."

They mean "finicky" as in "go to the BIOS and switch it off" and "some
systems" as in "all x86 hardware but not ARM"? Yeah, the situation is
not nice but it is not as bad as it could be. Microsoft requires that it
can be switched off for x86. It forbids it for ARM, though. The article
gets that bit right.

Regarding the 99$ "ransom": It is a one-off payment. The article should
have made that clear.

Okay, enough bashing the article. Some technical question: As I
understand it, if I want to make a live CD or a distribution, all I'd
need to do is to use Fedora's kernel and boot loader? That's not so bad.

[1] http://mjg59.dreamwidth.org/12368.html

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[pk]

On 2012-06-02 09:43, Florian Philipp wrote:

> You don't have to be "blessed". You could call your distribution 
> BallmerSucks and still get a certificate. You just have to 
> register, authenticate and pay the fee. Anything else would earn 
> them an antitrust law suite they wouldn't forget.

... or one could simply replace the bios/UEFI with coreboot[1] and get
on with life... albeit, (at least currently) it will severely limit
your choice of motherboards (AMD is supporting coreboot, which is why
I've chosen AMD ones but it also requires the support of the
motherboard makers).

[1]: www.coreboot.org

Best regards

Peter K

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Sat, Jun 2, 2012 at 3:43 AM, Florian Philipp <lists@binarywings.net> wrote:
> Am 02.06.2012 04:26, schrieb William Kenworthy:
>> http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html
>>
>> and something I had not considered with the whole idea was even bootable
>> cd's and usb keys for rescue will need the same privileges ...

[snip]

> Okay, enough bashing the article. Some technical question: As I
> understand it, if I want to make a live CD or a distribution, all I'd
> need to do is to use Fedora's kernel and boot loader? That's not so bad.

Or turn off 'secure boot' in the BIOS configuration menu.

For Windows 8 certification, a device must _default_ to 'secure boot'
being turned on. You're allowed to turn it off, you just can't have
programmatic access to turn it off; it has to be done manually.

I expect that'll be available in things like motherboards sold
directly to end-users. I expect it *won't* be available in whatever
the current iteration of Compaq/HP/Packard Hell all-in-one devices is;
manufacturers of those devices will still have keys installed to allow
debugging and maintenance tools to operate, but their signed tools
would only be available to their certified technicians.

Does anyone know what crypto hash they're using to sign these things?
I imagine it won't be too long (3-4 years, tops) before either the
signing key leaks or collision attacks are figured out.

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

Am 02.06.2012 15:00, schrieb Michael Mol:
> On Sat, Jun 2, 2012 at 3:43 AM, Florian Philipp <lists@binarywings.net> wrote:
>> Am 02.06.2012 04:26, schrieb William Kenworthy:
>>> http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html
>>>
>>> and something I had not considered with the whole idea was even bootable
>>> cd's and usb keys for rescue will need the same privileges ...
> 
> [snip]
> 
>> Okay, enough bashing the article. Some technical question: As I
>> understand it, if I want to make a live CD or a distribution, all I'd
>> need to do is to use Fedora's kernel and boot loader? That's not so bad.
> 
> Or turn off 'secure boot' in the BIOS configuration menu.
> 
> For Windows 8 certification, a device must _default_ to 'secure boot'
> being turned on. You're allowed to turn it off, you just can't have
> programmatic access to turn it off; it has to be done manually.
>

Yes, that was my point (or part of it). The main issue is usability for
the technically not so inclined. For the typical Gentoo user secure boot
is not an issue is no more trouble than changing the boot order to boot
from CD-ROM. For mainstream distros like Ubuntu or Fedora, it is an
issue. But they can afford to spend 99$ *once* to just get a valid key.

> I expect that'll be available in things like motherboards sold
> directly to end-users. I expect it *won't* be available in whatever
> the current iteration of Compaq/HP/Packard Hell all-in-one devices is;
> manufacturers of those devices will still have keys installed to allow
> debugging and maintenance tools to operate, but their signed tools
> would only be available to their certified technicians.
> 

As I understand it, having the chance to deactivate it is now mandatory
for Windows certification but I could be wrong.

> Does anyone know what crypto hash they're using to sign these things?
> I imagine it won't be too long (3-4 years, tops) before either the
> signing key leaks or collision attacks are figured out.
> 

According to [1] it is SHA-256 and RSA-2048. If I understand it
correctly, there are means to blacklist compromised keys. That's why
Fedora cannot simply share their key but they will share their
infrastructure and tools.

[1] http://www.uefi.org/learning_center/UEFI_Plugfest_2011Q4_P5_Insyde.pdf

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[pk]

On 2012-06-02 15:12, Florian Philipp wrote:

> According to [1] it is SHA-256 and RSA-2048. If I understand it 
> correctly, there are means to blacklist compromised keys. That's
> why

Just curious, how is a "compromised" key supposed to be blacklisted?
Does the bios contact Microsoft, or is it through some other mean (via
OS which means it needs to have some sort of service to check for this
blacklist)? Smells like trouble to me... :-/

Best regards

Peter K

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Sat, Jun 2, 2012 at 3:51 PM, pk <peterk2@coolmail.se> wrote:
> On 2012-06-02 15:12, Florian Philipp wrote:
>
>> According to [1] it is SHA-256 and RSA-2048. If I understand it
>> correctly, there are means to blacklist compromised keys. That's
>> why
>
> Just curious, how is a "compromised" key supposed to be blacklisted?
> Does the bios contact Microsoft, or is it through some other mean (via
> OS which means it needs to have some sort of service to check for this
> blacklist)? Smells like trouble to me... :-/

I expect the chief mechanism is at the manufacturer's end; blacklisted
keys get included on shipment.

It's also probable that the OS kernel can tell the UEFI BIOS about new
keys to blacklist. I expect that'll be a recurring thing in the
Monthly batch of security updates Microsoft puts out. (Makes sense,
really; if malware is using a key, blacklist that key.)

Someone linked to some absolutely terrible stuff being built into
Intel's Ivy Bridge...it's plausible it will be possible to deploy
blacklist key updates over the network within a couple years.


-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[pk]

On 2012-06-02 22:10, Michael Mol wrote:

> I expect the chief mechanism is at the manufacturer's end; blacklisted
> keys get included on shipment.

Makes sense.

> It's also probable that the OS kernel can tell the UEFI BIOS about new
> keys to blacklist. I expect that'll be a recurring thing in the
> Monthly batch of security updates Microsoft puts out. (Makes sense,
> really; if malware is using a key, blacklist that key.)

Yes, would expect something like this. Secure boot supposedly prevents
"unauthorized firmware, operating systems or UEFI drivers" at boot time.
So if I interpret this correctly it would mean that if I have, say, an
old graphics card with an old firmware (vga bios) I can't use it with
"secure boot". More interestingly, how is an "operating system" defined?
Does it mean only the kernel itself or does it mean a full-blown OS with
init and other supporting software? What does that mean to a source
based "distro"? Also, I would assume a legitimate key would be able to
sign pretty much any binary so a key that Fedora uses could be used to
sign malware for Windows, which then would be blacklisted by
Microsoft... and how is malware defined? Anything that would be
detrimental to Microsoft?

> Someone linked to some absolutely terrible stuff being built into
> Intel's Ivy Bridge...it's plausible it will be possible to deploy

You mean:
https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-control

?

> blacklist key updates over the network within a couple years.

Well, UEFI already implements remote management:
http://www.uefi.org/news/UEFI_Overview.pdf (page 13)
... so implementing an automatic update over the network, preferably via
SMM/SMI so that the operating system cannot intervene would be possible
already today... and you've lost control of your computer.

I'm putting on my tinfoil hat now and I'm going to pretend it's
raining... :-/

Best regards

Peter K

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Sat, Jun 2, 2012 at 6:50 PM, pk <peterk2@coolmail.se> wrote:
> On 2012-06-02 22:10, Michael Mol wrote:

[snip]

>> It's also probable that the OS kernel can tell the UEFI BIOS about new
>> keys to blacklist. I expect that'll be a recurring thing in the
>> Monthly batch of security updates Microsoft puts out. (Makes sense,
>> really; if malware is using a key, blacklist that key.)
>
> Yes, would expect something like this. Secure boot supposedly prevents
> "unauthorized firmware, operating systems or UEFI drivers" at boot time.
> So if I interpret this correctly it would mean that if I have, say, an
> old graphics card with an old firmware (vga bios) I can't use it with
> "secure boot".

It's probable that a system using an IOMMU and virtualization tech
could emulate the real-mode requirements needed to execute that VGA
BIOS safely.

Gets more interesting...my understanding of things like Firewire is
that it's almost trivially easy to crack a system on the bus, because
of the way DMA is implemented.

> More interestingly, how is an "operating system" defined?
> Does it mean only the kernel itself or does it mean a full-blown OS with
> init and other supporting software?

The BIOS will only load a signed bootloader. The signed bootloader
will only load a signed kernel. The signed kernel will...do whatever
you tell it to do.

> What does that mean to a source based "distro"?

It's going to make building and installing grub and the kernel
trickier; you'll have to get them signed. And that's going to be a
PITA for anyone who does developers.

What it *really* means is that someone who wants to run Linux as a
hobbyist or developer is going to disable "SecureBoot", and then fall
back to business as usual.

> Also, I would assume a legitimate key would be able to
> sign pretty much any binary so a key that Fedora uses could be used to
> sign malware for Windows, which then would be blacklisted by
> Microsoft...

If Fedora allows their key to sign crap, then their key will get revoked.

What I hope (I don't know) is whether or not the signing system
involved allows chaining.  i.e., with SSL, I can generate my own key,
get it signed by a CA, and then bundle the CA's public key and my
public key when I go on to sign _another_ key.

So, could I generate a key, have Fedora sign it, and then use my key
to sign my binaries? If my key is used to do malicious things,
Fedora's off the hook, and it's only my key which gets revoked.

> and how is malware defined? Anything that would be
> detrimental to Microsoft?

Dunno. I imagine it comes down to whatever the chief key's owner
doesn't want running on the same hardware while SecureBoot is enabled.
Rootkits come to mind.

>
>> Someone linked to some absolutely terrible stuff being built into
>> Intel's Ivy Bridge...it's plausible it will be possible to deploy
>
> You mean:
> https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-control
>
> ?

The vPro stuff relates, yeah.

>
>> blacklist key updates over the network within a couple years.
>
> Well, UEFI already implements remote management:
> http://www.uefi.org/news/UEFI_Overview.pdf (page 13)
> ... so implementing an automatic update over the network, preferably via
> SMM/SMI so that the operating system cannot intervene would be possible
> already today... and you've lost control of your computer.

You still own your network, so you have at least some control over it.
These features are intended to be managed by the system network
administrator.

This is going to be a matter of caveat emptor. Don't buy a Tivo or
Kindle and expect to be able to repurpose it. (And don't buy hardware
from Oracle, I expect. Though I suspect you may eventually not get a
choice is you want to run their software.)

If you don't know whether or not you can expect to reformat a device
before you buy it, then you haven't been paying attention to mobile
tech over the last five years, and you didn't do your homework.
Apologies for the lack of sympathy. :(

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]

Am 03.06.2012 01:36, schrieb Michael Mol:
> On Sat, Jun 2, 2012 at 6:50 PM, pk <peterk2@coolmail.se> wrote:
>> On 2012-06-02 22:10, Michael Mol wrote:
> 
> [snip]
> 
[...]
> 
> The BIOS will only load a signed bootloader. The signed bootloader
> will only load a signed kernel. The signed kernel will...do whatever
> you tell it to do.
> 

According to Matthew's blog post, Fedora patched Grub2 and the kernel to
avoid loading custom code into them:
- Deactivate grub2 plugins
- Sign all kernel modules and disallow unsigned ones
- Prevent access to PCI through userland
- Sanitize the kernel command line

>> What does that mean to a source based "distro"?
> 
> It's going to make building and installing grub and the kernel
> trickier; you'll have to get them signed. And that's going to be a
> PITA for anyone who does developers.
> 
> What it *really* means is that someone who wants to run Linux as a
> hobbyist or developer is going to disable "SecureBoot", and then fall
> back to business as usual.
> 

Yeah, the only way for Gentoo to have secure boot is a) let each user
register with Microsoft, b) provide a binary kernel and boot loader.

>> Also, I would assume a legitimate key would be able to
>> sign pretty much any binary so a key that Fedora uses could be used to
>> sign malware for Windows, which then would be blacklisted by
>> Microsoft...
> 
> If Fedora allows their key to sign crap, then their key will get revoked.
> 
> What I hope (I don't know) is whether or not the signing system
> involved allows chaining.  i.e., with SSL, I can generate my own key,
> get it signed by a CA, and then bundle the CA's public key and my
> public key when I go on to sign _another_ key.
> 
> So, could I generate a key, have Fedora sign it, and then use my key
> to sign my binaries? If my key is used to do malicious things,
> Fedora's off the hook, and it's only my key which gets revoked.
> 

Consider the exact approach Fedora takes: They've only made a certified
stage-1 boot loader. This boot loader then loads grub2 (signed with a
custom Fedora key, nothing chained back to MS) which then loads a
custom-signed kernel. This allows them to avoid authenticating against
MS every time they update grub or the kernel.

This means if you want to certify with Fedora, you don't need to chain
up to MS as long as you use their stage-1 boot loader. However, if I was
part of Fedora, I wouldn't risk my key by signing other people's stuff.
Mainboard makers won't look twice when they see rootkits with Fedora
boot loaders.

>> and how is malware defined? Anything that would be
>> detrimental to Microsoft?
> 
> Dunno. I imagine it comes down to whatever the chief key's owner
> doesn't want running on the same hardware while SecureBoot is enabled.
> Rootkits come to mind.
> 

To quote Matthew:
> If I take a signed Linux bootloader and then use it to boot something
> that looks like an unsigned Linux kernel, I've instead potentially
> just booted a piece of malware. And if that malware can attack
> Windows then the signed Linux bootloader is no longer just a signed
> Linux bootloader, it's a signed Windows malware launcher and that's
> the kind of thing that results in that bootloader being added to the
> list of blacklisted binaries and suddenly your signed Linux
> bootloader isn't even a signed Linux bootloader.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Sat, Jun 2, 2012 at 8:35 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 03.06.2012 01:36, schrieb Michael Mol:
>> On Sat, Jun 2, 2012 at 6:50 PM, pk <peterk2@coolmail.se> wrote:
>>> On 2012-06-02 22:10, Michael Mol wrote:
>>
>> [snip]
>>
> [...]
>>
>> The BIOS will only load a signed bootloader. The signed bootloader
>> will only load a signed kernel. The signed kernel will...do whatever
>> you tell it to do.
>>
>
> According to Matthew's blog post, Fedora patched Grub2 and the kernel to
> avoid loading custom code into them:
> - Deactivate grub2 plugins
> - Sign all kernel modules and disallow unsigned ones
> - Prevent access to PCI through userland
> - Sanitize the kernel command line

Yeah, I read his blog post via lwn.net. I forgot some of the details.


>
>>> What does that mean to a source based "distro"?
>>
>> It's going to make building and installing grub and the kernel
>> trickier; you'll have to get them signed. And that's going to be a
>> PITA for anyone who does developers.
>>
>> What it *really* means is that someone who wants to run Linux as a
>> hobbyist or developer is going to disable "SecureBoot", and then fall
>> back to business as usual.
>>
>
> Yeah, the only way for Gentoo to have secure boot is a) let each user
> register with Microsoft, b) provide a binary kernel and boot loader.

If you have a need to get a secure Gentoo boot, and you don't need to
boot Windows 8, then (as I understand it) you can also purge the UEFI
BIOS of Microsoft's key and install your own.

>
>>> Also, I would assume a legitimate key would be able to
>>> sign pretty much any binary so a key that Fedora uses could be used to
>>> sign malware for Windows, which then would be blacklisted by
>>> Microsoft...
>>
>> If Fedora allows their key to sign crap, then their key will get revoked.
>>
>> What I hope (I don't know) is whether or not the signing system
>> involved allows chaining.  i.e., with SSL, I can generate my own key,
>> get it signed by a CA, and then bundle the CA's public key and my
>> public key when I go on to sign _another_ key.
>>
>> So, could I generate a key, have Fedora sign it, and then use my key
>> to sign my binaries? If my key is used to do malicious things,
>> Fedora's off the hook, and it's only my key which gets revoked.
>>
>
> Consider the exact approach Fedora takes: They've only made a certified
> stage-1 boot loader. This boot loader then loads grub2 (signed with a
> custom Fedora key, nothing chained back to MS) which then loads a
> custom-signed kernel. This allows them to avoid authenticating against
> MS every time they update grub or the kernel.
>
> This means if you want to certify with Fedora, you don't need to chain
> up to MS as long as you use their stage-1 boot loader. However, if I was
> part of Fedora, I wouldn't risk my key by signing other people's stuff.
> Mainboard makers won't look twice when they see rootkits with Fedora
> boot loaders.

Yeah, that's not the kind of thing I was thinking about.

With SSL's PKI, someone like StartSSL has a CA cert.

I generate my own key, have StartSSL sign my key. My brother generates
a key, and I sign his.

Now my brother takes his key and sends you a signed email.

Now, you've never heard of me, and the crypto signature attached to
that email doesn't mean anything. However, if he bundles my public key
along with his public key in that email, then you can see that my
public key was signed by someone you _do_ know. Now you have a chain
of signatures showing the relationship between that email and the root
CA.

Now here's the interesting part, and what I was alluding to wrt signed
binaries and key revocation.

Let's say _my_ key is leaked. My brother send you an email signed with
his key. You look at that key, you see that key hasn't been revoked.
You look at the key that signed that key, and you see that _that_ key
_has_ been revoked. You can then choose to not trust keys signed by
that key.

Now let's say my _brother's_ key is leaked, and so he revokes it. Any
new emails signed with that key can be seen to be invalid. However,
_my_ key is still considered valid; I can still sign things with it.

That's the kind of thing I was thinking about. If you allow key chains
to be deep, rather than forcing them to be wide, you can wield
blacklists like a scalpel, rather than a bludgeon.

>
>>> and how is malware defined? Anything that would be
>>> detrimental to Microsoft?
>>
>> Dunno. I imagine it comes down to whatever the chief key's owner
>> doesn't want running on the same hardware while SecureBoot is enabled.
>> Rootkits come to mind.
>>
>
> To quote Matthew:
>> If I take a signed Linux bootloader and then use it to boot something
>> that looks like an unsigned Linux kernel, I've instead potentially
>> just booted a piece of malware. And if that malware can attack
>> Windows then the signed Linux bootloader is no longer just a signed
>> Linux bootloader, it's a signed Windows malware launcher and that's
>> the kind of thing that results in that bootloader being added to the
>> list of blacklisted binaries and suddenly your signed Linux
>> bootloader isn't even a signed Linux bootloader.

What kind of signature is the bootloader checking, anyway?

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[BRM]

> From: Michael Mol <mikemol@gmail.com>

> On Sat, Jun 2, 2012 at 8:35 PM, Florian Philipp <lists@binarywings.net> 
> wrote:
>>  Am 03.06.2012 01:36, schrieb Michael Mol:
>>>  On Sat, Jun 2, 2012 at 6:50 PM, pk <peterk2@coolmail.se> wrote:
>>>>  On 2012-06-02 22:10, Michael Mol wrote:
>>> 
>>>  [snip]
>>> 
>>  [...]
>>> 
>>>  The BIOS will only load a signed bootloader. The signed bootloader
>>>  will only load a signed kernel. The signed kernel will...do whatever
>>>  you tell it to do.
>>> 
>> 
>>  According to Matthew's blog post, Fedora patched Grub2 and the kernel 
> to
>>  avoid loading custom code into them:
>>  - Deactivate grub2 plugins
>>  - Sign all kernel modules and disallow unsigned ones
>>  - Prevent access to PCI through userland
>>  - Sanitize the kernel command line
> 
> Yeah, I read his blog post via lwn.net. I forgot some of the details.
> 
> 
>> 
>>>>  What does that mean to a source based "distro"?
>>> 
>>>  It's going to make building and installing grub and the kernel
>>>  trickier; you'll have to get them signed. And that's going to 
> be a
>>>  PITA for anyone who does developers.
>>> 
>>>  What it *really* means is that someone who wants to run Linux as a
>>>  hobbyist or developer is going to disable "SecureBoot", and 
> then fall
>>>  back to business as usual.
>>> 
>> 
>>  Yeah, the only way for Gentoo to have secure boot is a) let each user
>>  register with Microsoft, b) provide a binary kernel and boot loader.
> 
> If you have a need to get a secure Gentoo boot, and you don't need to
> boot Windows 8, then (as I understand it) you can also purge the UEFI
> BIOS of Microsoft's key and install your own.

well, on x86 for now...

> 
>> 
>>>>  Also, I would assume a legitimate key would be able to
>>>>  sign pretty much any binary so a key that Fedora uses could be used 
> to
>>>>  sign malware for Windows, which then would be blacklisted by
>>>>  Microsoft...
>>> 
>>>  If Fedora allows their key to sign crap, then their key will get 
> revoked.
>>> 
>>>  What I hope (I don't know) is whether or not the signing system
>>>  involved allows chaining.  i.e., with SSL, I can generate my own key,
>>>  get it signed by a CA, and then bundle the CA's public key and my
>>>  public key when I go on to sign _another_ key.
>>> 
>>>  So, could I generate a key, have Fedora sign it, and then use my key
>>>  to sign my binaries? If my key is used to do malicious things,
>>>  Fedora's off the hook, and it's only my key which gets revoked.
>>> 
>> 
>>  Consider the exact approach Fedora takes: They've only made a certified
>>  stage-1 boot loader. This boot loader then loads grub2 (signed with a
>>  custom Fedora key, nothing chained back to MS) which then loads a
>>  custom-signed kernel. This allows them to avoid authenticating against
>>  MS every time they update grub or the kernel.
>> 
>>  This means if you want to certify with Fedora, you don't need to chain
>>  up to MS as long as you use their stage-1 boot loader. However, if I was
>>  part of Fedora, I wouldn't risk my key by signing other people's 
> stuff.
>>  Mainboard makers won't look twice when they see rootkits with Fedora
>>  boot loaders.
> 
> Yeah, that's not the kind of thing I was thinking about.
> 
> With SSL's PKI, someone like StartSSL has a CA cert.
> 
> I generate my own key, have StartSSL sign my key. My brother generates
> a key, and I sign his.
> 
> Now my brother takes his key and sends you a signed email.
> 
> Now, you've never heard of me, and the crypto signature attached to
> that email doesn't mean anything. However, if he bundles my public key
> along with his public key in that email, then you can see that my
> public key was signed by someone you _do_ know. Now you have a chain
> of signatures showing the relationship between that email and the root
> CA.
> 
> Now here's the interesting part, and what I was alluding to wrt signed
> binaries and key revocation.
> 
> Let's say _my_ key is leaked. My brother send you an email signed with
> his key. You look at that key, you see that key hasn't been revoked.
> You look at the key that signed that key, and you see that _that_ key
> _has_ been revoked. You can then choose to not trust keys signed by
> that key.
> 
> Now let's say my _brother's_ key is leaked, and so he revokes it. Any
> new emails signed with that key can be seen to be invalid. However,
> _my_ key is still considered valid; I can still sign things with it.
> 
> That's the kind of thing I was thinking about. If you allow key chains
> to be deep, rather than forcing them to be wide, you can wield
> blacklists like a scalpel, rather than a bludgeon.

In theory that's how key signing systems are suppose to work.
In practice, they rarely implement the blacklists as they are (i) hard to maintain,
and (ii) hard to distribute in an effective manner.

Honestly, I don't expect SecureBoot to last very long.
Either MS and the OEMs will be forced to always allow users to disable it,
or they'll be simply drop it - kind of like they did with TPM requirements that were
talked about 10 years back and never came to fruition.

>>>>  and how is malware defined? Anything that would be
>>>>  detrimental to Microsoft?
>>> 
>>>  Dunno. I imagine it comes down to whatever the chief key's owner
>>>  doesn't want running on the same hardware while SecureBoot is enabled.
>>>  Rootkits come to mind.
>>> 
>> 
>>  To quote Matthew:
>>>  If I take a signed Linux bootloader and then use it to boot something
>>>  that looks like an unsigned Linux kernel, I've instead potentially
>>>  just booted a piece of malware. And if that malware can attack
>>>  Windows then the signed Linux bootloader is no longer just a signed
>>>  Linux bootloader, it's a signed Windows malware launcher and 
> that's
>>>  the kind of thing that results in that bootloader being added to the
>>>  list of blacklisted binaries and suddenly your signed Linux
>>>  bootloader isn't even a signed Linux bootloader.
> 
> What kind of signature is the bootloader checking, anyway?

Regardless of the check, it'll never be sufficient.

Ben

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>> From: Michael Mol <mikemol@gmail.com>
>

[snip]

>
> In theory that's how key signing systems are suppose to work.
> In practice, they rarely implement the blacklists as they are (i) hard to maintain,
> and (ii) hard to distribute in an effective manner.

Indeed. While Firefox, Chromium, et al check certificate revocation
lists, Microsoft doesn't; they distribute them as part of Windows
Update.

>
> Honestly, I don't expect SecureBoot to last very long.
> Either MS and the OEMs will be forced to always allow users to disable it,
> or they'll be simply drop it - kind of like they did with TPM requirements that were
> talked about 10 years back and never came to fruition.

TPM is still around for organizations which can use them. And,
honestly, I've been annoyed that they haven't been widespread, nor
easy to pick up in the aftermarket. (They come with a random number
generator...just about any HRNG is going to be better than none.)

I see something like SecureBoot as being useful in corporate and
military security contexts. I don't see it lasting in SOHO
environments.

[snip]

>> What kind of signature is the bootloader checking, anyway?
>
> Regardless of the check, it'll never be sufficient.

Sure; ultimately, all DRM solutions get cracked.

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[BRM]

> From: Michael Mol <mikemol@gmail.com>

>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>>> From: Michael Mol <mikemol@gmail.com>
>[snip]
>> In theory that's how key signing systems are suppose to work.
>> In practice, they rarely implement the blacklists as they are (i) hard to maintain,
>> and (ii) hard to distribute in an effective manner.
>
>Indeed. While Firefox, Chromium, et al check certificate revocation
>lists, Microsoft doesn't; they distribute them as part of Windows
>Update.


Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers.


>> Honestly, I don't expect SecureBoot to last very long.
>> Either MS and the OEMs will be forced to always allow users to disable it,
>> or they'll be simply drop it - kind of like they did with TPM requirements that were
>> talked about 10 years back and never came to fruition.
>
>TPM is still around for organizations which can use them. And,
>honestly, I've been annoyed that they haven't been widespread, nor
>easy to pick up in the aftermarket. (They come with a random number
>generator...just about any HRNG is going to be better than none.)


Yes TPM (originally named Palladium) is still around. However its use is almost non-existent.
When it was proposed, it was to include "SecureBoot" and enable secure Internet transactions, etc.
None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot.


>I see something like SecureBoot as being useful in corporate and
>military security contexts. I don't see it lasting in SOHO
>environments.


Certain environments as you say may find it useful; but then those environments already have very stringent controls
over the computers in those environments, often to the inability of people to do their job.


>[snip]
>>> What kind of signature is the bootloader checking, anyway?
>> Regardless of the check, it'll never be sufficient.
>Sure; ultimately, all DRM solutions get cracked.


TPM and SecureBoot will by design fail.
We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur.

Ben

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
>> From: Michael Mol <mikemol@gmail.com>
>
>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>>>> From: Michael Mol <mikemol@gmail.com>
>>[snip]
>>> In theory that's how key signing systems are suppose to work.
>>> In practice, they rarely implement the blacklists as they are (i) hard to maintain,
>>> and (ii) hard to distribute in an effective manner.
>>
>>Indeed. While Firefox, Chromium, et al check certificate revocation
>>lists, Microsoft doesn't; they distribute them as part of Windows
>>Update.
>
> Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers.

Only if the workstation is so configured. (i.e. it's joined to the
domain, or has otherwise had configuration placed on it.) It's not
just a matter of setting up a caching proxy server and modifying the
files before they're delivered.

And if you think that's a risk, then consider that your local domain
administrator has the ability to push out the organization CA into
your system cert store as a trusted CA, and can then go on to create
global certs your browser won't complain about.

If you don't own the network, don't expect to be able to do things on
it that the network administrator doesn't want you to do. At the same
time, he can't force (much...see DHCP) configuration onto your machine
without your being aware, at least if you're at least somewhat
responsible in knowing how configuring your machine works.


>>> Honestly, I don't expect SecureBoot to last very long.
>>> Either MS and the OEMs will be forced to always allow users to disable it,
>>> or they'll be simply drop it - kind of like they did with TPM requirements that were
>>> talked about 10 years back and never came to fruition.
>>
>>TPM is still around for organizations which can use them. And,
>>honestly, I've been annoyed that they haven't been widespread, nor
>>easy to pick up in the aftermarket. (They come with a random number
>>generator...just about any HRNG is going to be better than none.)
>
>
> Yes TPM (originally named Palladium) is still around. However its use is almost non-existent.

No, TPM wasn't originally named Palladium. TPM was the keystore
hardware component of a broader system named Palladium. The TPM is
just a keystore and a crypto accelerator, both of which are two things
valuable to _everybody_. The massive backlash against Palladium is at
least part of why even a generally useful hardware component like the
TPM never got distributed. Imagine if the floating-point coprocessor
was ditched in x86 because people thought it was a conspiracy  to
induce difficult-to-resolve math precision errors from careless use of
floating point arithmetic.

The part you're worried about is the curtained memory and hardware
lockout, which it sounds like Intel is distributing with vPro.

> When it was proposed, it was to include "SecureBoot" and enable secure Internet transactions, etc.
> None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot.
>
>
>>I see something like SecureBoot as being useful in corporate and
>>military security contexts. I don't see it lasting in SOHO
>>environments.
>
>
> Certain environments as you say may find it useful; but then those environments already have very stringent controls
> over the computers in those environments, often to the inability of people to do their job.

The nature of those controls stems at least in part from the ability
to use other means to maintain an overall security policy. With more
tools comes the ability to be more flexible, allowing people to do
more convenient convenient things (such as insert a flash drive or CD
into a computer) at lower risk (it'll be more difficult to
accidentally boot from that flash drive or CD).

It's for similar reasons the Linux kernel has support for fine-grained
access controls; you can grant additional privileges where needed, and
reduce the base set of privileges required.

And here's a use case that might seem worthwhile...Say you've got
hardware with SecureBoot. Now, you don't run Windows, so you don't
care about the UEFI BIOS having Microsoft's key. Instead, you're a
Linux guy, and you're very privacy conscious; perhaps you're a
security consultant or contractor. Or perhaps you're worried about
corporate espionage. Or perhaps you're simply afraid of governments.

You can flush Microsoft's key from BIOS and insert your own. Sign your
bootloader, kernel and initramfs. Set up your / filesystem to be fully
encrypted. And configure things such that if BIOS isn't operating in
SecureBoot mode with your key, it won't even mount and decrypt your /
filesystem.

You've just denied access to any existing forensic tool which would
either examine your hard disk or operate as a rootkit. The only thing
that's going to get your data is a live inspection of your RAM
(tricky! but doable.) or a rubber hose.

>>>> What kind of signature is the bootloader checking, anyway?
>>> Regardless of the check, it'll never be sufficient.
>>Sure; ultimately, all DRM solutions get cracked.
>
> TPM and SecureBoot will by design fail.

Please be aware of the distinction between TPM from Palladium. In
fact, you should probably be aware of the distinction between tools
and policies, too.

> We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur.

We'll see. Don't forget _you can turn the thing off_. I expect the
lawsuits will come around when the ability to turn the thing off or
reconfigure it is removed.

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[BRM]

> From: Michael Mol <mikemol@gmail.com>

>On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
>>> From: Michael Mol <mikemol@gmail.com>
>>
>>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>>>>> From: Michael Mol <mikemol@gmail.com>
>>>[snip]
>>>> In theory that's how key signing systems are suppose to work.
>>>> In practice, they rarely implement the blacklists as they are (i) hard to maintain,
>>>> and (ii) hard to distribute in an effective manner.
>>>
>>>Indeed. While Firefox, Chromium, et al check certificate revocation
>>>lists, Microsoft doesn't; they distribute them as part of Windows
>>>Update.
>>
>> Which can then be intercepted by IT in any IT department that stages Windows Update using their own servers.
>
>Only if the workstation is so configured. (i.e. it's joined to the
>domain, or has otherwise had configuration placed on it.) It's not
>just a matter of setting up a caching proxy server and modifying the
>files before they're delivered.
>
>And if you think that's a risk, then consider that your local domain
>administrator has the ability to push out the organization CA into
>your system cert store as a trusted CA, and can then go on to create
>global certs your browser won't complain about.
>
>If you don't own the network, don't expect to be able to do things on
>it that the network administrator doesn't want you to do. At the same
>time, he can't force (much...see DHCP) configuration onto your machine
>without your being aware, at least if you're at least somewhat
>responsible in knowing how configuring your machine works.


True.

My point was that since Microsoft is using Windows Update to update the CRLs, that the corporate IT departments could decide not to allow the update to go through.
Of course, it's their risk if they don't allow it through. Further, they can push out CRLs even if Microsoft doesn't send them.

But that's not the concern unless you want your device free of the IT department, and that's a wholly different issue.
And of course, they can't change the CA on a WinRT device for SecureBoot.

>>>> Honestly, I don't expect SecureBoot to last very long.
>>>> Either MS and the OEMs will be forced to always allow users to disable it,
>>>> or they'll be simply drop it - kind of like they did with TPM requirements that were
>>>> talked about 10 years back and never came to fruition.
>>>
>>>TPM is still around for organizations which can use them. And,
>>>honestly, I've been annoyed that they haven't been widespread, nor
>>>easy to pick up in the aftermarket. (They come with a random number
>>>generator...just about any HRNG is going to be better than none.)
>>
>>
>> Yes TPM (originally named Palladium) is still around. However its use is almost non-existent.
>
>No, TPM wasn't originally named Palladium. TPM was the keystore
>hardware component of a broader system named Palladium. The TPM is
>just a keystore and a crypto accelerator, both of which are two things
>valuable to _everybody_. The massive backlash against Palladium is at
>least part of why even a generally useful hardware component like the
>TPM never got distributed. Imagine if the floating-point coprocessor
>was ditched in x86 because people thought it was a conspiracy  to
>induce difficult-to-resolve math precision errors from careless use of
>floating point arithmetic.
>
>The part you're worried about is the curtained memory and hardware
>lockout, which it sounds like Intel is distributing with vPro.


TPM, SecureBoot, and Palladium are both beasts which need to be removed.


>> When it was proposed, it was to include "SecureBoot" and enable secure Internet transactions, etc.
>> None of that came to fruition. Now, after over a decade of ignoring it, they are trying it one step at a time, first with SecureBoot.
>>>I see something like SecureBoot as being useful in corporate and
>>>military security contexts. I don't see it lasting in SOHO
>>>environments.
>> Certain environments as you say may find it useful; but then those environments already have very stringent controls
>> over the computers in those environments, often to the inability of people to do their job.
>
>The nature of those controls stems at least in part from the ability
>to use other means to maintain an overall security policy. With more
>tools comes the ability to be more flexible, allowing people to do
>more convenient convenient things (such as insert a flash drive or CD
>into a computer) at lower risk (it'll be more difficult to
>accidentally boot from that flash drive or CD).


How often do people accidentally boot from the wrong device?
It's probably more of an issue for USB devices than floppy/CDs any more, but still.

And why destroy people's ability to boot from USB/CD/Floppy?
Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices.

The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place).


>It's for similar reasons the Linux kernel has support for fine-grained
>access controls; you can grant additional privileges where needed, and
>reduce the base set of privileges required.


Linux has fine grain control because that's what's required for Common Criteria, and what the NSA implemented for SELinux.

>And here's a use case that might seem worthwhile...Say you've got
>hardware with SecureBoot. Now, you don't run Windows, so you don't
>care about the UEFI BIOS having Microsoft's key. Instead, you're a
>Linux guy, and you're very privacy conscious; perhaps you're a
>security consultant or contractor. Or perhaps you're worried about
>corporate espionage. Or perhaps you're simply afraid of governments.
>
>You can flush Microsoft's key from BIOS and insert your own. Sign your
>bootloader, kernel and initramfs. Set up your / filesystem to be fully
>encrypted. And configure things such that if BIOS isn't operating in
>SecureBoot mode with your key, it won't even mount and decrypt your /
>filesystem.
>
>You've just denied access to any existing forensic tool which would
>either examine your hard disk or operate as a rootkit. The only thing
>that's going to get your data is a live inspection of your RAM
>(tricky! but doable.) or a rubber hose.


Or you just pull the hard drive and do the decryption elsewhere.
All it does is lock you out of your own system, and hand the keys to someone else.

And, on WinRT approved devices you will not be allowed to change the Keys for SecureBoot period (not even corporate IT).
On x86-based Windows devices you'll be allowed to, but it's only a matter of time before Microsoft will try to pull the plug there too.


>>>>> What kind of signature is the bootloader checking, anyway?
>>>> Regardless of the check, it'll never be sufficient.
>>>Sure; ultimately, all DRM solutions get cracked.
>>
>> TPM and SecureBoot will by design fail.
>
>Please be aware of the distinction between TPM from Palladium. In
>fact, you should probably be aware of the distinction between tools
>and policies, too.


That won't resolve the issue.


>> We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur.
>
>We'll see. Don't forget _you can turn the thing off_. I expect the
>lawsuits will come around when the ability to turn the thing off or
>reconfigure it is removed.


As noted, WinRT devices will not allow you to change the keys; they also won't allow you to turn off Secure Boot.
If MS can get SecureBoot out there and keep it enabled, then it's just a matter of time before they try to do the same thing to the rest of the platforms.
So expect the lawsuits to happen if it even gets out to start with.


Ben

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Mon, Jun 4, 2012 at 5:13 PM, BRM <bm_witness@yahoo.com> wrote:
>> From: Michael Mol <mikemol@gmail.com>
>
>>On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
>>>> From: Michael Mol <mikemol@gmail.com>
>>>
>>>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>>>>>> From: Michael Mol <mikemol@gmail.com>

[snip]

>>>>> Honestly, I don't expect SecureBoot to last very long.
>>>>> Either MS and the OEMs will be forced to always allow users to disable it,
>>>>> or they'll be simply drop it - kind of like they did with TPM requirements that were
>>>>> talked about 10 years back and never came to fruition.
>>>>
>>>>TPM is still around for organizations which can use them. And,
>>>>honestly, I've been annoyed that they haven't been widespread, nor
>>>>easy to pick up in the aftermarket. (They come with a random number
>>>>generator...just about any HRNG is going to be better than none.)
>>>
>>>
>>> Yes TPM (originally named Palladium) is still around. However its use is almost non-existent.
>>
>>No, TPM wasn't originally named Palladium. TPM was the keystore
>>hardware component of a broader system named Palladium. The TPM is
>>just a keystore and a crypto accelerator, both of which are two things
>>valuable to _everybody_. The massive backlash against Palladium is at
>>least part of why even a generally useful hardware component like the
>>TPM never got distributed. Imagine if the floating-point coprocessor
>>was ditched in x86 because people thought it was a conspiracy  to
>>induce difficult-to-resolve math precision errors from careless use of
>>floating point arithmetic.
>>
>>The part you're worried about is the curtained memory and hardware
>>lockout, which it sounds like Intel is distributing with vPro.
>
>
> TPM, SecureBoot, and Palladium are both beasts which need to be removed.

I'm still confused by your malice toward the TPM. What part of 'crypto
coprocessor' or 'crypto accelerator' doesn't get you thinking about
faster SSH and SSL connection setup and data transfers?

[snip]

>>The nature of those controls stems at least in part from the ability
>>to use other means to maintain an overall security policy. With more
>>tools comes the ability to be more flexible, allowing people to do
>>more convenient convenient things (such as insert a flash drive or CD
>>into a computer) at lower risk (it'll be more difficult to
>>accidentally boot from that flash drive or CD).
>
>
> How often do people accidentally boot from the wrong device?

You know how many Linux install flash drives are floating around? What
about OS install CDs? A curious artifact of both is that they're left
in systems so _frequently_, they're often designed to proceed back to
a disk-based boot after a timeout.

> It's probably more of an issue for USB devices than floppy/CDs any more, but still.

The Gentoo 12.1 LiveDVD also has the timeout-and-boot. And it's quite
common for people to leave flash drives plugged into systems over boot
cycles; it's like a portable 'My Documents' folder.

>
> And why destroy people's ability to boot from USB/CD/Floppy?

You're not; you can turn off SecureBoot in BIOS, and then boot from
USB or CD as normal. Though why you'd boot from a floppy on a system
that has SecureBoot, I have no idea. (It's questionable whether
systems shipping SecureBoot will even have floppy controllers...)

Being able to disable SecureBoot is going to be _critical_ for
application of diagnostics, forensics and system repair. And if it
comes down to it, you'll likely be able to get those tools signed,
too.

> Let's not forget this makes it harder for Gentoo (and numerous other distros and OSes) to go on devices.

Nobody's forgotten that. Now let's not forget how easy it will be to
turn SecureBoot off. You're likely to have a harder time getting
latest-grade RAM functioning in a brand-new new system, what with
timings and gang modes to contend with.

> The user should own and control the device, not a corporate entity (except where said corporate entity purchased the device in the first place).

Fully concur...and I'm moderately impressed; most people I've seen
argue things like this can't make that distinction.

>>It's for similar reasons the Linux kernel has support for fine-grained
>>access controls; you can grant additional privileges where needed, and
>>reduce the base set of privileges required.
>
>
> Linux has fine grain control because that's what's required for Common Criteria, and what the NSA implemented for SELinux.

SELinux required it because it was necessary. Linux included SELinux
because it's legitimately useful. Anything legitimately useful for
someone else to keep you out of their stuff is legitimately useful for
you to keep them out of yours.

>>And here's a use case that might seem worthwhile...Say you've got
>>hardware with SecureBoot. Now, you don't run Windows, so you don't
>>care about the UEFI BIOS having Microsoft's key. Instead, you're a
>>Linux guy, and you're very privacy conscious; perhaps you're a
>>security consultant or contractor. Or perhaps you're worried about
>>corporate espionage. Or perhaps you're simply afraid of governments.
>>
>>You can flush Microsoft's key from BIOS and insert your own. Sign your
>>bootloader, kernel and initramfs. Set up your / filesystem to be fully
>>encrypted. And configure things such that if BIOS isn't operating in
>>SecureBoot mode with your key, it won't even mount and decrypt your /
>>filesystem.
>>
>>You've just denied access to any existing forensic tool which would
>>either examine your hard disk or operate as a rootkit. The only thing
>>that's going to get your data is a live inspection of your RAM
>>(tricky! but doable.) or a rubber hose.
>
>
> Or you just pull the hard drive and do the decryption elsewhere.

Decryption is not trivial.

> All it does is lock you out of your own system, and hand the keys to someone else.
>
> And, on WinRT approved devices you will not be allowed to change the Keys for SecureBoot period (not even corporate IT).
> On x86-based Windows devices you'll be allowed to, but it's only a matter of time before Microsoft will try to pull the plug there too.
>
>
>>>>>> What kind of signature is the bootloader checking, anyway?
>>>>> Regardless of the check, it'll never be sufficient.
>>>>Sure; ultimately, all DRM solutions get cracked.
>>>
>>> TPM and SecureBoot will by design fail.
>>
>>Please be aware of the distinction between TPM from Palladium. In
>>fact, you should probably be aware of the distinction between tools
>>and policies, too.
>
>
> That won't resolve the issue.
>
>
>>> We'll see if SecureBoot actually even makes it to market; if it does, expect some Class Action lawsuits to occur.
>>
>>We'll see. Don't forget _you can turn the thing off_. I expect the
>>lawsuits will come around when the ability to turn the thing off or
>>reconfigure it is removed.
>
>
> As noted, WinRT devices will not allow you to change the keys; they also won't allow you to turn off Secure Boot.

If I properly understand what's discussed elsewhere in the thread, the
capability to turn off SecureBoot will be required for Windows 8
certification on x86 hardware. So, again, you _will_ be able to turn
it off.

Sure, that may mean you can't access the WinRT subsystem on Windows
with SecureBoot turned off. But you can still boot Linux. Want to boot
Windows and get WinRT? Turn SecureBoot back on and  boot Windows.

Yes, dual-booting is going to be a bigger pain than it already is.
And, honestly, I've never really understood dual-booting; if you spend
a long time in one OS, and a short time in another OS, much (most?) of
the time spend in that secondary OS is going to be spent in updates.
Which makes that secondary OS either very insecure for you, or a very
poor, nigh pointless experience.

> If MS can get SecureBoot out there and keep it enabled, then it's just a matter of time before they try to do the same thing to the rest of the platforms.
> So expect the lawsuits to happen if it even gets out to start with.

I did some googling after your repeated mentions of WinRT. From the
look of things, it's going to be hitting ARM as well as x86. ARM is
going to have a rougher time of it, though. Microsoft is being more
aggressive in that market...and no surprise; ARM platforms are eating
Microsoft's lunch--they're where you want to be in the mobile and
low-power markets. I think it unlikely Microsoft's going to succeed,
though; they're late to the game, and old giants (Nokia, RIM) are
collapsing.

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[William Kenworthy]

On Mon, 2012-06-04 at 10:34 -0400, Michael Mol wrote:
> On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
> >> From: Michael Mol <mikemol@gmail.com>
> >
> >>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
> >>>> From: Michael Mol <mikemol@gmail.com>
> >>[snip]
> >>> In theory that's how key signing systems are suppose to work.
...
> >>I see something like SecureBoot as being useful in corporate and
> >>military security contexts. I don't see it lasting in SOHO
> >>environments.
> >
> >
> >...
> 
> And here's a use case that might seem worthwhile...Say you've got
> hardware with SecureBoot. Now, you don't run Windows, so you don't
> care about the UEFI BIOS having Microsoft's key. Instead, you're a
> Linux guy, and you're very privacy conscious; perhaps you're a
> security consultant or contractor. Or perhaps you're worried about
> corporate espionage. Or perhaps you're simply afraid of governments.
> 
> You can flush Microsoft's key from BIOS and insert your own. Sign your
> bootloader, kernel and initramfs. Set up your / filesystem to be fully
> encrypted. And configure things such that if BIOS isn't operating in
> SecureBoot mode with your key, it won't even mount and decrypt your /
> filesystem.
> 
> You've just denied access to any existing forensic tool which would
> either examine your hard disk or operate as a rootkit. The only thing
> that's going to get your data is a live inspection of your RAM
> (tricky! but doable.) or a rubber hose.
> 
...

We have a security researcher at work who specialises in the forensics
side - expert witness in court and does data retrieval etc ... I dont
think he has had anyone seriously try to hide anything yet, but if the
above becomes common in the non-law abiding set, the govt will have it
back doored or dissappeared (banned from sale or heavily controlled).
"Think of the children ..." which is overused here in Oz comes to mind.

Providing tools to strip cell phone data and PC hard disks seems to be a
popular/profitable business to be in at the moment :)

BillK

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Walter Dnes]

On Mon, Jun 04, 2012 at 10:34:58AM -0400, Michael Mol wrote
> On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
> 
> > We'll see if SecureBoot actually even makes it to market; if it
> > does, expect some Class Action lawsuits to occur.
> 
> We'll see. Don't forget _you can turn the thing off_. I expect the
> lawsuits will come around when the ability to turn the thing off or
> reconfigure it is removed.

  The reason there is so much hate for TPM/Palladium/etc is that they're
tied into failed legislation proposed by former South Carolina Senator
Fritz Hollings.  He was jokingly referred to as "the Democrat from
Disney", because he seemed to spend more energy representing big media
than the people of his state.

  Fire up Google and look up the terms...
SSSCA CBDTPA "Fritz chip"

  This was intended to be draconian mandatory DRM on every PC.
Importing or building one without it would result in five to twenty
years in prison, and fines between $50,000 and $1 million.  It would've
effectively outlawed linux.  MS is trying to use its corporate muscle to
do via market manipulation what legislators couldn't.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Walter Dnes]

On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote

> The BIOS will only load a signed bootloader. The signed bootloader
> will only load a signed kernel.

  OK, so I sign LILO.  What code is in there that prevents LILO from
loading whatever kernel I've compiled?

> The signed kernel will...do whatever you tell it to do.

  Define "kernel"... no... seriously.
1) Could it actually be a hypervisor?

2) Or maybe another copy of LILO which proceeds to load the actual
kernel?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

Am 03.06.2012 08:57, schrieb Walter Dnes:
> On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote
> 
>> The BIOS will only load a signed bootloader. The signed bootloader
>> will only load a signed kernel.
> 
>   OK, so I sign LILO.  What code is in there that prevents LILO from
> loading whatever kernel I've compiled?
> 

Nothing. The point is, if you sign software that is used (or can be
used) for malware, your key will be blacklisted. That's why Fedora takes
the measures I've listed: They don't want to have their key revoked.

>> The signed kernel will...do whatever you tell it to do.
> 
>   Define "kernel"... no... seriously.
> 1) Could it actually be a hypervisor?
> 
> 2) Or maybe another copy of LILO which proceeds to load the actual
> kernel?
> 

Sure, whatever floats your boat. UEFI only checks the boot loader
directly. After that, it is the boot loader's responsibility to keep the
next stage secure. But if you allow unchecked access to the hardware
through whatever signed code you have, your key will be blacklisted. To
quote Matthew again:

> Secure boot is built on the idea that all code that can touch the
> hardware directly is trusted, and any untrusted code must go through
> the trusted code. This can be circumvented if users can execute
> arbitrary code in the kernel. So, we'll be moving to requiring signed
> kernel modules and locking down certain aspects of kernel
> functionality. The most obvious example is that it won't be possible
> to access PCI regions directly from userspace, which means all
> graphics cards will need kernel drivers. Userspace modesetting will
> be a thing of the past. Again, disabling secure boot will disable
> these restrictions.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2620 bytes --]

On Saturday 02 Jun 2012 23:50:58 pk wrote:
> On 2012-06-02 22:10, Michael Mol wrote:
> > I expect the chief mechanism is at the manufacturer's end; blacklisted
> > keys get included on shipment.
> 
> Makes sense.
> 
> > It's also probable that the OS kernel can tell the UEFI BIOS about new
> > keys to blacklist. I expect that'll be a recurring thing in the
> > Monthly batch of security updates Microsoft puts out. (Makes sense,
> > really; if malware is using a key, blacklist that key.)
> 
> Yes, would expect something like this. Secure boot supposedly prevents
> "unauthorized firmware, operating systems or UEFI drivers" at boot time.
> So if I interpret this correctly it would mean that if I have, say, an
> old graphics card with an old firmware (vga bios) I can't use it with
> "secure boot". More interestingly, how is an "operating system" defined?
> Does it mean only the kernel itself or does it mean a full-blown OS with
> init and other supporting software? What does that mean to a source
> based "distro"? Also, I would assume a legitimate key would be able to
> sign pretty much any binary so a key that Fedora uses could be used to
> sign malware for Windows, which then would be blacklisted by
> Microsoft... and how is malware defined? Anything that would be
> detrimental to Microsoft?
> 
> > Someone linked to some absolutely terrible stuff being built into
> > Intel's Ivy Bridge...it's plausible it will be possible to deploy
> 
> You mean:
> https://en.wikipedia.org/wiki/Intel_insider#Intel_Insider_and_remote-contro
> l
> 
> ?
> 
> > blacklist key updates over the network within a couple years.
> 
> Well, UEFI already implements remote management:
> http://www.uefi.org/news/UEFI_Overview.pdf (page 13)
> ... so implementing an automatic update over the network, preferably via
> SMM/SMI so that the operating system cannot intervene would be possible
> already today... and you've lost control of your computer.
> 
> I'm putting on my tinfoil hat now and I'm going to pretend it's
> raining... :-/
> 
> Best regards
> 
> Peter K

Can I please join you if you have a spare hat?

On a 3 year old Dell laptop manufactured by the famous and well known Winbond 
Electronics </sarcasm> I see this under lshw:

  *-remoteaccess UNCLAIMED
       vendor: Intel
       physical id: 2
       capabilities: outbound

but have not found a way of interrogating it or in anyway accessing it to 
understand what it is or does ...


Note, this is not a UEFI machine: 

capabilities: smbios-2.6 dmi-2.6 vsyscall32


-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Mon, Jun 4, 2012 at 8:48 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Saturday 02 Jun 2012 23:50:58 pk wrote:

[snip]

>> I'm putting on my tinfoil hat now and I'm going to pretend it's
>> raining... :-/

> Can I please join you if you have a spare hat?
>
> On a 3 year old Dell laptop manufactured by the famous and well known Winbond
> Electronics </sarcasm> I see this under lshw:
>
>  *-remoteaccess UNCLAIMED
>       vendor: Intel
>       physical id: 2
>       capabilities: outbound
>
> but have not found a way of interrogating it or in anyway accessing it to
> understand what it is or does ...
>
>
> Note, this is not a UEFI machine:
>
> capabilities: smbios-2.6 dmi-2.6 vsyscall32

What proc?

-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 968 bytes --]

On Monday 04 Jun 2012 13:57:11 Michael Mol wrote:
> On Mon, Jun 4, 2012 at 8:48 AM, Mick <michaelkintzios@gmail.com> wrote:
> > On Saturday 02 Jun 2012 23:50:58 pk wrote:
> [snip]
> 
> >> I'm putting on my tinfoil hat now and I'm going to pretend it's
> >> raining... :-/
> > 
> > Can I please join you if you have a spare hat?
> > 
> > On a 3 year old Dell laptop manufactured by the famous and well known
> > Winbond Electronics </sarcasm> I see this under lshw:
> > 
> >  *-remoteaccess UNCLAIMED
> >       vendor: Intel
> >       physical id: 2
> >       capabilities: outbound
> > 
> > but have not found a way of interrogating it or in anyway accessing it to
> > understand what it is or does ...
> > 
> > 
> > Note, this is not a UEFI machine:
> > 
> > capabilities: smbios-2.6 dmi-2.6 vsyscall32
> 
> What proc?

If you mean what /proc is this remoteaccess thing in, I don't really know.  
How can I find it?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Tue, Jun 5, 2012 at 8:52 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Monday 04 Jun 2012 13:57:11 Michael Mol wrote:
>> On Mon, Jun 4, 2012 at 8:48 AM, Mick <michaelkintzios@gmail.com> wrote:
>> > On Saturday 02 Jun 2012 23:50:58 pk wrote:
>> [snip]
>>
>> >> I'm putting on my tinfoil hat now and I'm going to pretend it's
>> >> raining... :-/
>> >
>> > Can I please join you if you have a spare hat?
>> >
>> > On a 3 year old Dell laptop manufactured by the famous and well known
>> > Winbond Electronics </sarcasm> I see this under lshw:
>> >
>> >  *-remoteaccess UNCLAIMED
>> >       vendor: Intel
>> >       physical id: 2
>> >       capabilities: outbound
>> >
>> > but have not found a way of interrogating it or in anyway accessing it to
>> > understand what it is or does ...
>> >
>> >
>> > Note, this is not a UEFI machine:
>> >
>> > capabilities: smbios-2.6 dmi-2.6 vsyscall32
>>
>> What proc?
>
> If you mean what /proc is this remoteaccess thing in, I don't really know.
> How can I find it?

Sorry...what CPU do you have?

cat /proc/cpuinfo


-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Bill Kenworthy]

On Tue, 2012-06-05 at 10:21 -0400, Michael Mol wrote:
> On Tue, Jun 5, 2012 at 8:52 AM, Mick <michaelkintzios@gmail.com> wrote:
> > On Monday 04 Jun 2012 13:57:11 Michael Mol wrote:
> >> On Mon, Jun 4, 2012 at 8:48 AM, Mick <michaelkintzios@gmail.com> wrote:
> >> > On Saturday 02 Jun 2012 23:50:58 pk wrote:
> >> [snip]
> >>
> >> >> I'm putting on my tinfoil hat now and I'm going to pretend it's
> >> >> raining... :-/
> >> >
> >> > Can I please join you if you have a spare hat?
> >> >
> >> > On a 3 year old Dell laptop manufactured by the famous and well known
> >> > Winbond Electronics </sarcasm> I see this under lshw:
> >> >
> >> >  *-remoteaccess UNCLAIMED
> >> >       vendor: Intel
> >> >       physical id: 2
> >> >       capabilities: outbound
> >> >
> >> > but have not found a way of interrogating it or in anyway accessing it to
> >> > understand what it is or does ...
> >> >
> >> >
> >> > Note, this is not a UEFI machine:
> >> >
> >> > capabilities: smbios-2.6 dmi-2.6 vsyscall32
> >>
> >> What proc?
> >
> > If you mean what /proc is this remoteaccess thing in, I don't really know.
> > How can I find it?
> 
> Sorry...what CPU do you have?
> 
> cat /proc/cpuinfo
> 
> 

Maybe this? -
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface

There is a kernel interface (under power management I think) and I seem
to remember some of my recent motherboards come with it.  If you have a
dell, look up iDRECV which does something similar.  Its not only the
cpu, but the motherboard you need to worry about.

BillK

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2851 bytes --]

On Wednesday 06 Jun 2012 02:14:45 Bill Kenworthy wrote:
> On Tue, 2012-06-05 at 10:21 -0400, Michael Mol wrote:
> > On Tue, Jun 5, 2012 at 8:52 AM, Mick <michaelkintzios@gmail.com> wrote:
> > > On Monday 04 Jun 2012 13:57:11 Michael Mol wrote:
> > >> On Mon, Jun 4, 2012 at 8:48 AM, Mick <michaelkintzios@gmail.com> wrote:
> > >> > On Saturday 02 Jun 2012 23:50:58 pk wrote:
> > >> [snip]
> > >> 
> > >> >> I'm putting on my tinfoil hat now and I'm going to pretend it's
> > >> >> raining... :-/
> > >> > 
> > >> > Can I please join you if you have a spare hat?
> > >> > 
> > >> > On a 3 year old Dell laptop manufactured by the famous and well
> > >> > known
> > >> > 
> > >> > Winbond Electronics </sarcasm> I see this under lshw:
> > >> >  *-remoteaccess UNCLAIMED
> > >> >  
> > >> >       vendor: Intel
> > >> >       physical id: 2
> > >> >       capabilities: outbound
> > >> > 
> > >> > but have not found a way of interrogating it or in anyway accessing
> > >> > it to understand what it is or does ...
> > >> > 
> > >> > 
> > >> > Note, this is not a UEFI machine:
> > >> > 
> > >> > capabilities: smbios-2.6 dmi-2.6 vsyscall32
> > >> 
> > >> What proc?
> > > 
> > > If you mean what /proc is this remoteaccess thing in, I don't really
> > > know. How can I find it?
> > 
> > Sorry...what CPU do you have?
> > 
> > cat /proc/cpuinfo
> 
> Maybe this? -
> https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
> 
> There is a kernel interface (under power management I think) and I seem
> to remember some of my recent motherboards come with it.  If you have a
> dell, look up iDRECV which does something similar.  Its not only the
> cpu, but the motherboard you need to worry about.
> 
> BillK

This is my CPU, a first generation i7:

cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU       Q 720  @ 1.60GHz
stepping	: 5
microcode	: 0x4
cpu MHz		: 933.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm 
sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 3192.11
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

You note that "power management:" above is empty.

grep-ping the /proc tree for remoteaccess does not bring up anything.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Michael Mol]

On Wed, Jun 6, 2012 at 3:40 PM, Mick <michaelkintzios@gmail.com> wrote:

[snip]

>
> This is my CPU, a first generation i7:
>
> cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 30
> model name      : Intel(R) Core(TM) i7 CPU       Q 720  @ 1.60GHz
> stepping        : 5
> microcode       : 0x4
> cpu MHz         : 933.000
> cache size      : 6144 KB
> physical id     : 0
> siblings        : 8
> core id         : 0
> cpu cores       : 4
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
> constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
> aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
> sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
> bogomips        : 3192.11
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
> You note that "power management:" above is empty.
>
> grep-ping the /proc tree for remoteaccess does not bring up anything.

According to Intel's site, your processor has the vPro "feature" in it.

http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-(6M-Cache-1_60-GHz)

Can you find the device you noticed under /sys?


-- 
:wq

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2103 bytes --]

On Wednesday 06 Jun 2012 20:50:38 Michael Mol wrote:
> On Wed, Jun 6, 2012 at 3:40 PM, Mick <michaelkintzios@gmail.com> wrote:
> 
> [snip]
> 
> > This is my CPU, a first generation i7:
> > 
> > cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 30
> > model name      : Intel(R) Core(TM) i7 CPU       Q 720  @ 1.60GHz
> > stepping        : 5
> > microcode       : 0x4
> > cpu MHz         : 933.000
> > cache size      : 6144 KB
> > physical id     : 0
> > siblings        : 8
> > core id         : 0
> > cpu cores       : 4
> > apicid          : 0
> > initial apicid  : 0
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 11
> > wp              : yes
> > flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> > syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
> > xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est
> > tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow
> > vnmi flexpriority ept vpid bogomips        : 3192.11
> > clflush size    : 64
> > cache_alignment : 64
> > address sizes   : 36 bits physical, 48 bits virtual
> > power management:
> > 
> > You note that "power management:" above is empty.
> > 
> > grep-ping the /proc tree for remoteaccess does not bring up anything.
> 
> According to Intel's site, your processor has the vPro "feature" in it.
> 
> http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-(6M-Cache
> -1_60-GHz)
> 
> Can you find the device you noticed under /sys?

No, nothing when I search for remote or remoteaccess or access ...

If this Intel AMT, or vPRO thingy is outside the MoBo chipset then it may not 
get probed or be accessible by the kernel?

But then, how does lshw see it?

  *-remoteaccess UNCLAIMED
       vendor: Intel
       physical id: 2
       capabilities: outbound   <--what does this mean?  O_O
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[William Kenworthy]

> power management:
> 
> You note that "power management:" above is empty.
> 
> grep-ping the /proc tree for remoteaccess does not bring up anything.

I dont mean cpu power management, I meant under the kernel config option
which you may not have enabled. As for the Dell iDREC, google it.

This stuff is "old" in enterprise equipment, and I suspect not widely
used but it is out there.

BillK

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Stroller]

On 7 June 2012, at 00:50, William Kenworthy wrote:
> ...
> I dont mean cpu power management, I meant under the kernel config option
> which you may not have enabled. As for the Dell iDREC, google it.
> 
> This stuff is "old" in enterprise equipment, and I suspect not widely
> used but it is out there.

Did you mean Dell DRAC? 

This is not obsolete at all, although in current models it is branded iDRAC.

I don't believe DRAC remote access is really related to IPMI, however.
I'm pretty sure that IPMI will work with a PowerEdge even lacking the DRAC module.

OP is taking about having a laptop, anyway, so that seems like a clupea rubra.

Stroller.

Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[pk]

On 2012-06-04 14:48, Mick wrote:

> Can I please join you if you have a spare hat?

Sure, got lots of (virtual) hats... here's one: ^ (may be a bit small) ;-)

> On a 3 year old Dell laptop manufactured by the famous and well
> known Winbond Electronics </sarcasm> I see this under lshw:
> 
> *-remoteaccess UNCLAIMED vendor: Intel physical id: 2 capabilities:
> outbound
> 
> but have not found a way of interrogating it or in anyway accessing
> it to understand what it is or does ...
> 
> 
> Note, this is not a UEFI machine:
> 
> capabilities: smbios-2.6 dmi-2.6 vsyscall32

https://en.wikipedia.org/wiki/System_Management_BIOS
https://en.wikipedia.org/wiki/Desktop_Management_Interface

SMBIOS does support out-of-band management, which may or may not be
scary, depending on who's in control of it...

https://en.wikipedia.org/wiki/Out-of-band_management

If you have an Intel processor in that laptop that supports vPro, I
would assume it's a "professional" laptop, and as such it might make
sense (assuming the IT department in your company is in control).

Here's an interesting link that describes some of the problems with
modern computers (it's an approx 1 hour long video from Google Tech
talks, regarding coreboot):
https://www.youtube.com/watch?v=X72LgcMpM9k

Best regards

Peter K

[gentoo-user] Re: Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[Nikos Chantziaras]

On 02/06/12 05:26, William Kenworthy wrote:
> http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html
>
> and something I had not considered with the whole idea was even bootable
> cd's and usb keys for rescue will need the same privileges ...

We were "chipping" our Playstations and XBOXes, now we'll be chipping 
PCs too. :-/