Recommended laptop?

[Ondřej Šulák]

Hello pals,

for the last release of Qubes, what laptop would you recommend? Is there any cheaper option which does have HW compatibility with latest Qubes (ideally with shipping from EU), than this one:

https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ ?

Thanks for any tips!

Ondrej

[Claudia]

December 24, 2019 9:43 AM, "Ondřej Šulák" <ond...@gmail.com> wrote:

> Hello pals,
>
> for the last release of Qubes, what laptop would you recommend? Is there any cheaper option which
> does have HW compatibility with latest Qubes (ideally with shipping from EU), than this one:
>

> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop ?
> Thanks for any tips!
>

There are two tested, but not certified, models: Thinkpad X1 Carbon gen 5, and Thinkpad x230. https://www.qubes-os.org/doc/hardware-testing/

In general Thinkpads are usually pretty safe. Personally I would try to avoid AMD systems, as well as consumer models. Look for business class or mid-range hardware where possible, as they tend to have more solid firmware. Look for Intel 4th gen (I think) and newer, as prior generations did not have integrated chipsets. Avoid buying the latest models. Qubes is based on older versions of Fedora and LTS kernels, so look for hardware that has been on the market for at least a little while. Look for models that advertise Linux compatibility or ship with Ubuntu preinstalled, and prefer vendors that tend to have good Linux support, such as Lenovo, Dell, and HP.

Other than that, check the HCL, and google around and see what other users have reported. Also search the mailing list for HCL reports, as it takes a long time for them to show up on the website.

Above all, make sure you can return it for a refund in case it doesn't run Qubes!

Now, all that being said, I recently took a chance on a very cheap consumer-grade Dell Inspiron with AMD, and I have to say I had pretty good luck, all things considered. USB Qube is not supported, and I still haven't gotten suspend/resume to work, but everything else works, and it was a steal for the price.

So even going against all recommendations you can still get lucky, it just depends how much risk you're comfortable with and how much trial-and-error you have time for. However, even following all the best practices won't guarantee success on the first try: case in point there are Thinkpads on the HCL with more problems than my cheap Inspiron.

Good luck!

[tasch...@posteo.de]

On Tue, 2019-12-24 at 12:48 +0000, Claudia wrote:
> Personally I would try to avoid AMD systems,

why that?

[Claudia]

> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> qubes-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/8137b39c393fd7d7192a72a8620706ae13f4150b.camel@posteo.
> e.

https://www.mail-archive.com/qubes...@googlegroups.com/msg31520.html

Not scientific evidence or anything, just my personal opinion/experience.

[Yethal]

Insurgo isn't really doing anything you can't do yourself with an x230 so just buy a regular x230 (they're dirt cheap at this point), put 16gb of ram and an ssd inside and then flash heads on there 

[brenda...@gmail.com]

Insurgo is providing a service.

If one can do the steps themselves, that’s fine.

If I were advising a somewhat less technical journalist or a potentially targeted human-rights worker or politically targeted activist who just wanted to get stuff done and had the resources, I’d point them to Insurgo.

Brendan

[rec wins]

On 12/25/19 1:03 PM,

+1 thinkpads think mine is a x540 or something, +1 16gb RAM and SSD,
bought my thinkpad used year ago for like $200 add the RAM and SSD ,

apparently some feel Intel isn't really trustworthy but might have to
pay more for non Intel machines, and roll dice if it has the VT-d or
Iommu required minimums, personally I don't use the TPM though I have
it, fear I'll likely lock myself out , and don't know what I'm doing in
general :)

[brenda...@gmail.com]

My own longterm Qubes primary has been a used W520 quad core with four 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core versions: they only have two memory slots and can only support 16GB Max.]

Storage: 1 x mSATA (300MB/s) slot; 1 x SATA (600MB/s) main bay; 1 x SATA (600MB/s) in media tray replacing optical drive; 1 x eSATAp (300MB/s) external port. Additional 1 x eSATA (300MB/s) on some docks. So plenty of fast-enough storage options. Plus an SD card slot.

VGA. DisplayPort. Ethernet. WiFi. Modem.

2 x USB 3.0.

2 x USB 2.0 (1 is part of the eSATAp connector). More on some docks.

FireWire and Expresscard (you’d generally want to disable both in bios for security reasons). Though...expresscard can be used to add another usb controller if two is not enough (e.g. to work around usb pass through issues with usbip).

Core unit generally $250-$300 on eBay in ok shape (sans ram and storage which you can add yourself).

Bit heavier than the x230, but I appreciate the additional RAM and cores most of the time.

Install in legacy mode, disable discrete GPU.

B

[Blake S]

On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com wrote:

My own longterm Qubes primary has been a used W520 quad core with four 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core versions: they only have two memory slots and can only support 16GB Max.]

B

What BIOS are you using?  I have a W520 coming in soon that I plan to use for Qubes.  I've been using a G505s for a while but it isn't terribly well built and suspend/resume doesn't work on it.

-BS

 

[brenda...@gmail.com]

On Sunday, December 29, 2019 at 5:35:52 PM UTC-5, Blake S wrote:

On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com wrote:

My own longterm Qubes primary has been a used W520 quad core with four 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core versions: they only have two memory slots and can only support 16GB Max.]

What BIOS are you using?  I have a W520 coming in soon that I plan to use for Qubes.  I've been using a G505s for a while but it isn't terribly well built and suspend/resume doesn't work on it.

Lenovo BIOS for W520, v1.46 (most recent last I checked).

Qubes R4.0 (updated as of today, including current-testing repo).

Using kernel-latest in dom0 (5.4.3-1, but 5.4.5-1 on next reboot).

Suspend/Resume appear to be working ok.

B

[eira wahlin]

I use qubes on an AMD system (thinkpad with Ryzen 5 pro 2500u). While I'm happy with it, I've had to make some sacrifices. AMD systems are tricky with hardware forwarding, so I cannot (at the moment) use a sys-USB. There is an inherent security problem there.

Also, I've had to make my own versions of the (horribly elitistic and class-hatingly named) AEM system. I use my machine's TPM2 to verify that my BIOS hasn't been infected, but that was difficult as hell to set up. AEM relies on Intel's TPM module, and doesn't work with AMD machines.

So while most of it all works, it's been tricky to set up, and it's not all functional yet.

<3
/panina

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Thierry Laurion]

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com.

Hello there, Thierry Laurion from Insurgo Open Technologies.

Thanks Brendan.

I feel the need to clarify things a bit once in a while. This reply is one of those. This QubesOS community is large, and even if replies were done on Reddit and other posts here in the past, the same questions arises with the same scattered answers. Here is a combination of those answers.

• Insurgo made grant applications so that actual best trustworthy unmaintained hardware becomes mainstreamed under coreboot, and added under Heads (extend Heads measured boot support of latest coreboot VBOOT+measured boot on Sandy/Ivy bridge xx30 and xx20 platforms:  t530, t430, x220. Thanks to obtained NlNet grant for Accessible Security project).
• Insurgo is attempting to gather developers, device manufacturers (RaptorEngineering) and funders around Power9-Power10 hardware based X86 alternative platform (PPC64le QubesOS platform support which has a bounty offer already but needs commited developers). Let's remember that their Blackbird/Talos II platforms recently got RYF certification.
• The last x86 platform having met RYF criteria is the X200, thanks to the Libreboot project, which removed Intel ME.
  
• Since then, the x86 platforms have blobs we have to accept/deal with to make it trustworthier:
  
• Sandy Bridge/Ivy bridge : EC firmware, Intel ME BUP ROMP modules. Coreboot doesnt rely on FSP blobs for initialization. ME is actually neutered (no kernel nor syslibs as opposed to newer platforms, just BUP and ROMP) and deactivated (AltMeDisable bit, not HAP bit).
• More recent hardware requires ME with its kernel and syslibs binary blobs present, while ME is asked to be deactivated through HAP bit, requires Intel FSP and other binary blobs for hardware initialization.
  
• Insurgo works to bridge the gap to broader QubesOS accessibility, so that users in need of remote support can have secured remote administration from trusted third parties (new revenue? AccessNow? Other third parties?) over hidden tor onion service from additional GUI (NlNet grant for Accessible Security project).
• Insurgo tries its best to support Heads community through GitHub opened issues while promoting collaboration.
  
• Insurgo tries its best to mainstream CI build systems to produce reproducible builds artifacts (this is broken for months and is still not resolved).
  
• Insurgo tries to raise awareness of researchers and developers on the current state of "Open Source Firmware" (currently requiring FSP, ME or equivalent,not having completely neutered Intel ME while claiming it is deactivated, while system libraries and kernel is still there but latent...) This implies going to conferences, doing talks, confronting the status quo, researching, developing so we have alternatives in the future....while also doing the required clerical work.
  
• Insurgo made QubesOS preinstallable for the first time on the PrivacyBeast X230, thanks to its reownership wizard which takes care of GPG key generation, internal ROM reflashing, TPM ownership and sealing of measurements, signing boot configuration, while enforcing diceware passphrases in the provisioning phase. The goal is to generalize it to other platforms. Ideally through collaboration...
  
• Insurgo made the PrivacyBeast X230 certified by QubesOS, with a lot of work done on Heads that is unfortunately not upstreamed yet. Will go back at this, while branch is available through Gitlab and GitHub.
  
• Insurgo collaborates with other parties to make needed work to have fwupd (firmware upgrades), available inside of QubesOS, including Heads firmware, thanks to NlNet Privacy and Trust grant, once again.
  
• Insurgo tries to push verified boot to measure also the LVM containers inside of deployed QubesOS reencrypted disk installation, through Heads, so that third party OEMs could also deploy reproducible ROMs that are measureable, verify their reproducibility, have verified boot and known good QubesOS installation with safer defaults to deploy to users by themselves (LUKS discards, MAC randomization, sdcard attached to sys-usb and others). The user would not have to trust those third parties on the RoT.
  
• Add internationalization into Heads, so that UK keyboards and other keymaps can be selected at first boot and saved into the ROM at ownership.
  
• .... Other work required by both QubesOS, Heads and their subprojects for more accessible security and usability.
  

There is something really interesting in the open source world.

Bigger corporation will pay for the development work they require to fit their needs and upstream changes. This makes software and accomplished work feel like free as in free beer.

Meanwhile, when a small player tries to make important changes for everyone in related projects, with really limited resources, people apply the same free as in free beer logic since they can buy second hand hardware online at lower price and do the reprogramming themselves, not understanding even the differences on the model they are buying and the changes in costs associated with the model they buy, nor the privilege they have to be able to do required technical work themselves nor the knowledge privilege they have of knowing that such hardware and free software exist with which their hardware can be freed with.

Of course, you can and are encouraged to backup your SPI flash chips, unlock the rom, apply me_cleaner, flash ME and Heads back into SPI flash chips, replace the wifi card, factory reset your USB security dongle, seal secrets for remote attestation and sign boot components, if you are tech savvy enough to do it right, yourself.

Meanwhile, Insurgo's goal is to facilitate that DIY, while still making money enough to pay itself and others to do the technical required work... so that you can do it yourself if you'd like, while organizations needing this kind of privacy/confidentiality/security for their users can also do the work for their users, without knowing all the technical details. On the X230 now, and other platforms in the near future.

Meanwhile, the x230 i7 2.9ghz, with its IPS screen and replaced wifi card, maximized 16GB ram and 256GB SSD drive, which makes the PrivacyBeast X230 hardware, is the one of the last platform on which open source firmware can fully thrive, meeting QubesOS requirements, pushing things the farthest possible by truely neutering ME (releasing 5Mb of additional ROM space to do more stuff from the boot environment), using its TPM to do the measured boot functions, sealing secrets into a QR code that enforces remote attestation through TOTP (smartphone based manual validation) or HOTP USB security dongles (Librem Key/Nitrokey Pro and Nitrokey Storage which visually attests of firmware integrity with a green or red LED), while using OpenGPG functions of the smartcard to enforce verified boot on QubesOS core system components (/boot), making those root of trust required components tamper evident.

Thanks for you time. Equip yourself accordingly. :)

Thierry Laurion

Insurgo, Open Technologies

[Anil Eklavya]

Thanks for putting all this information in one place. I was earlier looking to buy Insurgio Privacy Beast, but it was not clear whether it could be shipped to India. I then ordered Librem 13.

Is there any comparison available between these two, based on privacy and security considerations?

Regards,

Anil Kumar Singh 

On 01-Jan-2020, at 2:15 AM, Thierry Laurion <thierry...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAAzJznx%2BSgVSWOMvaohPf-im082uXqSqsu%3DLLL7P4N8rhXRKKA%40mail.gmail.com.

[trueriver]

Thanks Thierry,

Thanks for the detailed explanation and thanks for the work you have chosen to do. Thanks even more for upstreaming as much as you already have so that others can benefit too.

I want too add a couple of points that I hope are supportative, but let me start with an analogy.

When I was an impoverished student I used to fix my own car when it went wrong: serious problems too, stripping down the engine at one point. I never enjoyed it, and as soon as I was earning I gave that work to the local mechanic even though I knew how to do it.

If someone wants the most secure laptop available on a turnkey basis then they would buy from you. Maybe they are not expert enough to know all the pitfalls you mention; but even if they do know enough they may make the same choice I made over car maintenance. They have things to do with their time that they prefer to be doing rather than doing IT stuff. AND they can afford to do so.

There are two sorts of people her who will want to do the work for themselves.

There are those of us who enjoy the process and want to actually work through the choices for ourselves as the best way to fully understand our own kit.

And there are also those of us who need to watch every penny, so will do the best we can for ourselves within a budget that makes a 230 affordable at second hand prices but not at refurb prices.

Actually I'm in both those groups when it comes to IT, and my security needs are not so pressing as to need to pay the security premium that your product offers. And I enjoy tinkering with software more than I ever enjoyed lying under a car in the road when it was snowing.

So you have my sincere thanks for the info you do share (both through the open source channels and through posts like this one). And if a friend asks me to install a secure OS for them I will send them to you rather than take on a lifetime commitment to give them free support.

Equally, from where I am at the moment I would actually prefer to buy the second hand laptop and work through the process myself. But please don't ever think that that means I disrespect what you are doing, or that I have any problem with your pricing policies. You've made this your work and you are totally entitled to make a living out of it. At the end of the day I'm a hobbyist.

And it's not just free beer: I pay back when I can, not with currency, but in giving advice here when I see other ppl who are struggling with what I already solved, by making bug reports, and I've even edited the Qubes docs on a couple of occasions. For me free as in speech is a two way process: I come to ask questions here, but when I come I always find myself answering questions as well.

So much kudos to you for your choice of making your livelihood, and for facilitating hobbyists and those on low budgets by sharing info as well.

Have a great year Thierry

River~~

[Lorenzo Lamas]

Hello Thierry,

Thanks for all that you are doing for the community. Do you see a possibility of a Qubes Certified Laptop with an AMD CPU?

Intel is affected a lot more than AMD by the sidechannel vulnerabilities in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel stopped providing uCode updates for 1st gen in 2019, so this year is probably the last year they will support 3rd gen. More CPU vulnerabilities will most certainly be discovered in the coming years, so there is a need for an AMD based certified laptop, or at least a newer generation Intel based laptop, even though that may mean we're stuck with PSP or ME.

On Tuesday, December 31, 2019 at 9:45:18 PM UTC+1, Thierry Laurion wrote:

On Wed, Dec 25, 2019 at 6:03 PM <brend...@gmail.com> wrote:

Insurgo is providing a service.

If one can do the steps themselves, that’s fine.

If I were advising a somewhat less technical journalist or a potentially targeted human-rights worker or politically targeted activist who just wanted to get stuff done and had the resources, I’d point them to Insurgo.

Brendan

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes...@googlegroups.com.

[Claudia]

December 31, 2019 1:02 PM, "eira wahlin" <pan...@nonbinary.me> wrote:

> I use qubes on an AMD system (thinkpad with Ryzen 5 pro 2500u). While I'm happy with it, I've had
> to make some sacrifices. AMD systems are tricky with hardware forwarding, so I cannot (at the
> moment) use a sys-USB. There is an inherent security problem there.
>
> Also, I've had to make my own versions of the (horribly elitistic and class-hatingly named) AEM
> system. I use my machine's TPM2 to verify that my BIOS hasn't been infected, but that was difficult
> as hell to set up. AEM relies on Intel's TPM module, and doesn't work with AMD machines.
>
> So while most of it all works, it's been tricky to set up, and it's not all functional yet.
>
> <3
> /panina

Hi again, processor buddy. I have the Ryzen 5 (non-Pro) 2500U. I've also had a lot of problems with it. The IOMMU grouping is terrible, the kernel has a lot of problems with the firmware and ACPI, it doesn't support USB Qube, and so on. I haven't dared to even try AEM on this machine. But considering the performance for the money, I guess I really can't complain.

I recently got suspend/resume half working. Turns out, some or all of the Fam15h processors including the 2500U change their cpuid feature bits when resuming from suspend, which causes a Xen panic. This means the fans come back on, but the screen doesn't power back on and it can't save any logs, so it's really hard to diagnose. You can patch Xen to disable the feature check.

If you don't mind patching Xen, it's very likely that this will fix it for you (although you may run into other post-resume problems). And it's really not as difficult as it sounds.

This link contains a patch and instructions for building it.
https://www.mail-archive.com/qubes...@googlegroups.com/msg31697.html

[Thierry Laurion]

On Wed, Jan 1, 2020 at 3:16 AM Anil Eklavya <anile...@gmail.com> wrote:

Thanks for putting all this information in one place. I was earlier looking to buy Insurgio Privacy Beast, but it was not clear whether it could be shipped to India. I then ordered Librem 13.

 

Website does the simulation in costs for tax and shipping costs. If provided shipping address returns a shipping option, it can be shipped to you.

Is there any comparison available between these two, based on privacy and security considerations?

 

Unfortunately, not for the moment. External comparisons welcome!

At the end of the day, it goes to those simple points:

• X230's Intel ME has no kernel, no syslibs. It is reduced to be able to boot itself and main CPU and is shut down, not having anything else to execute since the modules have been removed completely. See here. 
• Here is an extract of the same me_cleaner command applied to:
• X230:

Full image detected
The ME/TXE region goes from 0x3000 to 0x4ff000
Found FPT header at 0x3010
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x183000 to 0x24d000
ME/TXE firmware version 8.1.30.1350
Removing extra partitions...
Removing extra partition entries in FPT...
Removing EFFS presence flag...
Removing ME/TXE R/W access to the other flash regions...
Correcting checksum (0x7b)...
Reading FTPR modules list...
 UPDATE           (LZMA   , 0x1cf4f2 - 0x1cf6b0): removed
 ROMP             (Huffman, fragmented data    ): NOT removed, essential
 BUP              (Huffman, fragmented data    ): NOT removed, essential
 KERNEL           (Huffman, fragmented data    ): removed
 POLICY           (Huffman, fragmented data    ): removed
 HOSTCOMM         (LZMA   , 0x1cf6b0 - 0x1d648b): removed
 RSA              (LZMA   , 0x1d648b - 0x1db6e0): removed
 CLS              (LZMA   , 0x1db6e0 - 0x1e0e71): removed
 TDT              (LZMA   , 0x1e0e71 - 0x1e7556): removed
 FTCS             (Huffman, fragmented data    ): removed
 ClsPriv          (LZMA   , 0x1e7556 - 0x1e7937): removed
 SESSMGR          (LZMA   , 0x1e7937 - 0x1f6240): removed
Relocating FTPR from 0xd00 - 0xcad00 to 0xd00 - 0xcad00...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
The ME minimum size should be 98304 bytes (0x18000 bytes)
The ME region can be reduced up to:
 00003000:0001afff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Removing ME/TXE R/W access to the other flash regions...
Extracting and truncating the ME image to "extracted_me.rom"...
Checking the FTPR RSA signature of the extracted ME image... VALID
Checking the FTPR RSA signature... VALID
Done! Good luck!

• Librem V3:
  Full image detected
  Found FPT header at 0x1010
  Found 1 partition(s)
  Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
  Found FTPR manifest at 0x1448
  ME/TXE firmware version 11.6.0.1126 (generation 3)
  Public key match: Intel ME, firmware versions 11.x.x.x
  The HAP bit is SET
  Reading partitions list...
   FTPR (0x00001000 - 0x0000a8000, 0x000a7000 total bytes): NOT removed
  Removing partition entries in FPT...
  Removing EFFS presence flag...
  Correcting checksum (0x98)...
  Reading FTPR modules list...
   FTPR.man     (uncompressed, 0x001448 - 0x002018): NOT removed, partition manif.
   rbe.met      (uncompressed, 0x002018 - 0x0020ae): NOT removed, module metadata
   kernel.met   (uncompressed, 0x0020ae - 0x00213c): NOT removed, module metadata
   syslib.met   (uncompressed, 0x00213c - 0x0021a0): NOT removed, module metadata
   bup.met      (uncompressed, 0x0021a0 - 0x00274a): NOT removed, module metadata
   pm.met       (uncompressed, 0x00274a - 0x0027f8): NOT removed, module metadata
   vfs.met      (uncompressed, 0x0027f8 - 0x003158): NOT removed, module metadata
   evtdisp.met  (uncompressed, 0x003158 - 0x0032e6): NOT removed, module metadata
   loadmgr.met  (uncompressed, 0x0032e6 - 0x00340e): NOT removed, module metadata
   busdrv.met   (uncompressed, 0x00340e - 0x0037b4): NOT removed, module metadata
   gpio.met     (uncompressed, 0x0037b4 - 0x0038fe): NOT removed, module metadata
   prtc.met     (uncompressed, 0x0038fe - 0x003aae): NOT removed, module metadata
   policy.met   (uncompressed, 0x003aae - 0x003c72): NOT removed, module metadata
   crypto.met   (uncompressed, 0x003c72 - 0x003dfc): NOT removed, module metadata
   heci.met     (uncompressed, 0x003dfc - 0x003fc8): NOT removed, module metadata
   storage.met  (uncompressed, 0x003fc8 - 0x0042c4): NOT removed, module metadata
   pmdrv.met    (uncompressed, 0x0042c4 - 0x0043e8): NOT removed, module metadata
   maestro.met  (uncompressed, 0x0043e8 - 0x0044d2): NOT removed, module metadata
   fpf.met      (uncompressed, 0x0044d2 - 0x0045de): NOT removed, module metadata
   hci.met      (uncompressed, 0x0045de - 0x0046e0): NOT removed, module metadata
   fwupdate.met (uncompressed, 0x0046e0 - 0x0047ea): NOT removed, module metadata
   ptt.met      (uncompressed, 0x0047ea - 0x0048f6): NOT removed, module metadata
   touch_fw.met (uncompressed, 0x0048f6 - 0x004a40): NOT removed, module metadata
   rbe          (Huffman     , 0x004a40 - 0x007100): NOT removed, essential
   kernel       (Huffman     , 0x007100 - 0x016d00): NOT removed, essential
   syslib       (Huffman     , 0x016d00 - 0x028d00): NOT removed, essential
   bup          (Huffman     , 0x028d00 - 0x050440): NOT removed, essential
   pm           (LZMA/uncomp., 0x050440 - 0x052a40): removed
   vfs          (LZMA/uncomp., 0x052a40 - 0x05a740): removed
   evtdisp      (LZMA/uncomp., 0x05a740 - 0x05c140): removed
   loadmgr      (LZMA/uncomp., 0x05c140 - 0x05eec0): removed
   busdrv       (LZMA/uncomp., 0x05eec0 - 0x060780): removed
   gpio         (LZMA/uncomp., 0x060780 - 0x061a00): removed
   prtc         (LZMA/uncomp., 0x061a00 - 0x0625c0): removed
   policy       (LZMA/uncomp., 0x0625c0 - 0x067200): removed
   crypto       (LZMA/uncomp., 0x067200 - 0x074d80): removed
   heci         (LZMA/uncomp., 0x074d80 - 0x078c80): removed
   storage      (LZMA/uncomp., 0x078c80 - 0x07d200): removed
   pmdrv        (LZMA/uncomp., 0x07d200 - 0x07e340): removed
   maestro      (LZMA/uncomp., 0x07e340 - 0x0800c0): removed
   fpf          (LZMA/uncomp., 0x0800c0 - 0x081940): removed
   hci          (LZMA/uncomp., 0x081940 - 0x082200): removed
   fwupdate     (LZMA/uncomp., 0x082200 - 0x086d40): removed
   ptt          (LZMA/uncomp., 0x086d40 - 0x09bd80): removed
   touch_fw     (LZMA/uncomp., 0x09bd80 - 0x0a8000): removed
  Relocating FTPR from 0x1000 - 0xa8000 to 0x400 - 0xa7400...
   Adjusting FPT entry...
   Moving data...
  The ME minimum size should be 344064 bytes (0x54000 bytes)
  The ME region can be reduced up to:
   00001000:00054fff me
  Setting the HAP bit in PCHSTRP0 to disable Intel ME...
  Removing ME/TXE R/W access to the other flash regions...
  Extracting and truncating the ME image to "extracted_me.rom"...
  Checking the FTPR RSA signature of the extracted ME image... VALID
  Checking the FTPR RSA signature... VALID
  Done! Good luck!

• Librem V4:
  ME/TXE image detected
  Found FPT header at 0x10
  Found 2 partition(s)
  Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
  Found FTPR manifest at 0x1478
  ME/TXE firmware version 11.0.18.1002 (generation 3)
  Public key match: Intel ME, firmware versions 11.x.x.x
  Reading partitions list...
   FTPR (0x00001000 - 0x0000a8000, 0x000a7000 total bytes): NOT removed
   MFS  (0x000a8000 - 0x00010c000, 0x00064000 total bytes): removed
  Removing partition entries in FPT...
  Removing EFFS presence flag...
  Correcting checksum (0x01)...
  Reading FTPR modules list...
   FTPR.man     (uncompressed, 0x001478 - 0x00207c): NOT removed, partition manif.
   rbe.met      (uncompressed, 0x00207c - 0x002112): NOT removed, module metadata
   kernel.met   (uncompressed, 0x002112 - 0x0021a0): NOT removed, module metadata
   syslib.met   (uncompressed, 0x0021a0 - 0x002204): NOT removed, module metadata
   bup.met      (uncompressed, 0x002204 - 0x0026a4): NOT removed, module metadata
   pm.met       (uncompressed, 0x0026a4 - 0x002752): NOT removed, module metadata
   syncman.met  (uncompressed, 0x002752 - 0x0027e8): NOT removed, module metadata
   vfs.met      (uncompressed, 0x0027e8 - 0x003148): NOT removed, module metadata
   evtdisp.met  (uncompressed, 0x003148 - 0x0032d6): NOT removed, module metadata
   loadmgr.met  (uncompressed, 0x0032d6 - 0x0033fe): NOT removed, module metadata
   busdrv.met   (uncompressed, 0x0033fe - 0x0037b0): NOT removed, module metadata
   gpio.met     (uncompressed, 0x0037b0 - 0x0038bc): NOT removed, module metadata
   prtc.met     (uncompressed, 0x0038bc - 0x003a6c): NOT removed, module metadata
   policy.met   (uncompressed, 0x003a6c - 0x003c36): NOT removed, module metadata
   crypto.met   (uncompressed, 0x003c36 - 0x003dc0): NOT removed, module metadata
   heci.met     (uncompressed, 0x003dc0 - 0x003f74): NOT removed, module metadata
   storage.met  (uncompressed, 0x003f74 - 0x004258): NOT removed, module metadata
   pmdrv.met    (uncompressed, 0x004258 - 0x00437c): NOT removed, module metadata
   maestro.met  (uncompressed, 0x00437c - 0x004466): NOT removed, module metadata
   fpf.met      (uncompressed, 0x004466 - 0x00455a): NOT removed, module metadata
   hci.met      (uncompressed, 0x00455a - 0x004704): NOT removed, module metadata
   fwupdate.met (uncompressed, 0x004704 - 0x00480c): NOT removed, module metadata
   ptt.met      (uncompressed, 0x00480c - 0x0048fe): NOT removed, module metadata
   touch_fw.met (uncompressed, 0x0048fe - 0x004a40): NOT removed, module metadata
   rbe          (Huffman     , 0x004a40 - 0x0070c0): NOT removed, essential
   kernel       (Huffman     , 0x0070c0 - 0x015dc0): NOT removed, essential
   syslib       (Huffman     , 0x015dc0 - 0x028a00): NOT removed, essential
   bup          (Huffman     , 0x028a00 - 0x051600): NOT removed, essential
   pm           (LZMA/uncomp., 0x051600 - 0x053f80): removed
   syncman      (LZMA/uncomp., 0x053f80 - 0x0544c0): removed
   vfs          (LZMA/uncomp., 0x0544c0 - 0x05c2c0): removed
   evtdisp      (LZMA/uncomp., 0x05c2c0 - 0x05dd40): removed
   loadmgr      (LZMA/uncomp., 0x05dd40 - 0x060b80): removed
   busdrv       (LZMA/uncomp., 0x060b80 - 0x063980): removed
   gpio         (LZMA/uncomp., 0x063980 - 0x064e00): removed
   prtc         (LZMA/uncomp., 0x064e00 - 0x065bc0): removed
   policy       (LZMA/uncomp., 0x065bc0 - 0x06c280): removed
   crypto       (LZMA/uncomp., 0x06c280 - 0x07be00): removed
   heci         (LZMA/uncomp., 0x07be00 - 0x07fec0): removed
   storage      (LZMA/uncomp., 0x07fec0 - 0x084640): removed
   pmdrv        (LZMA/uncomp., 0x084640 - 0x085e40): removed
   maestro      (LZMA/uncomp., 0x085e40 - 0x088d40): removed
   fpf          (LZMA/uncomp., 0x088d40 - 0x08a740): removed
   hci          (LZMA/uncomp., 0x08a740 - 0x08afc0): removed
   fwupdate     (LZMA/uncomp., 0x08afc0 - 0x08f840): removed
   ptt          (LZMA/uncomp., 0x08f840 - 0x0a3980): removed
   touch_fw     (LZMA/uncomp., 0x0a3980 - 0x0a8000): removed
  The ME minimum size should be 352256 bytes (0x56000 bytes)
  Checking the FTPR RSA signature... VALID
  Done! Good luck!
  

• X230's coreboot doesn't depend on Intel FSP binary blobs on the x230 nor any others. Librem's depend on those.
• There is no mechanical switch for the webcam nor microphone on X230, while those are isolated under QubesOS (microphone: dom0; not network, webcam: sys-usb; no network) and require explicit assignment to AppVM it will be used in prior to usage. A nice project exists to mod the X230/X220 but prototyping has not taken off by the community to simplify and make build reproducible enough to be included.
  
• Both X230 and Librems provide a wifi mechanical switch, while again, QubesOS isolates network from the rest of the system out of the box, relying on routing between defined gateways, firewalls and network. AppVMs that do not need networking doesn't.
  
• The PrivacyBeast strongly emphasize on the importance of setting a Disk Unlock Key, released by the TPM only if firmware measurements are known and user supplies the valid valid passphrase to unlock encrypted LUKS container with a second decryption key to boot QubesOS. This security measure mitigate the risk of having a third party record keystrokes and be able to unlock remotely the cloned disk, since the user doesn't type the Disk Recovery Key passphrase to boot his laptop. Purism chose to base their disk unlock feature on their USB security dongle and unlock the LUKS container when provided with passphrase for the security dongle (untested from me).

[Thierry Laurion]

Sorry for reposting. Previous mail badly formatted.

On Wed, Jan 1, 2020 at 3:16 AM Anil Eklavya <anile...@gmail.com> wrote:

Thanks for putting all this information in one place. I was earlier looking to buy Insurgio Privacy Beast, but it was not clear whether it could be shipped to India. I then ordered Librem 13.

 

Website does the simulation in costs for tax and shipping costs. If shipping address returns a shipping option, it can be shipped to you.

Is there any comparison available between these two, based on privacy and security considerations?

 

--

Thierry Laurion

--

Thierry Laurion

[Thierry Laurion]

On Wed, Jan 1, 2020 at 5:43 AM Lorenzo Lamas <lama...@gmail.com> wrote:

Hello Thierry,

Thanks for all that you are doing for the community. Do you see a possibility of a Qubes Certified Laptop with an AMD CPU?

There could be others certifying such models, but I won't do certification process for those.

Only model that would not have an Intel ME equivalent, doesn't rely on binary blobs etc would be the G505S which doesn't have enough SPI flash space to do anything interesting.

Intel is affected a lot more than AMD by the sidechannel vulnerabilities in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel stopped providing uCode updates for 1st gen in 2019, so this year is probably the last year they will support 3rd gen. More CPU vulnerabilities will most certainly be discovered in the coming years, so there is a need for an AMD based certified laptop, or at least a newer generation Intel based laptop, even though that may mean we're stuck with PSP or ME.

My personal path is to try to go away of x86 as fast as possible and try to move actual interest (chicken and egg problem) toward where we should really want to go.

I understand all the fuss around those CPU vulnerabilities, but mostly for the server use case, where everything NEEDS to be kept in memory. The concept that needs to be gripped here for workstations is that an information that is not in memory cannot be stolen. Getting the root of this concept, applied to QubesOS, which shuts off smt (HyperThreading) and enforces easy DisposableVMs usage, the user changing some of his habits and compartmentalize accordingly resolves most of the risks. Unsafe browsing? DisposableVM. Done with unsafe browsing? Close unsafe browser, which shuts down DisposableVM and deletes disk changes and memory content. Unsafe attachment? Open in DisposableVM. Often attach untrusted USB device to computer? Create a separate USB sys-usb-unsafe and affect distinct USB controller to it and always attach untrusted USB devices to that port only. Consider USB compartment as being temporary and never trust anything being in memory of that AppVM or its attached storage. Don't give network access to AppVMs not needing it.

To say it short, hardware will continue to have vulnerabilities. Those will continue to be really hard to patch. Users will have to change their habits in any case, the sooner the better. Now seems a good moment. The current race for better security enclaves, memory encryption etc won't save the day if closed and behind NDAs for code review and documentation access. The best protection a user can have is against himself. Combined with a root of trust that contains lesser to none untrusted binaries is the best scenario IMOHO, where untrusted binaries are isolated and untrusted at all time. Having ways to make users aware of harware casing tampering would be best. Supply chain not being a problem would be ideal but impossible, targeting and implants always being possible. Race conditions in accessing confidential information in memory is key.... Do you really need those 16 AppVMs opened at all time on older hardware :) Or worst. Have those 20 proprietary software running concurrently on your monolithic operating system disclosing information you don't know on you and other applications running at the same time? Habits.

Meanwhile, having a non-monolithic operating system on top of measured firmware containing less to none binary blobs, and verified boot on core components is the best we can have as a root of trust (RoT) perspective for end point devices. It always go down to the simple question: What do you put your trust in? My personal answer is: on hardware that is the most user-controllable as possible. And this is where my interest, time and energies are directed at. The lesser blobs the better.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/df275a80-4ca6-45f9-b284-1ae34fc41fc4%40googlegroups.com.

--

Thierry Laurion

[Chris Laprise]

On 1/1/20 5:43 AM, Lorenzo Lamas wrote:
> Hello Thierry,
>
> Thanks for all that you are doing for the community. Do you see a
> possibility of a Qubes Certified Laptop with an AMD CPU?
> Intel is affected a lot more than AMD by the sidechannel vulnerabilities
> in the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel
> stopped providing uCode updates for 1st gen in 2019, so this year is
> probably the last year they will support 3rd gen. More CPU
> vulnerabilities will most certainly be discovered in the coming years,
> so there is a need for an AMD based certified laptop, or at least a
> newer generation Intel based laptop, even though that may mean we're
> stuck with PSP or ME.

As much as I like the Insurgo/Purism/System76 offerings, this issue has
weighed on me to reconsider.

The massive amount of side-channel vulnerabilities have shown Intel's
engineering is reckless, and it gets worse. They're still pushing
fraudulent compiler code – detecting and de-optimizing AMD – almost a
decade after it was reported in the press. And they outright refuse to
pay government fines relating to their misconduct – which also included
threatening PC vendors with retaliation if they sell "too many" AMD units.

Historically, when a behemoth like Intel goes renegade its because they
know their products are superior and the public will accept the
situation as a trade-off. But the only thing that's "superior" about
Intel is their attitude and their ill-gotten revenue.

The biggest problem I see is peoples' willingness to go along with what
is becoming a tradition of anti-competition. Whatever logical fallacies
are put forward to make it seem palatable with CPUs will also undermine
user motivations in other areas.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Thierry Laurion]

Completely agreeing. This is why this needs collaboration to have real solutions in the future.

[Chris Laprise]

> <https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749>

> needs collaboration to have real solutions in the future.

The relative ease of using another x86 brand with better implementation
and ethics such as AMD makes it a clear choice in the meantime, while
the much more difficult and lengthy task of adopting open hardware is
pursued.

People can wait 18-36 months for a Qubes port to POWER architecture...
That is 18-36 months of being subject to maximum side-channel (and
probably other) risks and signalling a tacit acceptance of Intel's
engineering. And at the end of that period, we still won't have laptops.

Only holding out for the perfect appears to be the enemy of good in this
case; it is the wrong mindset for adding alternatives. Under these
circumstances, there should be absolutely no hint that a robust x86
alternative is somehow passe... but that appears to be the message
coming from vendors.

[Thierry Laurion]

I am not aware of any AMD model to recommend on my end which would have the good mix of QubesOS well supported components to fit requirements and warned compatibility issues.

If you have such model in mind to recommend, be part of the solution and let us know.

Meanwhile, models that fitted the bill for workstation/server got dropped by coreboot by lack of interest from the community (KGPE-D16). It might be brought back under grant work (TBD), but AFAIK, there is not such trust altogether from the community torward AMD, not really more trust torward their PSP (ME equivalent) and not so much known right now from attempts reversing it.

So what model would you suggest in the meantime for which firmware can be replaced by Open Source Firmware?

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--

Thierry Laurion

[Chris Laprise]

> <https://github.com/osresearch/heads/issues/134#issuecomment-368922440>). It

> might be brought back under grant work (TBD), but AFAIK, there is not
> such trust altogether from the community torward AMD, not really more
> trust torward their PSP (ME equivalent) and not so much known right now

> from attempts reversing <https://github.com/PSPReverse/PSPTool> it.

Yes, this has as much to do with community attitudes as anything else. I
would still expect some vendor to be able to put 2+2 together and market
AMD-based systems based on their history and current strengths.

If there is public mistrust bc of PSP, then there should be some
engagement from Coreboot and Libreboot to demonstrate that deactivation
is plausible. OTOH, since Coreboot seems stuck in c.2012 with Intel Ivy
Bridge processors, that could make the issue moot bc AMD units requiring
no such deactivation (containing no PSP) are available that are also a
year newer.

Regarding new hardware, which is important, I would rather take my
chances with AMD PSP firmware properly deactivating (when told to) than
with the equivalent Intel ME function. It would be interesting to
compare errata between the two brands on this point.

>
> So what model would you suggest in the meantime for which firmware can
> be replaced by Open Source Firmware?

Given that c.2012 machines are being discussed, I think its worth
mentioning the Lenovo G505s as a workable candidate. But I don't hang
out in Coreboot forums as much as I'd like, so I'd just assume ask you
the same question about what AMD models work? Is this something Insurgo
has looked into?

Complicating the issue is that Coreboot's documentation is 100% geared
to developers; the only guidance for users are links to OEMs. However,
the MrChromebox site lists AMD Stoneyridge c.2017 as Coreboot supported,
which makes models like Lenovo 14E chromebook and HP 15-BW077AX
candidates for testing and porting.

TBH, I'm not exactly sure why, from a consumer standpoint, open firmware
must be a prerequisite when the hardware itself is closed. Perhaps its
more important than correctly functioning CPU hardware, but perhaps not.
I think the perceived need that many have for it is rooted in reports
that some Intel ME versions don't deactivate properly, as deactivating
ME gained the Coreboot project a great deal of visibility.

[Guerlan]

Im running on a Razer Blade Steatlh 4k + touchscreen 2016 16gb RAM 512gb SSD i7 ultra thin. Everything works wxcept for the lid closing and opening but I'm trying to find a solution. Qubes runs very good on this laptop, I'm very happy!

[Thierry Laurion]

The same point being made toward newer Intel ME is made torward PSP: It is now part of the main CPU bringup, making PSP not completely removable. AGESA binary blobs are required for hardware initialization (coreboot shimboot), while the same situation applies to newer Intel hardware, requiring FSP (coreboot shimboot) on newer hardware. From a firmware development perspective (hardware firmware developers, please jump in) this requires NDA to access documentation, which complicates the process and increase costs, limiting the actual firmware development to a limited, resourceful, number of organizations. This reduces community collaboration proportionally.

As for Intel HAP bit that was discovered, as pointed out in this thread before, the binary blobs now required (not being trimmable) have increased since Sandy/Ivy bridge and now requires a signed kernel and syslibs block to be present, while Intel ME is asked gently to be deactivated, which permits to vendors to claim that ME is Neutered+Deactivated, without end users to really understand the binary blobs differences and what is still there.

The only point there that should make it obvious for everyone is that the FSF refuses to RYF certify neither newer AMD or Intel based platforms since the X200 for Intel, and the KGPE-D16 for AMD even though me_cleaner does its job, while Talos II obtained RYF certification in November 2019.

OTOH, since Coreboot seems stuck in c.2012 with Intel Ivy
Bridge processors, that could make the issue moot bc AMD units requiring
no such deactivation (containing no PSP) are available that are also a
year newer.

Regarding new hardware, which is important, I would rather take my
chances with AMD PSP firmware properly deactivating (when told to) than
with the equivalent Intel ME function.

 

Agreed, but would need some interest, reversing, and porting to coreboot. This is not my field, unfortunately.
coreboot people: HP ENVY 15z-j100? (but then Radeon graphics?)

Yet again, PSP will NOT be completely deactivated, per design, as post GM-45 (x200, libreboot, RYFed)

It would be interesting to
compare errata between the two brands on this point.

 

Absolutely! Who jumps in?

>
> So what model would you suggest in the meantime for which firmware can
> be replaced by Open Source Firmware?

Given that c.2012 machines are being discussed, I think its worth
mentioning the Lenovo G505s as a workable candidate. But I don't hang
out in Coreboot forums as much as I'd like, so I'd just assume ask you
the same question about what AMD models work? Is this something Insurgo
has looked into?

There are two AMD laptops models supported by coreboot as of now from what I gathered from yesterday homeworks: Lenovo G505s and the HP M6-1035DX.

The G505S is, as said previously in this thread, not really interesting for firmware integrity attestation perspective (Heads), not having a TPM and not having enough SPI flash space to do anything trustworthy.

So yeah, you can have a AMD corebooted system. But you can't verify that the rom you booted is the one you think it is, but if you externally backup it and compare it to its original image.

 

Complicating the issue is that Coreboot's documentation is 100% geared
to developers; the only guidance for users are links to OEMs. However,
the MrChromebox site lists AMD Stoneyridge c.2017 as Coreboot supported,
which makes models like Lenovo 14E chromebook and HP 15-BW077AX
candidates for testing and porting.

 

All of which are based on UEFI and their binary blobs. Additionally "This UEFI firmware does have a few limitations however: among other things, it lacks the ability to boot in Legacy Mode (often referred to as UEFI-CSM; this will likely never be implemented). It currently does not support TPM management or UEFI Secure Boot. The UI is also not as polished as other UEFI implementations, but that's open source for you :)"

Which is linuxboot like, without coreboot native initialization, replacing PEI part of UEFI.

This tendency of accepting more blobs everywhere for better performance, let it be in ARM, AMD or Intel, doesn't fit any trustworthyness by openness and actually encourages the whole industry in going that way, not just Intel engineering like you pointed at. It's "Open Source" as long as the code relies on closed source APIs. I disagree with that direction, personally.

TBH, I'm not exactly sure why, from a consumer standpoint, open firmware
must be a prerequisite when the hardware itself is closed.

Because the firmware controls the hardware until open source hardware exists altogether. Back to Sandy bridge once again, there is no FSP. There is native initialization, even the SMM is deactivate as early as possible by coreboot. Measurements of modules is done from the romstage under Heads. That is the state for the X230 as of now with Heads.

Having a PEI replacement makes you trust UEFI a bit less, while relying  on its initialization that was made prior of payload runtime.

And that is exactly my point trying to gather interest, development and funds toward supporting real alternatives for the future, without accepting ME nor its alternatives. Without accepting FSP and its alternatives. Relying to the lowest to none closed source firmwares present in the hardware.

As said previously in this thread, we had that with the KGPE-D16. And for the moment, support is dropped since most codepaths were incompatible with AGESA ones, and it drifted until support got dropped in last release.

Meanwhile, I encourage you to discuss QubesOS certification requirements with QubesOS peers:
"Another important requirement is that Qubes-certified hardware should run only open-source boot firmware (aka “the BIOS”), such as coreboot. The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see Intel FSP) as well as other internal operations (see Intel ME). However, we specifically require all code used for and dealing with the System Management Mode (SMM) to be open-source.

While we recognize the potential problems that proprietary CPU-vendor code can cause, we are also pragmatic enough to realize that we need to take smaller steps first, before we can implement even stronger countermeasures such as a stateless laptop. A switch to open source boot firmware is one such important step. To be compatible with Qubes OS, the BIOS must properly expose all the VT-x, VT-d, and SLAT functionality that the underlying hardware offers (and which we require). Among other things, this implies proper DMAR ACPI table construction."

And the question that arises is: What is Open Source Firmware nowadays?

And QubesOS being historically mainly if not exclusively supporting Intel hardware. Chicken and egg problem everywhere.

Perhaps its
more important than correctly functioning CPU hardware, but perhaps not.

To clarify the situation, I would also invite you to look at the optimizations on which side channels attacks relies. Some of which only targeting more recent silicons. Some targeting all silicon manufacturers.

This is not so clear cut as: AMD is better, maybe less targeted. I am not against AMD and would gladly join forces in supporting a model that fits the bill for privacy/confidentiality conscious people caring for their data at rest to be more secured while the transition is made. First by researchers, developers, integrators, offering alternatives to customers. As far as I see myself, I don't have the ressources to assemble a laptop as of now. The ones that have those resources to create new offers have to step up.

The best would still be, IMOHO, to be able to have CPU microcode updates for the lifetime of a CPU, and that again, means a required shift of how things are done from the industry. Its not just choosing parts to assemble to build hardware, but having silicon creators deciding to go open and actually doing it. Not creating Open Source certification, or doing Reddit AMA then nothing, but keeping promises and actually contributing in the Open Source ecosystem, reducing blobs, not augmenting their numbers and closeness. 

I think the perceived need that many have for it is rooted in reports
that some Intel ME versions don't deactivate properly, as deactivating
ME gained the Coreboot project a great deal of visibility.

 

Agreed. Which is why oreboot is alive and refuses to play with x86, altogether.

[Chris Laprise]

> <https://doc.coreboot.org/soc/amd/family17h.html>. AGESA binary blobs

> are required for hardware initialization (coreboot shimboot), while the
> same situation applies to newer Intel hardware, requiring FSP (coreboot

> shimboot) <https://doc.coreboot.org/soc/intel/fsp/index.html> on newer

> hardware. From a firmware development perspective (hardware firmware
> developers, please jump in) this requires NDA to access documentation,
> which complicates the process and increase costs, limiting the actual
> firmware development to a limited, resourceful, number of organizations.
> This reduces community collaboration proportionally.
>
> As for Intel HAP bit that was discovered

> <https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit>, as

> pointed out in this thread before, the binary blobs now required (not
> being trimmable) have increased since Sandy/Ivy bridge and now requires
> a signed kernel and syslibs block to be present

> <https://github.com/corna/me_cleaner/wiki/How-does-it-work>, while Intel

> ME is asked gently to be deactivated, which permits to vendors to claim
> that ME is Neutered+Deactivated, without end users to really understand
> the binary blobs differences and what is still there.
>
> The only point there that should make it obvious for everyone is that
> the FSF refuses to RYF certify neither newer AMD or Intel based
> platforms since the X200 for Intel, and the KGPE-D16 for AMD even though
> me_cleaner does its job, while Talos II obtained RYF certification

> <https://twitter.com/RaptorCompSys/status/1192579979613212673>in

> November 2019.
>
>
> OTOH, since Coreboot seems stuck in c.2012 with Intel Ivy
> Bridge processors, that could make the issue moot bc AMD units
> requiring
> no such deactivation (containing no PSP) are available that are also a
> year newer.
>
>
> Regarding new hardware, which is important, I would rather take my
> chances with AMD PSP firmware properly deactivating (when told to) than
> with the equivalent Intel ME function.
>
> Agreed, but would need some interest, reversing, and porting to
> coreboot. This is not my field, unfortunately.
> coreboot people: HP ENVY 15z-j100? (but then Radeon graphics?)
>
> Yet again, PSP will NOT be completely deactivated, per design, as post
> GM-45 (x200, libreboot, RYFed)
>
> It would be interesting to
> compare errata between the two brands on this point.
>
> Absolutely! Who jumps in

> <https://freundschafter.com/cybersecurity-cpu-and-system-alternatives-without-intel-me-iamt-and-amd-psp-secure-technology/>?

>
>
>
> >
> > So what model would you suggest in the meantime for which
> firmware can
> > be replaced by Open Source Firmware?
>
> Given that c.2012 machines are being discussed, I think its worth
> mentioning the Lenovo G505s as a workable candidate. But I don't hang
> out in Coreboot forums as much as I'd like, so I'd just assume ask you
> the same question about what AMD models work? Is this something Insurgo
> has looked into?
>
> There are two AMD laptops models supported by coreboot as of now from
> what I gathered from yesterday homeworks: Lenovo G505s and the HP M6-1035DX.
>

> TheG505S is, as said previously in this thread, not really interesting

> for firmware integrity attestation perspective (Heads), not having a TPM
> and not having enough SPI flash space to do anything trustworthy.

> <https://github.com/osresearch/heads/issues/453>

>
> So yeah, you can have a AMD corebooted system. But you can't verify that
> the rom you booted is the one you think it is, but if you externally
> backup it and compare it to its original image.
>
>
> Complicating the issue is that Coreboot's documentation is 100% geared
> to developers; the only guidance for users are links to OEMs. However,
> the MrChromebox site lists AMD Stoneyridge c.2017 as Coreboot
> supported,
> which makes models like Lenovo 14E chromebook and HP 15-BW077AX
> candidates for testing and porting.
>

> All of which are based on UEFI <https://mrchromebox.tech/#bootmodes> and

> their binary blobs. Additionally "This UEFI firmware does have a few
> limitations however: among other things, it lacks the ability to boot in
> Legacy Mode (often referred to as UEFI-CSM; this will likely never be
> implemented). It currently does not support TPM management or UEFI
> Secure Boot. The UI is also not as polished as other UEFI
> implementations, but that's open source for you :)"
>

> Which is linuxboot <https://trmm.net/LinuxBoot_34c3> like, without

> coreboot native initialization, replacing PEI part of UEFI

> <https://en.wikipedia.org/wiki/LinuxBoot>.

>
> This tendency of accepting more blobs everywhere for better performance,
> let it be in ARM, AMD or Intel, doesn't fit any trustworthyness by
> openness and actually encourages the whole industry in going that way,
> not just Intel engineering like you pointed at. It's "Open Source" as
> long as the code relies on closed source APIs. I disagree with that
> direction, personally.
>
>
> TBH, I'm not exactly sure why, from a consumer standpoint, open
> firmware
> must be a prerequisite when the hardware itself is closed.
>
> Because the firmware controls the hardware until open source hardware
> exists altogether. Back to Sandy bridge once again, there is no FSP.
> There is native initialization, even the SMM is deactivate as early as
> possible by coreboot. Measurements of modules is done from the romstage
> under Heads. That is the state for the X230 as of now with Heads

> <https://trmm.net/Heads_33c3>.

>
> Having a PEI replacement makes you trust UEFI a bit less, while relying
> on its initialization that was made prior of payload runtime.
>
> And that is exactly my point trying to gather interest, development and
> funds toward supporting real alternatives for the future, without
> accepting ME nor its alternatives. Without accepting FSP and its
> alternatives. Relying to the lowest to none closed source firmwares
> present in the hardware.
>
> As said previously in this thread, we had that with the KGPE-D16. And
> for the moment, support is dropped since most codepaths were
> incompatible with AGESA ones, and it drifted until support got dropped
> in last release

> <https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1140203-coreboot-4-11-brings-many-intel-improvements-new-support-for-supermicro-lenovo-boards?p=1140576#post1140576>.

>
> Meanwhile, I encourage you to discuss QubesOS certification requirements

> <https://www.qubes-os.org/doc/certified-hardware/> with QubesOS peers:

IMO, this is one of the logical fallacies that has reinforced Intel
dominance. In the case of side-channel attacks, most of them are
grounded in a basic theory of what could be exploited in poorly
engineered systems.. e.g. they are applicable across different
architectures with relatively little adjustment. What really underscores
this is that AMD x86 is the _same_ arch as Intel and researchers woke up
to the necessity to test both brands.

Also note that AMD has been forthcoming with information about
vulnerabilities while Intel has used tactics to prevent disclosure.

And look at the subsequent reactions from major integrators: Apple,
Google and Amazon. They all announced plans to get Intel-branded CPUs
out of their systems!

> not against AMD and would gladly join forces in supporting a model that
> fits the bill for privacy/confidentiality conscious people caring for
> their data at rest to be more secured while the transition is made.
> First by researchers, developers, integrators, offering alternatives to
> customers. As far as I see myself, I don't have the ressources to
> assemble a laptop as of now. The ones that have those resources to
> create new offers have to step up.
>
> The best would still be, IMOHO, to be able to have CPU microcode updates
> for the lifetime of a CPU, and that again, means a required shift of how
> things are done from the industry. Its not just choosing parts to
> assemble to build hardware, but having silicon creators deciding to go
> open and actually doing it. Not creating Open Source certification, or
> doing Reddit AMA then nothing, but keeping promises and actually
> contributing in the Open Source ecosystem, reducing blobs, not
> augmenting their numbers and closeness.

I agree that's important, too. Open firmware is becoming more of a
long-term goal that we can acheive alongside open hardware. Clearly its
not working out too well with closed hardware, and the closed firmware
might as well be considered a part of the hardware, IMO.

But that doesn't mean stopgaps can't be applied to x86 processors to
assuage fears about ME/PSP's main issue: attack surface. I can imagine
that even Intel and AMD might accommodate a request to open source the
specific code that activates/deactivates management functions.

[gorked]

I was also interested in a higher security laptop.   I feel the guys who create the Insurgo Privacy Beast are doing a lot more than just flashing the BIOS.  I am on Social Security, so I can not afford their Insurgo Privacy Beast.   I suspect that I might brick a Lenovo X230 trying to put Core Boot on it.  I know the guys at a local computer shop are capable, but they are not free, and I would have to take the risk of it going bad.

The Librem laptops are not quite in my price range, and I notice the posts by the developer of Qubes who is somewhat not happy with some of the direction of Librem development.   I am guessing the individual could tweak up some of the security issues on the Librem.  And a Librem is  better than not doing anything, but still prohibitively expensive for me at this time.   

I guess I am getting off the point.   I was looking at Chrome Books to run Qubes, and notice, 

https://github.com/bibanon/Coreboot-ThinkPads/wiki/Chromebook-Coreboot-Installation

My questions being, seems like there is some kind of thing about needing a computer build before 2012 to work properly.   Is this true?

Anyone work with a specific Chrome Book?   One can have its RAM increase to say 16 GB, and so on?   

For now, I have to work with what I have.   I have a mid 2009 Mac Book Pro, and will put another spinning drive in it.  Install OS X, the dual book to some version of Linux.  (I guess everyone here knows that is what Apple calls "Boot Camp")   Yes, I did put an SSD in it and try to just install Linux.   Something about it does not seem to shut down properly, and then I can not get it to boot at all.   No doubt not a problem to Linux groupies here.   I feel a dual boot with Boot Camp would resolve that issue.   I guess that is training wheels.  That may seem overly detailed, but my last question is:  I know nearly any version of Linux should work in the Apple, and I may try several, just for fun. I had hoped for a solid Linux stub to run a virtual machine on top of.  But which version of Linux should give me Security?  I had thought of CentOS or its Oracle twin.  Parrot OS looks interesting.  None of those are just basic stubs.   Thanks for reading this.  and for replying.    

[dhorf-hfre...@hashmail.org]

On Sat, Jan 04, 2020 at 05:48:29AM -0800, gorked wrote:

> Privacy Beast. I suspect that I might brick a Lenovo X230 trying to put
> Core Boot on it. I know the guys at a local computer shop are capable, but

the main "trick" here is to have a solid unbricking strategy.
if you have an external flasher, or a device with a clever
vendor firmware, the worst that will happen is you get to
curse and waste an hour of your time.
i wouldnt even recommend applying me_cleaner without _some_
strategy for recovering from a bad flash.

> My questions being, seems like there is some kind of thing about needing a
> computer build before 2012 to work properly. Is this true?

not sure what that means.
actualy, for chromebooks i would recommend "as new as possible".
all chromebooks with enough oomph ship with coreboot.
any documentation referencing Lewis tooling is outdated.
if you just want to liberate a chromebook without doing own
work on the firmware, MrChromebox tooling is the current way to go.

> Anyone work with a specific Chrome Book? One can have its RAM increase to
> say 16 GB, and so on?

i use qubes on two higher end chromebook models.
Acer CB713 (more pixels, smaller storage) and CB714 (fewer pixels, more
storage).
both have 16GB ram.
both are on the high end of the chromebook price range.
both can be maddening with their (lack of) internal storage performance.

all modern chromebooks with usbc also support external debug+flash
through a suzyqable.
very convenient if you want to explore custom firmware mods.