search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.41k stars 182 forks source link

Call for Collaboration to Apply to NGI "Privacy & Trust Enchancing Technologies" Grant #540

Closed tlaurion closed 2 years ago

tlaurion commented 5 years ago

Grant Information here: https://nlnet.nl/PET/ Form here: https://nlnet.nl/propose/

Framapad for grant proposal collaboration: https://mensuel.framapad.org/p/AQqOdrEBWr

Anyone wants to jump in?

tlaurion commented 5 years ago

Some ideas that needs to be picked up and integrated, don't know how to include them in paper yet: EDIT: Multiple additions. QubesOS will also apply to this for UX improvements.

Please comment all pertinent ideas!

Heads specific work

Hardware mods to streamline/for which open source blueprints needs optimizations

QubesOS related work

Create and deploy additional Salt recipes at QubesOS installation/new defaults that

Sent from my Galaxy S3 using FastHub-Libre

tlaurion commented 5 years ago

@merge @marmarek @osresearch @kakaroto @mfc : Any other improvements you would love to see happening into Heads Heads/QubesOS, integration of better privacy/confidentiality enforcing measures that would benefit all privacy conscious?

merge commented 5 years ago

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is. In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

tlaurion commented 5 years ago

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is.

@merge : #326? Never tested it though.

In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

@merge : It could be as easy as putting that here: export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

marmarek commented 5 years ago

@merge : It could be as easy as putting that here: export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

merge commented 5 years ago

thanks for the links and updates. sorry for the confusion. actually it's quite unrelated and not a good idea to mess with user's kernel commandline so much. All we need for a proper root of trust is (persistent until reboot-)write-protection of the flash as soon as possible unless the user chooses "upgrade" or something. Once we have that, it should really be irrelevant what iomem or others say.

We really need to verify whether that works for the X230's flash chips, and implement a user-friendly solution.

tlaurion commented 5 years ago

@merge : It could be as easy as putting that here: export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

@marmarek: agreed. But:

Following this, a whitelist seems overkill, io386 actually prohibits iomem=relaxed from being successfully used to reprogram the SPI flash from within OSes other then Heads which locks it. Following this, if io386 is in, removing iomem=relaxed from KERNEL_REMOVE is useless.

mfc commented 5 years ago

hey folks, just chipping in that the Qubes proposal I will draft will be focused on Qubes usability (integrating existing efforts that still haven't been reviewed/incorporated into the release) and internationalization/localization/accessibility support. so it will be a bit "conservative" in approach but filling in some very necessary gaps Qubes has.

I don't expect any overlap with these topics so the Heads/Qubes proposal can be as ambitious as desired! :)

snmcmillan commented 5 years ago

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks). ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I apologize for this text wall and if it's difficult to read.

tlaurion commented 5 years ago

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

@SebastianMcMillan : Agreed, with some personal limitations, see below.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Agreed, while again, the most free platforms (binary free of Intel FSP/no AMD PSP, me_cleaner neuterable Intel ME platorms containing only ROMP and BUP modules) should be priorized in that list. This is why I push so much the x230 right now and think that Ivy bridge first, and then sandy bridge second, based laptops should be supported more.

This doesn't mean that other platforms should not be added in parallel. My point here is that my own priority is to push most trustable hardware available today (binary blobfree 4.9 coreboot (graphic init, native ram init, etc) with Measured boot support, TXT support(optional), TPMv2 support) well supported/tested before integrating other platforms.

I invite others to collaborate on that and will gladly add those platforms in the points to be covered for the grant but won't do that work myself nor will be able to test those platforms, while inviting the community to do it and be paid for those contributions.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks).

Follow GSoC progress for ARM64 here. I'm personally more interested into PPC64 port, for the same reasons evoked above with even more user ownership possibilities (PowerPC notebook, Power9 completely open designs like the Talos II/BlackBird and others).

ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

TrustZone is IME equivalent. This is an interesting file to follow, but not all ARM architectures include virtualization extension, and from what I saw, the ones that does, for laptops, don't have enough memory to be minimally interesting for QubesOS(8Gb+). But that might change in the future.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

It's planned for QubesOS 4.1. EDIT see here: https://groups.google.com/d/msg/qubes-devel/CA7gHGQk5WE/JEfADyFaBAAJ

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I've roughly tested this myself and it works: Scripts Tablet support in QubesOS

I apologize for this text wall and if it's difficult to read.

No problem. :)

Edit: priorities

Sent from my Galaxy S3 using FastHub-Libre

snmcmillan commented 5 years ago

TrustZone

How did I forget this? That name makes me shudder every time I hear it. Thankfully, it's not a part of ARM in itself, and that not all current ARM devices have it (yet).

I do agree that testing is very important for a project like this, and that also putting more work more free platforms than others is a better choice (seeing how user trust is the entire point of this project). I wouldn't mind maintaining the T420 and X220.

Another thing I recall reading back in the later half of 2017 was that Libreboot was in the works for the X220 and that it would be released in 2018. Seeing how that never happened, I may try to find where I saw that and track down what caused that to never happen. If someone is able to somehow find a way to get rid of the blobs on the X220, that'll likely be relevant to other Sandy Bridge devices at the very least.

tlaurion commented 5 years ago

@SebastianMcMillan

Libreboot on x220 was conditional to the tiny possibility to have it RYF certified if IME could be completely wiped, which, thanks to Trammel and me_cleaner afterward, showed different level of disablement and not be completely possible from a deeper understanding of the dependency torward ME in firing up the main cpu. Creating debates and confusion on ME being deactivated/neutered/deleted.

RYF guidelines and conditions would have had to be modified to tolerate neutered IME (90Kb BUP and ROMP required modules to fire up main CPU on Ivy, even less on Sandy), which they didn't and still don't and probably won't do, since that cpu is still there and alive, running unknown code. I would consequently greatly doubt RYF certification criteria to change for that reason.

I think that debate for the x220 to be supported by libreboot happened on Reddit under Leah's name. The x220 product page can be found with web.archive.org for minifree.org.

Following me_cleaner work to not being able to completely delete IME like it was possible on gm45 (x200), Leah dropped the project. That's what I remember of it but my memories may not include all the details.

Edit: added archive.org link to the minifree x220

snmcmillan commented 5 years ago

That's the picture I seem to be getting as well. I apologize for getting a little off-topic with that thought.

tlaurion commented 5 years ago

@flammit, @marmarek, @mfc, @osresearch

Anything else to add? I'll begin working on the proposal in the beginning of the week.

Would gladly take reviews/corrections on the framapad link in first post while I go.

Sent from my Galaxy S3 using FastHub-Libre

tlaurion commented 5 years ago

Thanks to all that collaborated! The grant application was delivered in time!

tlaurion commented 5 years ago

Retained! Gonna be considered and evaluated against all other projects in the next 3 weeks before final approval/refusal:

It is my pleasure to inform you that your project "Integrating measurable security into daily lives" (2019-04-XXX) has been selected to enter the second round of the 2019-04 call, which means that your project likely fits the eligibility criteria. Given that the amount of remaining candidates still exceeds the available budget, there will be another strict selection round.

This means that your project now has to compete with the other proposals selected with regards to urgency, relevance and value for money. Unfortunately we will not be able to fund all projects proposed, as much as we would like that. For the next three weeks we will be thoroughly evaluating the remaining proposals for the second round, during which we may ask you to supply additional details. After that we will inform you on the outcome of this second (and final) selection round.

tlaurion commented 5 years ago

Passed! Last stage! @mfc @marmarek @blackmaria @merge @osresearch @SebastianMcMillan @kylerankin @zaolin @adrelanos

[...] you applied to the NGI0 PET open call from NLnet. Currently a selection of the projects is with the independent review committee to validate their eligibility, and we are happy to inform you that this includes your project "Integrating measurable security into daily lives" (2019-04-XXX).

Should your project pass that final hurdle, the selection will be made public and we will contact you to negotiate a Memorandum of Understanding. The final amount of the grant will be determined at that point.

We will then also need to share some information about the project both with the general audience and with the European Commission. In the interest of time, we ask you to prepare a one paragraph management summary of the project. For examples we refer you to https://NLnet.nl/thema/NGIZeroDiscovery.html and https://NLnet.nl/thema/NGIZeroPET.html

tlaurion commented 5 years ago

The "Finish porting Replicant to a newer Android version" fits similar general background behind this grant application.

The idea is to facilitate firmware/boot integrity attestation on more hardware platforms (Heads support for smaller SPI, broader support through coreboot VBoot measured boot subconfig: coreboot/Heads), ease accessibility and support of such hardware (OEM reownership (Heads) permitting QubesOS preinstallation, TXT support for AEM(Coreboot/Heads), additional hardening/anonymizing defaults through Salt (QubesOS/Whonix), Additional Hardware security(NSA-B-GONE x220/x230 prototype evolution) and new user support/integration (through hidden onion remote AdminVM administration (QubesOS/Whonix).

Anyone has the talent to write such executive summary? @BlackMaria?

BlackMaria commented 5 years ago

@tlaurion sure, I will try to write something for the one paragraph management summary of the project but I dont understand your point about the similarities with the android text?

IIUC our text only needs to be one paragraph and the examples are provided.

I will aim for tomorrow evening to write this. [ edit: I pinged you in slack, I posted a text ]

tlaurion commented 5 years ago

@BlackMaria : I was referring to the tone mainly of the executive summary, since it's about supporting more hardware and setting bases to ease further platform integration (most of the budget would go on that).

BlackMaria commented 5 years ago

This is my suggested text for such a proposal

The "Accessible Security" project's initiative was sparked by the need for usable security made available to the average citizen. Several projects are contributing a part of this bigger puzzle, QubesOS, coreboot, Heads, me_cleaner, Whonix and others, yet the average person does not have the sophistication to integrate these software projects. With some effort we can add some missing parts, help the effected projects usability, and facilitate access to cutting-edge developments, currently only usable by developers and more sophisticated users. Bringing these projects together will reduce the amount of expertise and effort required to benefit from these projects.

tlaurion commented 5 years ago

Project name changed to "Accessible Security" following Michiel request to ease internal communication exchanges about the project. Again, thanks to @BlackMaria to have this kind of brain which simplifies language! My brain is not good at that but yours is, definitely :)

tlaurion commented 5 years ago

@SebastianMcMillan said:

Another thing I recall reading back in the later half of 2017 was that Libreboot was in the works for the X220 and that it would be released in 2018. Seeing how that never happened, I may try to find where I saw that and track down what caused that to never happen. If someone is able to somehow find a way to get rid of the blobs on the X220, that'll likely be relevant to other Sandy Bridge devices at the very least.

@MagicFab @kylerankin @mfc @marmarek @SebastianMcMillan Update in regard of RYF certification guidelines.

Personal confusion on certifyable hardware criteria "product software" and Intel ME: https://www.fsf.org/resources/hw/endorsement/criteria

"However, there is an exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."

Would the Lenovo ThinkPad X230 be RYF certifyable https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME- firmware.md? Coreboot on this platform is FSP free with native ram init. Heads makes its root of trust (firmware) tamper evident through measured boot, while the /boot sha256sum digest is autogenerated at every boot while that digest is verified with user's GPG public key injected inside to detect any change. Intel ME with only the ROMP and BUP modules (previous link PoC) is considered "neutered" and the most trustworthy available platform for reasonably secure computing (QubesOS moto), having the possibility to meet their certification baseline and FSF RYF.

If the X230 is certifiable with Heads linux coreboot payload, then i'm interested in starting the process for RYF certification. The X230 i'm making, being under QubesOS certification https://github.com/osresearch/heads/pull/551 as the PrivacyBeast X230, will land public market in the next weeks and permit, for the first time, shipping of preinstalled Linux inside LUKS container, without the OEM having the possibility to hand to authorities encryption key or associated passphrase, the user reowning secrets, first thing, after having validated firmware and boot integrity prior to launch the re-ownership Wizard, leading to the re-encryption of its container and change of its passphrase through generated EFF diceware dictionary randomly chosen words.

Please clarify first quoted paragraph about RYF certification requirements to let me know if the neutered, Heads' Open Source Firmware powered X230 would fit your guidelines.

Thanks for checking in on this. We've been discussing this issue, but as of yet haven't come to a firm conclusion on neutralized Intel ME. We'll certainly raise the priority of that discussion, but I can't guarantee a time frame on when we'll reach a conclusion.

If you would like to go ahead and file an application for RYF certification, we can take a look for other potential issues. I've attached the application form and you can return it to ryf@fsf.org.

Thank you for working to make hardware that users can trust, and I hope to have an answer to your question soon.

-- Sincerely,

Donald R. Robertson, III, J.D. Licensing & Compliance Manager Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110, USA Phone +1-617-542-5942 Fax +1-617-542-2652 ex. 56

snmcmillan commented 5 years ago

The only issue with that is ME is updatable.

On Fri, Jun 14, 2019, 10:29 tlaurion notifications@github.com wrote:

@SebastianMcMillan https://github.com/SebastianMcMillan Update in regard of RYF certification guidelines https://www.fsf.org/resources/hw/endorsement/criteria. Contacted FSF, waiting for clarifications, since, from what I undertand, Intel ME is considered an exception: "However, there is an exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/540?email_source=notifications&email_token=AFNTUNBMYDETABPQEMA6XBTP2O2O5A5CNFSM4G76LDG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXXEHGI#issuecomment-502154137, or mute the thread https://github.com/notifications/unsubscribe-auth/AFNTUNGEEATHMDA46V6CBKTP2O2O5ANCNFSM4G76LDGQ .

tlaurion commented 5 years ago

@SebastianMcMillan

The only issue with that is ME is updatable.

As is the EC in laptops, the microcode updates for processor (now required....), TPM firmware, hard drive firmware, etc.

The GM45 (x200) was certified in a time microcode updates were a probable prejudice to security, while right now, not having them applied is the prejudice to security. The EC in GM45 was upgradeable, while still certifiable. As is the firmware of the hard drive.

The question being what are they considering acceptable. The open source SSD/HD firmware is still not readily accessible. But closed source is tolerated on that level. The X200 was certified even with those closed source components.

Everything is upgradeable with physical access.

The point being, I think, that once SPI is locked down (#326) or measured (not done actually, but measurements could be extended with something like #493 (complete rom read measurements, SPI address range measurements or modules measurements) or VBOOT/measured boot in coreboot 4.9+ to include ME integrity checks), what would be RYF certifiable.

I wrote back an e-mail dissecting differences in vocabulary currently used to describe Intel ME states. Removed(GM45 RYF certified)/Neutered (ROMP BUP + AltMeDisable bit) /Neutralized or Deactivated (AltMeDisable bit/ HAP bit while modules still being in SPI [kernel syslib and rbe]).

Waiting for a feedback in their currently made/to be made differentiation.

tlaurion commented 5 years ago

@zaolin @marmarek @BlackMaria @mfc @osresearch @kylerankin @adrelanos @merge

Project receives grant :)

mfc commented 5 years ago

Qubes just received confirmation as well :)

tlaurion commented 5 years ago

@zaolin @marmarek @BlackMaria @mfc @osresearch @kylerankin @adrelanos @merge NGI0-intakedocument.pdf

As stated in this document, it is expected to have smaller deliverables, so that the funds are transmitted directly to you from NLNet, every two weeks upon completion of tasks. You are responsible to create your own timeline. The results must be public and reproducible.

Questions?

tlaurion commented 5 years ago

Heads/Coreboot specific work

@zaolin

mfc commented 5 years ago

FYI just had call with NLNet regarding our own grant and to be clear, a timeline is not very important, just the deliverables. you can ask for funds for a completed deliverable (or sub-task) right after you complete it, or months later if that is useful for you.

Thierry I am assuming since you are the point of contact on this grant you will make clear who is working on which deliverables, get their consent and confirmation on it and the associated costs, and if there are any deliverables missing owners that you will flag that and we can find folks to work on them.

edit: you are doing these things, great :D

tlaurion commented 5 years ago

QubesOS/Whonix related work

@marmarek @adrelanos

Create and deploy additional Salt recipes at QubesOS installation/new defaults that