Intel TXT advice

[TeaderP]

Having discovered Qubes some time ago I decided to invest a whole lot of time in the learning curve, learning both linux / Fedora and Qubes. After playing with Qubes for a while I decided to set up and purchase the best desk top machine I could to use Qubes on. I read a lot of the documentation, research papers and blogs to decide what to do. After months of reading I was under the impression that Intel TXT technology was a desirable technology to have in this new machine.  Before I go further I want to say I am not looking to lay blame or fault but I am looking for knowledgeable advice, preferably from a Qubes developer, on what to do now with intel TXT having just seen a video of Joanna Rutkowska saying it is not so good, and after she read a new book by an Intel Dev says she was misled on its security. That is Ok, At the rate technology changes and develops it is impossible to stay on top of it. I understand that. So I have tried on my own by reading and lurking and trying really hard not to bug anyone with stupid noob questions and have succeeded this far but this issue is way out of my understanding and as far as a can ascertain is a critical security issue.

My question to a Qubes security professional then - What should I do with Intel TXT in my new machine if it is a security issue now?

Thank you in advance for your time.

[TeaderP]

My question to a Qubes security professional then - What should I do with Intel TXT in my new machine if it is a security issue now?

Thank you in advance for your time.

Being an important security issue I would ask again for the best course of action in regards to Intel TXT. 
How compromised is it? I understood that it is now very exploitable. Am I mistaken?
Should I just simply disable TXT and VPro?
Is there a better way to deal with it or am I mistaken and over reacting? I'm happy to know either way.

I understood that Intel ME was not good either now but I have no use for that. 

I spent extra money to get these technology under the impression from the ITL research that they were good to have, so I would like to know if they are at all usable or whether I should just disable the lot. I'm sure a lot of other Qubes users interested in security would be interested to know also.

If there are some public disclosure issues with Intel I would be happy to receive a personal email.

[raah...@gmail.com]

You can read Joanna's latest pdf writeups on intel me on the blog. blog.invisiblethings.org "x86 considered harmful" and "state considered harmful"

The main gist i get from her latest article even more then txt is weak, is that if the vendor manufacturer is in cahoots with a state actor or whoever(such as NSA), they could compromise us through intel me and we would never even be able to prove it. Not only that, corporations might be able to really limit the control we have over our pcs in the future. Richard Stallman has been saying the same things for years but Joanna really explains everything in detail.

No security measure is 100% imo. I would still use it if you have the option, why not? I don't think it would actually weaken your security? Only poc i can find online with someone exploiting txt is the ITL team themselves. So I imagine it would take someone of their expertise. Do you have more information on this subject you can share?

If you don't mind me asking what board do you have? Which laptop comes with txt, or if a desktop board where did you buy your tpm header module?

Also, imo, regardless of these security concerns I feel qubes would be more secure then your normal linux or windows systems even without Intel ME/Vpro. Qubes takes into account something might be compromised already while most linux systems are too arrogant or blind to believe something is even possible by design. I would love to hear others opinions.

[Eric Shelton]

My understanding is that although Joanna has concluded that Intel TXT is flawed, it may still be an essential component of Anti Evil Maid (AEM).

I have never found it clear whether TXT is a required feature for AEM (the README instructs you to install the appropriate SINIT module for your CPU, which I believe involves TXT).  Joanna or Marek, can you clear this up (and maybe make it more explicit in the documentation if it is in fact required)?

Eric

[marmarek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, AEM in current shape uses Intel TXT. Initial AEM implementation used
static root of trust through tboot (TPM aware grub-legacy fork), but
since migration to grub2 it was no longer feasible.

It is stated clearly in README in anti-evil-maid package (which is also
referenced from documentation page). Maybe it should be also mentioned
directly on https://www.qubes-os.org/doc/anti-evil-maid/ (anyone willing
to hit "edit" button there?)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWy2Q8AAoJENuP0xzK19csIVoH/ikrvd1ifIM/aSUVKDy8+GVE
Iad/7z0HbThCzDuAxlCqJXT7L03/IMqCWYugbqYpupN9OrfqH0UD+NDwTzyejgsq
Dj34p7060P9Far3BZ0zgUAUbQ8gSuVq8fFEZaLK/q8t1xES7Qi0Ic5fdinb0hZc5
7WEBgwM/kflJk7AGzjncBcoqWFMzfefQjxsi8e2HlHe2Tdi6xDBuczs/0eboN2lz
6SB24LizNkkz+VXu2wCvhBDCL9sjMqx2kzru6vCOtZI47z7wDRaPslBAlOs36vQn
g4okz9oNrZTeOzXg5P3LQUbR9geSN7K4ulau4EGz8ZxvmWD+9ohjW/No0y6bpUs=
=dMhY
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

marmarek:

> Yes, AEM in current shape uses Intel TXT. Initial AEM
> implementation used static root of trust through tboot (TPM aware
> grub-legacy fork), but

^^^^^ *TrustedGRUB; tboot is used now

> since migration to grub2 it was no longer feasible.

Though even now it should be possible to use AEM without TXT? Just don't
install the SINIT blob, in which case *only* the LUKS header(s) would be
protected by the TPM. If a per-boot BIOS password has been set, maybe
this kind of setup is even sort of reasonable?

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJWy3UbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfd7wP/3AiXWcDWJ7EKFDBeoNFnaXz
mAYHTCTv44lSEoW76r3SDIh2/r0oTgFSg9xIHtsBnHCfWX/3CzOlMKEoGx8wyKCn
QL4UMIwdKcarecYCE4DxfbS8ditL7WyEdxIGCnNmUxbTdY4P3PdbunnTjRUkjAvo
8tOKEE4dmlift79n2u8TWOjlfTDI7m/yv/Jajt/tH8QNCe/WTzNBPLbM4fLgPmjg
mEH6YsU1pthK312W530nCrljFNNLwHcdKVnmsbohbMN3pswrYOcVTchIDYai3KTB
fs669OeDr3/1OKNUADeXr11bugYtu8FqJTbuNV3x+8Zr1DJ9P0VElotD/9G16/k1
3FXQ00WuFuAUhtJJGLA7A+CBrZVqKTH22LLvwfascSMMag63Q+t2Qa0krY4pQP52
VTVzI/TW1IpI3CSxCm7ik4BR8IJcj9EWBY/DVBBq3y+kbmfgddfXNjC52oPniWI+
K72hgWwmpJLUTPgthehNr5DsuVLEasl8q3Lbh8r+tkrwdVG3GdQPySeADbS32jrr
qnkifaeTe720bLpv9in1tX1QN4eSnYPwpgGLkZ6TDM7sjsUqRpNmfkBYMDQ/5bgC
dxgBpIWQdDtTY+5lcSOQYcocRnhLZTrPCeTNwJLlJ6Y7Bc9kbQ5p//ulF7DutmoE
av6fGydjxAyBRNbvNgUd
=I9Uk
-----END PGP SIGNATURE-----

[TeaderP]

> > You can read Joanna's latest pdf writeups on intel me on the blog.  

Thank you. If I hadn't read that I would be interested to do so. That is why I was wondering if I should disable the lot or if there was some use still. I see now that I should leave it enabled if I want to use AEM. This is a desktop machine in my home and not really expecting anyone to break in to compromise it as I don't have any state secrets or company property / data. I don't think I need AEM - would I disable TXT?

> >
> > No security measure is 100% imo.  I would still use it if you have the
> > option,  why not?  I don't think it would actually weaken your security?
> > Only poc i can find online with someone exploiting txt is the ITL team
> > themselves.  So I imagine it would take someone of their expertise.  Do you
> > have more information on this subject you can share?

A search of Intel TXT exploit sure delivered a lot of direct results and most of them concerning ITL but I'm sure I saw some other company with an exploit. If not TXT then definitely ME. I will double check.

> >
> > If you don't mind me asking what board do you have?  Which laptop comes
> > with txt, or if a desktop board where did you buy your tpm header module?

The desk top machine has an Intel i7 processor and I had the Q170 chipset especially put in to replace the Z170.

> >
> >  Also, imo, regardless of these security concerns I feel qubes would be
> > more secure then your normal linux or windows systems even without Intel
> > ME/Vpro.  Qubes takes into account something might be compromised already
> > while most linux systems are too arrogant or blind to believe something is
> > even possible by design. I would love to hear others opinions.

I believe as much. Qubes is a game changer. I'm surprised it took so long for technology to get past a monolithic kernel. Kudos ITL. Also why I was confident to just disable the lot if someone with knowledge could confirm if there was any critical usage of the TXT technology for Qubes. This is new ground for most of us and why I have come asking what might appear to be basic questions. I can see the genius in this design and I intend to become a proficient contributing user.

So I can the conclude that if I don't think I need to worry about Evil Maid and therefore not have to use AEM - I can just turn TXT and Vpro off and Qubes will be just as secure without it and function normally?

For me Intel ME is a no brainer and there is a slide on the motherboard / chipset to turn it off. If I turn it off at the slide is it truly off?

[marmarek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 22, 2016 at 08:52:43PM +0000, Rusty Bird wrote:
> marmarek:
> > Yes, AEM in current shape uses Intel TXT. Initial AEM
> > implementation used static root of trust through tboot (TPM aware
> > grub-legacy fork), but
> ^^^^^ *TrustedGRUB; tboot is used now

Yes.

> > since migration to grub2 it was no longer feasible.
>
> Though even now it should be possible to use AEM without TXT? Just don't
> install the SINIT blob, in which case *only* the LUKS header(s) would be
> protected by the TPM.

But not having xen/kernel/initrd measured means AEM is pretty useless.
The whole purpose is to verify the thing that prompt you for LUKS
passphrase. Without such measurement you'll have no way to really know
if those binaries were even loaded from your USB stick (and not from
some additional one plugged in by the attacker, for example). Such
replaced initrd script can present still unmodified LUKS header to TPM,
unseal the secret, show it to you, then record LUKS passphrase.

> If a per-boot BIOS password has been set, maybe
> this kind of setup is even sort of reasonable?

You are joking, aren't you?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWy3sJAAoJENuP0xzK19cs3UIH/AxoXod6UAsebTd/Kr0oyrST
QCOKdJY0IhnmYqXAH2EC4aYkKbha4kTf4h+M+b4z2o2ZL7SEJsUnimN7bWAJlpxb
9nHjDOVbffyTwON2rAfAIwHGlaWe1/THMxQ6p6OxtvNMyYcpZivJzR5XQDwckZX0
zvqZjn3879IwUGCs5pHwRu9tlgEieK4JTbLRiTUSbMWfGngl4jFTIcLGIKrpjVOm
Kh/NchSTi8jODdQJLpLqqz+kTQAQeH6y9tfTOrgJyr3SI/pL4LRLry4o8u1UdFkt
7+nTy2sMgWiE7PT20jXko4wu+2e3UJMvS8qub1Na3iYwsLGEhpYC/Nscc1gtZ0w=
=Iqrr
-----END PGP SIGNATURE-----

[raah...@gmail.com]

Vpro means different things so not sure what you mean by that. If you are not using aem then you don't need intel txt. For me vpro means amt, if your mobo probably has intel amt option in bios, I would turn that off also.

But you would want to still turn on intel vt-d which helps isolate the netcard used to help prevent dma side attacks for example. someone please correct me if I'm wrong.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

marmarek:

> On Mon, Feb 22, 2016 at 08:52:43PM +0000, Rusty Bird wrote:
>> Though even now it should be possible to use AEM without TXT?
>> Just don't install the SINIT blob, in which case *only* the LUKS
>> header(s) would be protected by the TPM.
>
> But not having xen/kernel/initrd measured means AEM is pretty
> useless. The whole purpose is to verify the thing that prompt you
> for LUKS passphrase. Without such measurement you'll have no way
> to really know if those binaries were even loaded from your USB
> stick (and not from some additional one plugged in by the attacker,
> for example).

If the order is fixed, i.e. USB before SATA, and you don't see another
USB drive sticking into the notebook you left at home, then the part in
parentheses wouldn't apply?

> Such replaced initrd script can present still unmodified LUKS
> header to TPM, unseal the secret, show it to you, then record LUKS
> passphrase.

But Xen/kernel/initrd are on the AEM stick you take with you, so the
attacker would have to modify the BIOS. In which case TXT wouldn't help
much, because a BIOS rootkit can effectively hide itself from TXT if I
understand Joanna right.

>> If a per-boot BIOS password has been set, maybe this kind of
>> setup is even sort of reasonable?
>
> You are joking, aren't you?

Not really. If these assumptions are correct:

1. a BIOS rootkit can hide itself from TXT;
2. an attacker who can boot their own medium can, more and more
probably, also persist such a rootkit in the BIOS;
3. there are no BIOS master password lists anymore (are there?),
or other easy password prompt bypasses (are option ROMs loaded
early enough from ExpressCards?);

then it seems to me that a per-boot BIOS password without TXT could work
out better than the converse, TXT without a PBBP. Not to say that both
together aren't best though!

AEM protecting the LUKS header would still be (barely) worthwhile
without TXT, if it's easier / faster / less conspicuous for the attacker
to take out the HDD and rewrite a few blocks than to infect the BIOS.

(BTW Marek, regarding VM random seeds: Have you considered somehow
harnessing whatever it is that Thunderbird+Enigmail use to place line
breaks in my mails after I hit send)

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJWy9wLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfwBcP+wRvEHdaElmRlrtnDzumWF9s
zLq9NYrklIVuZNEMnR0q7PrrZrOzqV2DBodJq9jcfdL1gBTbYlsO6W6TzZxlRMir
PkbycDd6mJ69ez9eGvc1oqkRa0kaPxhVQtaf+YOYrGb2VwJlKOEvy44wxGBHC49W
EdM+znTecHPZT2Rb9Q/xKWiw78pEGeWAPbeeB2CwUjZR120KhfdI0Nm+NiMyFjqY
+v05q/D0QEQ+RvdMzwg38M/uCMgPdahNo5k85S4Qb6po0M8GHZX11NRkkSiwZiv4
sW1Y8IzbA3xtqc3GL3iGXePOXFrcqAfdbCVqdqj4lz5Let6QOGSk5g8JSeQjprlX
rEsE5xC9LCi4EBxBnvJrdibe67Xvux3peC5VIO7DSohKt81AEIzbPIhoZ7P62U5E
meR3L6omQvqZxPBehonqkK1TpC8i5pTlapENELNKUKsR2NCWRDNdRZir3SfES4Sg
fSdgmdqtKHUReiDsWpdCvBPOcZns+y7KxOyKF8Q/RdmmillHQ0kvIn4BMyvpaeHt
+QtbFAWGcazrq6zh9XF/rRMGeBO4fU5sgF8aWyJ3R9N+EkLekhrd7aN0cq1cGU1s
oPaCaQ/+duY5Y2LOrvY8QG+svRRu8YZgaAm0+pz2rIENSMETlwkS44jUMQj9EppJ
v/VdcppIkj8UwCaWZcsz
=YwFD
-----END PGP SIGNATURE-----

[TeaderP]

Vpro means different things so not sure what you mean by that.  If you are not using aem then you don't need intel txt.  

Thanks raah..., As far as I know Evil maid needs someone to be physically present to insert USB, so although anything is possible I guess the probability would be absolutely minute. If Qubes functions normally without that tech I am turning it off.

 

But you would want to still turn on intel vt-d which helps isolate the netcard used to help prevent dma side attacks for example.  someone please correct me if I'm wrong.

 

The main reason I asked for the Q170 instead of the z170 chipset was to get vt-d which I know is essential to best functioning of Qubes. The Z170 chipset does not support vt-d.  I thought the TXT and other technology would be a bonus but I guess I'm disabling all that. I'm still happy though as the specifications of the processor (6th gen i7) and chipset with vt-d should keep up with Qubes os for years to come.

I read that the TXT exploit has the potential to possibly be the worst exploit ever in the context of the prevalence of the technology. If I wasn't using Qubes I wouldn't think about turning it off.

Thanks to everyone who replied. I have confidence to proceed.

[qu...@qubu16.sbrk.co.uk]

On Tue, Feb 23, 2016 at 04:11:55AM +0000, Rusty Bird wrote:
> 3. there are no BIOS master password lists anymore (are there?),
> or other easy password prompt bypasses (are option ROMs loaded
> early enough from ExpressCards?);

I bought a new HP laptop a couple of months ago, set a BIOS password
and stored it on my phone, then unfortunately destroyed my phone.
It took me 5 minutes to find a site to remove BIOS passwords from
my laptop by just entering the on-screen challenge code and
receiving a reset password.

I have tried tboot with TXT but it was such a pain to setup and
I found my other laptops don't have it. I'm currently using
Matthew Garrett's TPM-enabled grub with UEFI secureboot and my
own secureboot PK/KEK/db keys. I haven't yet got as far as trying
to get this working with qubes yet though.

I don't have any expectation that this can survive a reasonably
targetted BIOS modification attack but I do think it reduces a
number of less sophisticated attacks.

Paul

[marmarek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Feb 23, 2016 at 04:11:55AM +0000, Rusty Bird wrote:

> marmarek:
> > On Mon, Feb 22, 2016 at 08:52:43PM +0000, Rusty Bird wrote:
> >> Though even now it should be possible to use AEM without TXT?
> >> Just don't install the SINIT blob, in which case *only* the LUKS
> >> header(s) would be protected by the TPM.
> >
> > But not having xen/kernel/initrd measured means AEM is pretty
> > useless. The whole purpose is to verify the thing that prompt you
> > for LUKS passphrase. Without such measurement you'll have no way
> > to really know if those binaries were even loaded from your USB
> > stick (and not from some additional one plugged in by the attacker,
> > for example).
>
> If the order is fixed, i.e. USB before SATA, and you don't see another
> USB drive sticking into the notebook you left at home, then the part in
> parentheses wouldn't apply?

It is easy enough to hide USB device inside the USB socket itself (those
devices are small these days). Or inside your notebook (for example
instead of bluetooth card, which is also USB device in most cases).

Some more sophisticated attack would be installing some "USB proxy" in
USB socket. Which would hijack only initramfs reads. You'll not see
any additional USB device in the system in that case.

> > Such replaced initrd script can present still unmodified LUKS
> > header to TPM, unseal the secret, show it to you, then record LUKS
> > passphrase.
>
> But Xen/kernel/initrd are on the AEM stick you take with you, so the
> attacker would have to modify the BIOS. In which case TXT wouldn't help
> much, because a BIOS rootkit can effectively hide itself from TXT if I
> understand Joanna right.

But attack hidden from TXT is much more complex than attack simply
changing boot order. It all depends on your threat model.

> >> If a per-boot BIOS password has been set, maybe this kind of
> >> setup is even sort of reasonable?
> >
> > You are joking, aren't you?
>
> Not really. If these assumptions are correct:
>
> 1. a BIOS rootkit can hide itself from TXT;
> 2. an attacker who can boot their own medium can, more and more
> probably, also persist such a rootkit in the BIOS;
> 3. there are no BIOS master password lists anymore (are there?),
> or other easy password prompt bypasses (are option ROMs loaded
> early enough from ExpressCards?);

I wouldn't rely on BIOS password protection. It failed so many times
in the history, so I can't assume that magically now BIOS vendors
learned how to do it properly.

> then it seems to me that a per-boot BIOS password without TXT could work
> out better than the converse, TXT without a PBBP. Not to say that both
> together aren't best though!
>
> AEM protecting the LUKS header would still be (barely) worthwhile
> without TXT, if it's easier / faster / less conspicuous for the attacker
> to take out the HDD and rewrite a few blocks than to infect the BIOS.
>
> (BTW Marek, regarding VM random seeds: Have you considered somehow
> harnessing whatever it is that Thunderbird+Enigmail use to place line
> breaks in my mails after I hit send)
>
> Rusty

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWzCxPAAoJENuP0xzK19csMKMH/2UKniK+2stmWYV4CiEcgo1t
fGXwhwXEP7yFssfw65ANdJtyvdtsAk8cxah3+JEQ4D3l3qw0cdJ29rsasvp+o8GI
kOpDDi/m5LzI0tsJuZ+0Z3ZcKYNOoQR4TVti89h7qLi75+BjsIhOvPSTjLmPY06n
5+OjfNYa8QwwcD4rtEBe0yePNt8yhxqvrM5WHqmaEpVw+AtMBxg4e7o87s2Qo5Ld
IXgc2hHiK44CPDDpTSqQGC36XLByKOfxilEcj9946YTwL+QlQIlY8O9GdihSBzfd
P2xQ68cDw9jqjxrm8ifAbuhrSfcQR+9XGq+snsJPo+TBYBuG/NimT7hprIeNMS8=
=BF3U
-----END PGP SIGNATURE-----

[Eric Shelton]

On Monday, February 22, 2016 at 3:53:21 PM UTC-5, TeaderP wrote:

> > You can read Joanna's latest pdf writeups on intel me on the blog.  

Thank you. If I hadn't read that I would be interested to do so. That is why I was wondering if I should disable the lot or if there was some use still. I see now that I should leave it enabled if I want to use AEM. This is a desktop machine in my home and not really expecting anyone to break in to compromise it as I don't have any state secrets or company property / data. I don't think I need AEM - would I disable TXT?

> >
> > No security measure is 100% imo.  I would still use it if you have the
> > option,  why not?  I don't think it would actually weaken your security?
> > Only poc i can find online with someone exploiting txt is the ITL team
> > themselves.  So I imagine it would take someone of their expertise.  Do you
> > have more information on this subject you can share?

A search of Intel TXT exploit sure delivered a lot of direct results and most of them concerning ITL but I'm sure I saw some other company with an exploit. If not TXT then definitely ME. I will double check.

> >
> > If you don't mind me asking what board do you have?  Which laptop comes
> > with txt, or if a desktop board where did you buy your tpm header module?

The desk top machine has an Intel i7 processor and I had the Q170 chipset especially put in to replace the Z170.

You mention later on you made that choice because you believed that "The Z170 chipset does not support vt-d."  FWIW, that is not true - VT-d works on Z170.  You will find multiple users on this forum who have been using Z170 systems and Skylake just fine with VT-d.

Intel has made figuring out what combinations of CPUs and chipsets support VT-d a challenge (and on top of that, motherboard vendors have contributed their own blunders).  It was a real mess before Haswell.  Things got easier starting with Haswell, since northbridge and southbridge functionality relating to VT-d got pulled into the CPU package.  Now you just need to pick the right CPU and make sure your BIOS includes VT-d support.

 

> >
> >  Also, imo, regardless of these security concerns I feel qubes would be
> > more secure then your normal linux or windows systems even without Intel
> > ME/Vpro.  Qubes takes into account something might be compromised already
> > while most linux systems are too arrogant or blind to believe something is
> > even possible by design. I would love to hear others opinions.

I believe as much. Qubes is a game changer. I'm surprised it took so long for technology to get past a monolithic kernel. Kudos ITL. Also why I was confident to just disable the lot if someone with knowledge could confirm if there was any critical usage of the TXT technology for Qubes. This is new ground for most of us and why I have come asking what might appear to be basic questions. I can see the genius in this design and I intend to become a proficient contributing user.

So I can the conclude that if I don't think I need to worry about Evil Maid and therefore not have to use AEM - I can just turn TXT and Vpro off and Qubes will be just as secure without it and function normally?

For me Intel ME is a no brainer and there is a slide on the motherboard / chipset to turn it off. If I turn it off at the slide is it truly off?

I have not heard of any such capability, and I am very skeptical - particularly where Skylake is concerned - that ME _can_ be turned off, or that Intel has made firmware blobs that would in effect disable the objectionable features of ME available to motherboard vendors (and even if they were offered, I'm not sure we have any way to actually verify that they in fact neuter ME).  For example, my understanding is that the SGX instructions, introduced in Skylake, are closely integrated with code running in ME for the secure enclaves, etc.  As I understand it, ME is currently unavoidable if you have an Intel CPU made after 2008 or so - there is no way to boot up the CPU without it.

What motherboard do you have that indicates it has the capability to disable ME?  It would be interesting to look at the user manual to see exactly what is said about this.

Eric

[TeaderP]

On Wednesday, February 24, 2016 at 1:49:12 PM UTC+10, Eric Shelton wrote:

The desk top machine has an Intel i7 processor and I had the Q170 chipset especially put in to replace the Z170.

You mention later on you made that choice because you believed that "The Z170 chipset does not support vt-d."  FWIW, that is not true - VT-d works on Z170.  You will find multiple users on this forum who have been using Z170 systems and Skylake just fine with VT-d.

Intel has made figuring out what combinations of CPUs and chipsets support VT-d a challenge (and on top of that, motherboard vendors have contributed their own blunders).  It was a real mess before Haswell.  Things got easier starting with Haswell, since northbridge and southbridge functionality relating to VT-d got pulled into the CPU package.  Now you just need to pick the right CPU and make sure your BIOS includes VT-d support.

Thank you for pulling me up on that Eric. Rechecking my months of sticky notes and the Intel ARK specifications site again I will say that I mis-spoke and you are correct. The z170 chipset does support VT-d. It was the i76700 Z processor found in HP desktops that did not have some important tech that I wanted. The Z170 chipset did not support TXT or Vpro. My apologies to all, I have had a ton of information to process lately. Having just broken up with Apple after a decade- (Yes, it was you Apple )- I found Qubes and took on the task of learning Linux/ Fedora and Qubes. So two new operating systems and machines and all the Qubes docs. I'm playing with Debian too now. Anyway, I'm sorting through it slowly and hopefully can contribute competently in the future. Until then, I have decided to make a policy of making a donation whenever I have a noobish question that takes up time.

 

For me Intel ME is a no brainer and there is a slide on the motherboard / chipset to turn it off. If I turn it off at the slide is it truly off?

I have not heard of any such capability, and I am very skeptical - particularly where Skylake is concerned - that ME _can_ be turned off, or that Intel has made firmware blobs that would in effect disable the objectionable features of ME available to motherboard vendors (and even if they were offered, I'm not sure we have any way to actually verify that they in fact neuter ME).  For example, my understanding is that the SGX instructions, introduced in Skylake, are closely integrated with code running in ME for the secure enclaves, etc.  As I understand it, ME is currently unavoidable if you have an Intel CPU made after 2008 or so - there is no way to boot up the CPU without it.

What motherboard do you have that indicates it has the capability to disable ME?  It would be interesting to look at the user manual to see exactly what is said about this.

 

 I am also skeptical and why asked if it is truly off. Although my background is in science it has nothing to do with computer sciences and I wouldn't know how to check if it is truly off even if I pushed the slide to disable it. I will find out how in time though because as you mentioned there are objectionable features in ME. The Intel Q170 -C chipset has been given to me on an Asus motherboard. The link to it here https://www.asus.com/us/Motherboards/Q170M-C-CSM/ . The information about disabling ME can be found on page 12, Chapter 1 of the user guide and reads; "This jumper allows you to enable or disable the Intel* ME function. Set this jumper to pins1-2 to enable (default) the Intel* ME function and to pins 2-3 to disable it." There is diagram of its location. The * is the registered mark.  

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

marmarek:

> On Tue, Feb 23, 2016 at 04:11:55AM +0000, Rusty Bird wrote:
>> marmarek:

>>> But not having xen/kernel/initrd measured means AEM is pretty
>>> useless. The whole purpose is to verify the thing that prompt
>>> you for LUKS passphrase. Without such measurement you'll have
>>> no way to really know if those binaries were even loaded from
>>> your USB stick (and not from some additional one plugged in by
>>> the attacker, for example).
>
>> If the order is fixed, i.e. USB before SATA, and you don't see
>> another USB drive sticking into the notebook you left at home,
>> then the part in parentheses wouldn't apply?
>
> It is easy enough to hide USB device inside the USB socket itself
> (those devices are small these days).

Right, I hadn't really thought about hidden USB drives. They do seem
realistic enough, and would make the BIOS password issue moot. (Unless
you're lucky and insert the real USB drive into the occupied port, in
which case the boot process would suspiciously fail.) Has anything like
this been spotted yet?

> Some more sophisticated attack would be installing some "USB proxy"
> in USB socket. Which would hijack only initramfs reads. You'll not
> see any additional USB device in the system in that case.

Hmm... A USB stick where the inner prong of the plug is < 0.1 mm
thicker than allowed has a noticeably increased insertion force in
every socket I've tried it with.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJW1W/yXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfWCYP/AyApNx19VXryEJcwbM0Kmyh
SXuq0bldjn0j7/7rllQ3wpCWLUiPafNJnu7n3thgALWFLas59S0uKU4wCIcARffc
MONSx6WsQNnMeq1raxefFGO4aZpKa4jcrqfMv1kqhLTYO7neE3NjWJXN1nJdpCcm
GPW/E89eF30dmMQ5r/u+21E59G56h9B+PeZG3kSOISdX6T7uwSnH6dzKf6dgq0Gj
sUZiZmvdXjyjz/WIB1QMZW+0eL3crA9gMOxJWxLnmOp8WCadbyeNAGKnDAJM/6FT
crr9PsIeTHzlP0Y0/DIl5rYzwTEzP87tLD3CWmbdUz+hCoT1zxLj8XuYnsx6UXqj
xSRxCmcsR3lyYXot2ay/F/qcKHcor+9RQlJVlhnV4v+TSi8CPpwWiPRYTjcfE/OE
fdGY1qf8ycZxoouoqqZLLg5/CoITC4/mf8IW4WdLqfvhnJOWPRH4Jx+AUpTN+Xaw
VllQU9t1RN5rJbO3u8h4RNecMc6jJodyM5mod+3Ti7hl5KOKIY3DwtI3zVp9BqgW
I7s5G8aMElqzz4d4r92FkudybBs7IkV7DsLpx4bw5FqYkotZXsbmbgcM9BX7mH3j
3rMJHjUqnkPsMzq+qtIdOhVJtGUFAevt9j6hd4rRz/nfAvzG1GrP6lehwdIZUEb7
ANLPgAcPr9f4wnVW9KUo
=bm0e
-----END PGP SIGNATURE-----

[Rusty Bird]

Hi Paul,

> I bought a new HP laptop a couple of months ago, set a BIOS password
> and stored it on my phone, then unfortunately destroyed my phone.
> It took me 5 minutes to find a site to remove BIOS passwords from
> my laptop by just entering the on-screen challenge code and
> receiving a reset password.

Ugh, that sucks. Do you mean https://bios-pw.org/?

> I have tried tboot with TXT but it was such a pain to setup and
> I found my other laptops don't have it.

For the laptop with TXT support, you might want to give AEM another try
on Qubes 3.1, where it's a little more streamlined. Getting the SINIT
blob from Intel's website is still annoying though.

Rusty

[qu...@qubu16.sbrk.co.uk]

Hi Rusty,

> > I bought a new HP laptop a couple of months ago, set a BIOS password
> > and stored it on my phone, then unfortunately destroyed my phone.
> > It took me 5 minutes to find a site to remove BIOS passwords from
> > my laptop by just entering the on-screen challenge code and
> > receiving a reset password.
>
> Ugh, that sucks. Do you mean https://bios-pw.org/?

That looks about right. I think I found a python version somewhere too.

> > I have tried tboot with TXT but it was such a pain to setup and
> > I found my other laptops don't have it.
>
> For the laptop with TXT support, you might want to give AEM another try
> on Qubes 3.1, where it's a little more streamlined. Getting the SINIT
> blob from Intel's website is still annoying though.

I know how to do it now so it's not a problem. A big problem was that
tboot silently changed the mechanism where they stripped the first
parameter off the command line and it just reset or powered off if
the TXT policy is wrong. I finally figured it out looking through
the code and got it working.

I have my own AEM mode now anyway. I boot and decrypt my sealed root
filesystem luks key then show a google authenticator code unsealed
via the TPM on boot.

Paul

[Eric]

Just bought a laptop with a Skylake processor for running Qubes, and from looking around on Intel's website it appears that no Skylake Core-branded processors support Intel TXT. Any point in running Anti-Evil-Maid at this point? Can I use a YubiKey to store hashes of the xen/initramfs and use that for AEM? (probably not, since it's a USB device?)

[entr0py]

Eric:

I was just looking around for information on AMT/ME a minute ago. It appears that some Skylake Core i5/i7's do support TXT. (On their website, TXT might fall under the umbrella of vPro.)

https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors#Skylake_microarchitecture_.286th_generation.29_2
https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors#Skylake_microarchitecture_.286th_generation.29_2

[Eric]

On Sunday, November 13, 2016 at 5:01:59 PM UTC-8, entr0py wrote:
> Eric:

> > Just bought a laptop with a Skylake processor for running Qubes, and from looking around on Intel's website it appears that no Skylake Core-branded processors support Intel TXT. Any point in running Anti-Evil-Maid at this point? Can I use a YubiKey to store hashes of the xen/initramfs and use that for AEM? (probably not, since it's a USB device?)
> >
>
> I was just looking around for information on AMT/ME a minute ago. It appears that some Skylake Core i5/i7's do support TXT. (On their website, TXT might fall under the umbrella of vPro.)
>
> https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors#Skylake_microarchitecture_.286th_generation.29_2
> https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors#Skylake_microarchitecture_.286th_generation.29_2

Yes, I misspoke. It appears that the processor/chipset on the computer I purchased does not have/support vPro or TXT (though Intel ME is apparently disabled, which is a win, I guess?). So hard to find something that checks all the boxes for me. My threat model currently doesn't include Evil Maids, so I'm probably ok. Shame, though. Hopefully it doesn't close the door on Qubes 4 compatibility. (It does have SLAT and VT-(d/x).

[Chris Laprise]

I hate to point this out now, but AEM is kind of a misnomer. It can
alert you to tampering from *either* physical or remote attacks. So
anyone who wants to guard against a remote exploit that can also priv
escalate against Xen--and from there possibly infect firmware or boot
device--would benefit from using AEM.

When I last shopped around, I was under the impression that TXT was tied
to AMT/ME/Vpro as a package.

Chris

[Eric]

> > Yes, I misspoke. It appears that the processor/chipset on the computer I purchased does not have/support vPro or TXT (though Intel ME is apparently disabled, which is a win, I guess?). So hard to find something that checks all the boxes for me. My threat model currently doesn't include Evil Maids, so I'm probably ok. Shame, though. Hopefully it doesn't close the door on Qubes 4 compatibility. (It does have SLAT and VT-(d/x).
>
> I hate to point this out now, but AEM is kind of a misnomer. It can
> alert you to tampering from *either* physical or remote attacks. So
> anyone who wants to guard against a remote exploit that can also priv
> escalate against Xen--and from there possibly infect firmware or boot
> device--would benefit from using AEM.
>
> When I last shopped around, I was under the impression that TXT was tied
> to AMT/ME/Vpro as a package.

Well, that's unfortunate. Guess I'll shop around some more, ask more questions. I know that ThinkPads are popular, as are "business class laptops", but I haven't seen any newer ones being mentioned here (and older laptops are likely to be used, which I'm not a fan of).

[Jean-Philippe Ouellet]

On Sun, Nov 13, 2016 at 8:36 PM, Eric <akta...@gmail.com> wrote:
> though Intel ME is apparently disabled, which is a win, I guess?

You can not "disable" ME. See page 37 of
https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

[Tai...@gmx.com]

I am assuming you were one of those people who bought a computer from
those purism scammers.
https://blogs.coreboot.org/blog/2015/02/23/the-truth-about-purism-why-librem-is-not-the-same-as-libre/

It is impossible to disable (ie, like it was never there, 100% gone) ME
on any intel system post 775/771 era, anyone who tells you different is
lying.

vPro is a marketing term for various ME remote management features that
are activated with a vPro license, all intel systems 2006+ have ME.

On 11/13/2016 08:36 PM, Eric wrote:

[Tai...@gmx.com]

Forgot to say:
Purism is just an overpriced quanta/oem whitebox laptop, it takes 5mil+
of startup funds to do a small run of *just a motherboard* let alone an
entire laptop computer including the fab for a fancy aluminum case - it
is quite obvious that their components are not "hand selected" and that
they just called up some chinese OEM and asked them what they had
kicking around.

I can't understand if they are scammers or just really naive, Instead of
making an OpenPower or ARM laptop and having it be 100% libre from the
start they instead do the dishonest "you'll go to disneyworld one day
poor johnny" - If google can't convince intel to open up FSP/ME then
nobody can - coreboot with FSP is just shimboot (black box FSP - 95% of
the bios work)

It bothers me quite a lot that they are on the list of approved vendors
when they are a dishonest company.

[Eric]

Whoa. Ok, hold on a sec. I did not buy a Purism computer, though not for those reasons - putting a 28W TDP proc in a 15inch "workstation" is absurd to me. as is their lack of a screen configuration. I hear your anger at the gap between what they promise and what they deliver; I'm more displeased on the hardware side of things (though I do like HW kill switches. I've looked into what they promise and understand very well that they don't actually have a very free computer at all, especially on the bios/firmware side.

What I actually ordered (and have now cancelled), was a Dell XPS 15". There is no vPro option in the configure menu, though it does support VT-d and SLAT. I've read all of Joanna's papers, and understand the concerns about Intel ME very well. However, on the Dell order, it claimed "ME Disabled." Perhaps they simply meant that vPro/AMT/TXT was disabled, and that was mine and Dell's fault for wishful thinking and false naming, respectively. Please see linked photo: https://d.pr/Q0YZ

[Tai...@gmx.com]

...I had assumed you purchased a purism computer as they are the only
ones to have claimed to "disable" ME (entirely not true)


I have experience with the dell ordering process, it simply means that
in the ME settings menu it is set to "Disabled" which to intel means a
different thing than to you and I as it is still quite involved in the
boot process and is still lurking in the background.

They aren't being dishonest, you just misunderstood what it meant - they
provide that notification as many business users like to have it enabled
and in one touch configuration mode (ME would have been a really cool
feature for corporate IT departments if it was FOSS and located on a
physically removable eprom chip)

vPro is a marketing term for several corporate manageability features,
it is a set of modules that is loaded in to ME for remote access if the
license key is available on the system.

There are several blob free laptops including:
http://makezine.com/2014/01/08/building-an-open-source-laptop/
https://kosagi.com//w/index.php?title=Novena_Main_Page
https://www.crowdsupply.com/sutajio-kosagi/novena - finally a
crowdfunding project with realistic goals and a quality end result - Ima
get me one

"jwe...@chromium.org:
All Chromebooks based on Nvidia and Rockchip SoCs are 100% FOSS as far

as firmware goes (graphics acceleration is a different story, but you
can run them with software rendering). (Mediatek Chromebooks are 99.9%
FOSS, they just have a tiny power management controller with openly
available binary firmware.)""


But no unfortunately you aren't going to get a modern "mobile
workstation" type laptop that is blob free - if dell asks why you
canceled tell them that you want a blob free non-intel coreboot laptop
(the CSR wont know what you are talking about - but it will make you
feel better)

If you want IOMMU laptop though I am not sure what to tell you at the
moment, I suppose the best choice would be an older thinkpad (blobs -
but no FSP) that is compatible with coreboot and trammel hudsons ME
nerfing project.

I guess you could always make your own mobile workstation "laptop" by
machining a case and sticking a blob free desktop motherboard in it,
kind of like a 1U laptop.

I used to like dell, their latitude/precision line was really great
(until they started H1B abuse and chasing apple with the thinness
obsession at the expense of everything else + bad island chiclet
keyboard + fisher price design + lousy 16:9 screen)

[entr0py]

Eric:

Moral considerations aside, why not buy that Dell and pair it with a portable router/firewall like this (https://www.compulab.co.il/utilite-computer/web/products)? Shouldn't that effectively block out any ME-related mischief or do I have a fundamental misunderstanding? It doesn't seem possible otherwise to get the type of processing power you're looking for in a laptop form-factor.

[Eric]

Well, the Dell XPS was enough processing power for me. The Business version, the Precision 5510, not only has vPro and TXT, but also supports ECC memory (Xeon E5). Adds another layer of protection (against Rowhammer attacks that can compromise even Qubes), but a) nobody actually makes DDR4-ECC-SODIMM memory that I can find, and b) it's basically another thousand bucks. I also happen to hate 16:9 displays, but I would compromise on that for Qubes' sake.

As far as blob-free hardware goes, I unfortunately have to live and work in the world, and therefore need 1) performance and x86-64 architecture, and 2) to not have my computer be a part time job.

Guess I'll keep looking. And saving.

[Eric]

On Monday, November 14, 2016 at 11:58:32 AM UTC-8, entr0py wrote:

Also, the concern for me is not ME shenanigans. I'm more concerned about having TXT for AEM and measured boot, and the consumer Dell model does not have that (the processor and chipset don't support it). The other option aside from the Precision 5510, would be a ThinkPad T460 or T460p, but the downside there is performance (only SATA-3 SSD), and also the screen quality is terrible.

Much as I dislike proprietary anything, I might take a second look at the new MacBook Pros, and run things that need higher security in a VM or in Whonix.

[Tai...@gmx.com]

Why would you buy a macbook? You realize those have regular intel
processors and ME too right?

Lenovo is owned by the chinese, and dell business laptop (their consumer
line is garbage) is a way better choice than either.

It seems you do have (as you said) a fundamental misunderstanding of how
security actually works, and how a router/firewall operates. - thus I
don't think that anyone would be targeting you specifically with a ME
exploit.

[Eric]

On Monday, November 14, 2016 at 1:02:14 PM UTC-8, Tai...@gmx.com wrote:
> Why would you buy a macbook? You realize those have regular intel
> processors and ME too right?
>
> Lenovo is owned by the chinese, and dell business laptop (their consumer
> line is garbage) is a way better choice than either.
>
> It seems you do have (as you said) a fundamental misunderstanding of how
> security actually works, and how a router/firewall operates. - thus I
> don't think that anyone would be targeting you specifically with a ME
> exploit.

Beg your pardon. Calling into question my security knowledge does not lead to any sort of productive discussion. I am fully aware that I have things to learn, and that's why I'm here. I'm not going to get itno a security measuring knowledge with your or fire back with how much I do know; I'll simply thank you for your insight and move on.

Cheers.

[entr0py]

Tai...@gmx.com:

(top-posting fixed)

Despite my "fundamental misunderstanding of how security actually works", I am able to read a thread and keep track of who said what - a skill you seemed to have misplaced in all your wizardry. Also, on your crusade to dismantle Intel and Google, it might behoove you to take a slightly less agressive tack with people who generally share your beliefs cause it seems you're significantly outnumbered as it is.

Now if you'd like to respond without the obligatory disdain and actually explain something, my questions was: "Is Intel ME/AMT able to bypass firewalls that haven't been specifically configured to support those services?" This entry: https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Communication leads me to think that ME TCP/IP traffic isn't automatically passed-through, but like *I* said, I may have a fundamental misunderstanding of that.

[entr0py]

entr0py:

I should add: My question is in the context of independent router/firewalls (on separate hardware). I know that firewalls on the same machine as Intel ME have no effect because the signals are out-of-band / not OS-dependent.

[Tai...@gmx.com]

It is the same as any other device connected to your network, if it has
a world routable IP, you port forward, your router gets hacked, your
computer gets exploited or it initiates communication on its own then
yes it can communicate with the outside world.
For all we know it is simply waiting for an "activation" code sent via
MITM that it will detect.

I do not want to "dismantle" intel/google, I simply want them to be more
friendly to the customer and for intel to end their war on free software
and general purpose computing - they used to be great companies but now
they aren't because of nepotism and outsourcing.

Features like boot guard could have been implemented fully open source
and transparent, with a jumper to disable or place the computer in
signing mode so that you can sign/write your own firmware.
In 10-20 years you won't even be able to run unapproved binaries or view
unapproved files on an average computer, similarly as to how secure boot
v2 standards don't require the option to disable it (and thus you must
ask microsoft for permission to run linux on your own computer) it is a
slippery slope and if you give them an inch they take a mile.

It is the hollowing of the market, the removal of the middle class of
computing.
You can buy a low performance arm (or the like) device with free
firmware or you can splash out 4-8K for a super high performance OPOWER8
device from ibm/tyan - it is a myth that free firmware is only available
on old/slow devices. My next laptop will be a desktop board in a custom
made mobile 1U chassis.

"top posting" is my natural way of reading things, with my eyes at the
center-top of the screen it feels more natural. I am the trump of the IT
world - a steamroller in every way "my way or the highway" - but I enjoy
and am happy to help people with highly technical questions that no one
else is able to answer as long as they do their own research as well.

[3n7r...@gmail.com]

> computer gets exploited or *it initiates communication on its own* then

> yes it can communicate with the outside world.
> For all we know it is simply waiting for an "activation" code sent via
> MITM that it will detect.

Thank you for the explanation. Even Trump can act presidential. :) So it turns out my reasoning had a rather obvious flaw. I kept stubbornly assuming that my ME device would be on the LISTENING end when it could just as easily be set to call out periodically and render my genius plan moot. I guess now I'm back in the depressing boat with everyone else.

> I do not want to "dismantle" intel/google, I simply want them to be more
> friendly to the customer and for intel to end their war on free software
> and general purpose computing - they used to be great companies but now
> they aren't because of nepotism and outsourcing.
>
> Features like boot guard could have been implemented fully open source
> and transparent, with a jumper to disable or place the computer in
> signing mode so that you can sign/write your own firmware.
> In 10-20 years you won't even be able to run unapproved binaries or view
> unapproved files on an average computer, similarly as to how secure boot
> v2 standards don't require the option to disable it (and thus you must
> ask microsoft for permission to run linux on your own computer) it is a
> slippery slope and if you give them an inch they take a mile.
>
> It is the hollowing of the market, the removal of the middle class of
> computing.
> You can buy a low performance arm (or the like) device with free
> firmware or you can splash out 4-8K for a super high performance OPOWER8
> device from ibm/tyan - it is a myth that free firmware is only available
> on old/slow devices. My next laptop will be a desktop board in a custom
> made mobile 1U chassis.

I spent some time reading up on Power (including this optimistic Anandtech review: http://www.anandtech.com/show/9567/the-power-8-review-challenging-the-intel-xeon-/2). The chips are seemingly priced competitively enough (though my office would turn into a sauna). I was intimidated by the prospect of having to port x86 packages to Power arch but looking through Debian repos, it appears that nearly all of the packages I use have already been ported to ppc64el. Then I noticed the one exception, the dealbreaker, is that Xen doesn't support Power. So it comes down to Qubes + Intel ME versus KVM + Power8 + clueless user. So yeah... guess my Intel boycott lasted all of one day. :/

[Tai...@gmx.com]

So you know AFIAK OPOWER8+ systems have a emulation layer for x86 that
works quite well, on the TALOS page you can see them playing a modern 3d
game with it via pass thru video although obvious you wouldn't want to
emulate a VMM.

Xen isn't the be all-end all of virtualization, there are many other
solutions and some of them work better. (I could never get pass thru
video to work with xen, only qemu-kvm and I used libvirt for the
management layer)

There are plenty of non ME systems out there that are new enough to be
useful for gaming, only AM4/FM2 have PSP but all the other AMD procs
don't have PSP. The KGPE-d16 for instance is an opteron blob free
coreboot/libreboot board that is quite nice for a performance
workstation. For a laptop there is always the novena and a few other
blob free ones, and if you don't want ME you can buy a non PSP AMD laptop.

[Pedro Martins]

On 14-11-2016 20:07, Eric wrote:
> On Monday, November 14, 2016 at 11:58:32 AM UTC-8, entr0py wrote:
>> Eric:
>>> On Sunday, November 13, 2016 at 10:44:33 PM UTC-8,
>>> Tai...@gmx.com wrote:

>>>> ...

>
> Well, the Dell XPS was enough processing power for me. The Business
> version, the Precision 5510, not only has vPro and TXT, but also
> supports ECC memory (Xeon E5). Adds another layer of protection
> (against Rowhammer attacks that can compromise even Qubes), but a)
> nobody actually makes DDR4-ECC-SODIMM memory that I can find, and b)
> it's basically another thousand bucks. I also happen to hate 16:9
> displays, but I would compromise on that for Qubes' sake.
>

FYI, ECC SODIMM DDR3, no DDR4 yet:

http://www.intelligentmemory.com/ECC-DRAM/DDR3/

--
Pedro Martins