11 ms·

Open source firmware is important for security

615 points by eindiran 7y ago

subway 7y ago
Awesome post, but a very minor nitpick: > Chromebooks use both, coreboot on x86, and u-boot for the rest. This isn't entirely true. Coreboot is used on a number of ARM Chromebooks, including rk3288 and rk3399 based devices. It seems like u-boot is used less and less in the space. Libreboot has builds for a few devices that kill the annoying "untrusted os" message, and even allow you to set your own trust root.
- sneak 7y ago
  Is there a way to flash Pixelbooks? Being able to reflash a current nvme Pixelbook with my own trust root and build and sign my own OS images would be super excellent. The platform security of the Pixelbook is lovely; the only way it could be better is if I were able to control it.
  - subway 7y ago
    I'm not sure -- I haven't messed with a Pixelbook. On Chromebooks, the trust root lives in the bootloader's flash with no security beyond the write protect screw. A quick googling led to a reddit post that indicates it's possible with the Pixelbook, but likely a PITA: https://www.reddit.com/r/PixelBook/comments/7kv944/does_anyone_know_how_to_disable_writeprotection/drsxfny/ https://www.reddit.com/r/PixelBook/comments/7kv944/does_anyo...
  - aspenmayer 7y ago
    https://mrchromebox.tech https://mrchromebox.tech
yingw787 7y ago
Great blog post Jess! I think this is an extension of Kerckhoff's Principle that a secure cryptosystem should be able to keep your data secure even if everything (except the key) is compromised: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle Is there a Dockerfile or bash script anywhere that demonstrates how to install all these tools on bare metal? I operate at a higher level in the tech stack and I'm unfamiliar with these tools and how they work. A Dockerfile would be nice because then you could create a virtualish environment where you could play with the new stuff in docker exec before blowing away the old stuff.
- justincormack 7y ago
  Hey, also look into post compromise security eg see https://eprint.iacr.org/2016/221.pdf https://eprint.iacr.org/2016/221.pdf This stuff is way off Dockerfile level, sorry.
- mlaretallack 7y ago
  I would start with qemu and uefi coreboot. Docker is too high level for this.
- voltagex_ 7y ago
  Not a dockerfile, but it may be worth looking at buildroot [0] and qemu [1]. I'd like to say that I started 5 years ago with these tools and ended up working on embedded systems, but it's more like I started 5 years ago and ended up with drawers full of unsupported ARM boards. 0: https://buildroot.org https://buildroot.org 1: https://www.qemu.org/ https://www.qemu.org/
sneak 7y ago
Slightly offtopic, but relevant: Note that the recently-popular "Docker Desktop" product (I believe it uses the xhyve framework in OSX) that brings up a VM to run a linux-based Docker daemon on a local OSX system is not f/oss. The source isn't even publicly available. It surprised me when I found out, considering that all of the other tools shipped by Docker have been.
transpute 7y ago
Videos from the 2018 Open Source Firmware conference are available: https://osfc.io/archive https://osfc.io/archive See also "Firmware is the new Software" from Trammell Hudson, https://www.platformsecuritysummit.com/2018/speaker/hudson/ https://www.platformsecuritysummit.com/2018/speaker/hudson/ > Secure firmware is the foundation of secure systems. If we want to build slightly more secure systems they will require open, auditable and measured firmware. If we can’t read and audit the firmware code, we can’t reason about what is going on during the critical phases of the boot process; if we can’t modify and reproducibly build the firmware, we can’t fix vulnerabilities or tailor it to our needs; and if the firmware isn’t measured and attested, we can’t be certain that our system hasn’t been tampered with.
josteink 7y ago
I’m curious about NERF. What hardware do I need to run it? Is the HW-support as limited as Coreboot? And what do I do if I decide it’s not for me? Are there known safe ways to revert to your mainboards factory firmware?
classichasclass 7y ago
I'm surprised there is no mention of the Raptor Talos II, which is designed to be auditable in exactly this fashion.
- Lutzb 7y ago
  I am also perplexed why the Raptor Talos II does not receive more attention in the open hardware/software community. For me it is basically everything I've ever wanted from a libre system.
  - monocasa 7y ago
    Because it costs as much as my car and has been on backorder for a long time?
    - jancsika 7y ago
      Just curious-- what kind of car?
      - phaer 7y ago
        > Starting at $5,649.00 > Current Status: Backordered For the workstation: https://www.raptorcs.com/content/base/products.html https://www.raptorcs.com/content/base/products.html Fantastic machine, but sadly still 2 or 3 times as much as many people, including me would spend for a workstation.
        jancsika 7y ago
        The criticism as I understood it was, "I can get a car for that!" To really sting, that criticism should imply a decent run-of-the-mill car, not a clunker. Therefore, I wanted to know the car make/model. Because $6,000 for a decent run-of-the-mill car isn't bad.
      - monocasa 7y ago
        2004 Infinti G35X
deleted 7y ago
[deleted]
acd 7y ago
Agree with the author that UEFI is bad for security. You have this huge binary UEFI blob in a pre os boot environment that does not run open source. After the motherboard,laptop manufacturer looses interest and they loose interest as soon as the product does not sell more new products UEFI remains unpatched and insecure. The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source. Management processors like Intel ME built into the CPU, firmware another x86 insecurity.
- fghtr 7y ago
  >The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source. I do not see why it would be different for any other software.
  - jraph 7y ago
    It's not, in my opinion. And if the piece of software is simple and dumb, I don't really see why it should not be open source neither.
  - adrianratnapala 7y ago
    Well simple and dumb generally is good for all engineered things, as long as they aren't so dumb that they can't do their job. This principle applies especially well to boot loaders, because the job of a bootloader is to hand control off to some other, more sophisticated piece software.
  - marcosdumay 7y ago
    Well, you can sandbox anything that is loaded on top of a Free layer, you computer's boot firmware is certainly not on such place.
- parentheses 7y ago
  Unpatched UEFI is more about the reputation of the manufacturer/provider of UEFI. If a major manufacturer releases a motherboard, you can be sure (1) they are patched often and (2) they use similar components across many motherboards so bugs and vulnerabilities are patched across many simultaneously are worked out sooner
fghtr 7y ago
Although mentioned in the article, I would like to emphasize that https://puri.sm https://puri.sm are selling laptops with disabled and cleaned (with me_cleaner) bios. I hope more companies follow.
- tty2300 7y ago
  The purism devices look great but they are so expensive and its really hard to justify a $900 phone that has worse specs than my old $300 one
- metildaa 7y ago
  Purism seems to be rather inept, they shat the bed with their recent Librem One product launch, whereby they rebranded Tusky and disabled all moderation tools on their Mastodon instance, then were suprised when their employees started quiting due to this ridiculous behaviour. Purism doesn't seem to want to invest in the software that makes their services work, hence the commentary by Matrix devs on which services are helping to push development forward (and thus deserve subscribers).
  - ptx 7y ago
    Where can I read the details of this? (I have preordered a Librem 5. Employees quitting doesn't sound good.)
    - metildaa 7y ago
      https://social.libre.fi/objects/140ca2e8-addd-4dbb-8e03-8d6affd5f724 https://social.libre.fi/objects/140ca2e8-addd-4dbb-8e03-8d6a... Gnome dev ended his contract with Purism over their inept management of the Mastodon instance they are selling accrss to: https://wandering.shop/@KelsonV/102057489260188127 https://wandering.shop/@KelsonV/102057489260188127
- PascLeRasc 7y ago
  System76 also does this for some machines: https://news.ycombinator.com/item?id=15819636 https://news.ycombinator.com/item?id=15819636
yc-kraln 7y ago
This is a very PC centric article, but the same can be said about any connected device--from cars, to baby monitors, to buttplugs. If it has an internet connection, the firmware should either be open source or in open source escrow, so that if the company dies or decides to not support their device anymore, the hardware itself can continue to live.
- crispyambulance 7y ago
  > open source escrow I think that's a good idea, but ARE there real and reliable escrow agents for this kind stuff? Is it better than, say, a gentleman's agreement to make the source public on github (or some other channel) upon dissolution of company?
  - rtempaccount1 7y ago
    Software escrow agents are definitely a thing (e.g. https://www.nccgroup.trust/uk/our-services/software-escrow-and-verification/ https://www.nccgroup.trust/uk/our-services/software-escrow-a... ) (Disclaimer, I work for that company, but not in the escrow area)
- jraph 7y ago
  A concrete argument for this: Qualcomm recently released a patch for a vulnerability that makes it possible to access private data stored in the TrustZone of many of its SoCs: https://www.nccgroup.trust/us/our-research/private-key-extraction-qualcomm-keystore/ https://www.nccgroup.trust/us/our-research/private-key-extra... The patch needs to be provided by phone and tablet manufacturers. Except that many otherwise capable phones are not supported anymore and will not be fixed. Were the firmware of these devices open source, the community could fix this (given that the firmware does not have to be signed, or a signing key can be added). But no, many devices will remain forever vulnerable. Including my phone, 4G RAM, 32G internal storage, excellent battery and screen, great computing capabilities, in a excellent physical shape. Will probably last a few years more. Last updated on November 2017 by its manufacturer. Some parts will never be updated again and there is no way to audit this stuff. This is a shame. Edit: and I'm lucky my phone resembles an Android One phone, so some stuff can be taken from this phone to update mine.
nickpsecurity 7y ago
Nice article. A few comments: “Rings 1 & 2 - Device Drivers: drivers for devices, the name pretty much describes itself.” STOP and GEMSOS did use four rings. The evaluators griped that UNIX’s didn’t. Microkernel proponents kept pushing mainstream OS’s to move drivers from kernel mode to another mode. Maybe my memory is off again but arent the drivers for Nix’s and most monolithic kernels in kernel mode (Ring 0)? Maybe Xen does something different with its use of protected mode. Then, some things in user-mode later on like FUSE. “Each of these kernels have their own networking stacks and web servers. The code can also modify itself and persist across power cycles and re-installs. We have very little visibility into what the code in these rings is actually doing” Which is why I put money down that the backdoors NSA paid for in direct money and/or defense contracts would be in management systems. That we’d definitely find services with 0-days in there. Sure enough… “Linux is already quite vetted and has a lot of eyes on it since it is used quite extensively.” That’s total nonsense. Empirical evidence below that’s been consistent over long periods of time. If anything, using Linux is guaranteeing you vulnerabilities if they can call anything in the kernel. If a subset or just one function, maybe OK. Careful analysis case by case on that. We’d be better off with something clean-slate for this purpose that can reuse Linux drivers where necessary. Then, we’d check the drivers and the interfaces. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... It is true that it’s better than the closed-source stuff they’re using, has better tooling, folks understand it better, and so on. All true. “We need open source firmware for the network interface controller (NIC), solid state drives (SSD), and base management controller (BMC).” The problem with this and Intel/AMD internals are that they’re secretive partly to avoid patent suits and new competition. You’re not getting this stuff opened. Not easily at least. Might be better to literally do a closed-source product for them vetted by multiple parties. Otherwise, get the actual specs under NDA to build the open-source code against in a way that doesn’t leak the specs a lot. Alternatively, gotta build your own hardware doing this yourself with whatever the I.P. vendors give you. I mean, good luck on the reverse engineering efforts but these are usually lagging behind. “We need to have all open source firmware to have all the visibility into the stack but also to actually verify the state of software on a machine.” You actually need open, secure hardware for that since attackers are now hitting hardware. I kept telling people this would happen. Just wait till they do analog and RF more. What she’s actually saying here is “verify the state of the machine if the hardware works and is honest and doesn’t do anything malicious between verifications.” “ is the same code running on hardware for all the various places we have firmware. We could then verify that a machine was in a correct state without a doubt of it being vulnerable or with a backdoor.” Case in point: I put a secret coprocessor on the machine for “diagnostic purposes,” it can read state of system, it can leak over RF or network, and we leak stuff out of that signed, crypto code. Good thing no major vendors are including hidden or undocumented coprocessors on their chips. ;) “Chromebooks are a great example of this, as well as Purism computers. You can ask your providers what they are doing for open source firmware or ensuring hardware security with roots of trust.” End with some good advice: buy stuff that’s more open and secure to get more of it. Market demand incentivizing suppliers. That could solve a lot of these problems if enough people do it.
dopamean 7y ago
I have a completely honest question here that I'm hoping some people can answer. Is open source really more secure? My default answer would be yes absolutely but when I think about it I'm not sure I understand why. If something is open source then bugs and security problems can be found more easily and then fixed. This sounds great to me and I'm sure that works out just fine most of the time. This makes me wonder though...are there really fewer intrusions into production systems that are built entirely on open source software than there are in ones built with lots of proprietary, closed source software? What does the data look like about this stuff?
- seanhandley 7y ago
  I guess it's the principle of "many eyes make all bugs shallow". If the source is freely available, then every day someone is going to read it and maybe see/fix the bug. You can't know what bugs are in code for which you do not have the source, and the pool of people reading it is likely to be much smaller.
  - krapp 7y ago
    >If the source is freely available, then every day someone is going to read it and maybe see/fix the bug. How many years did Heartbleed go unnoticed? How many exploits in open source software get reported here? It's not true that someone reads all of the open source code every day. The truth is, few people ever read any of it, and fewer still have the domain expertise necessary to be able to spot and patch any obvious bug, much less subtle ones. And yet this metaphysical belief in the "many eyes" persists. Sure, it exists, but there are supposed to be eyes on the proprietary code as well, and the effect is probably smaller than people think, with no one outside of a project's maintainers ever actually studying the code for most open source projects.
    - marenkay 7y ago
      I'd like to add one thing to this: Heartbleed also went unnoticed because the OpenSSL code ad build process was in such a state that simply looking at it, and having to build it costs an insane amount of effort. So if you truly want to benefit from open source firmware, it needs to also come in at least some minimal form of quality. Things such as good build documentation, automated builds in CI, and also low requirements for setting up development builds are a thing often not present in software all of us deem critical. It is much more intriguing to contribute to a project, use it and submit improvements when the entrance barriers are low.
shmerl 7y ago
I wish AMD would provide open source AGESA, GPU firmware and CPU microcode.
- warmwaffles 7y ago
  Opensource GPU firmware I am willing to bet has license issues if they were to try and go open source.
  - shmerl 7y ago
    Not according to AMD. It's more an organizational issue, since to make it open, they'll need to maintain two versions. One without DRM garbage (HDCP), and one with it. And it costs more to do it naturally. As usual, DRM poison ruins technology.
Paianni 7y ago
The Socionext E-series Developerbox has open source firmware and is at least cheaper than the Raptor stuff.
- classichasclass 7y ago
  It's a nice system, and definitely cheaper, but it isn't a reasonable price comparison as it isn't even remotely in the same performance ballpark as POWER9. https://www.phoronix.com/scan.php?page=article&item=arm-24core-developer&num=1 https://www.phoronix.com/scan.php?page=article&item=arm-24co...
  - iamnothere 7y ago
    Depends on the workload and the # of cores in the POWER9 chip(s). The Socionext has 24 cores! Edit: Admittedly only massively parallel workloads will be faster than the POWER9, and only if the POWER9 has limited cores. A bit of a stretch for most use cases.
matthewfcarlson 7y ago
I agree- this is a very PC focused article but firmware is everywhere. It needs to be updateable and making it open makes it far easier to update. As far as UEFI goes, I'd just like to point out Microsoft's open source Firmware efforts (Project Mu). https://microsoft.github.io/mu/ https://microsoft.github.io/mu/ The goal is to make firmware easier to service and easier to update with security fixes for older projects. While it's not perfect, it is a great step forward. I think we need to see more of this in the future from other companies. (Disclaimer: I work for Microsoft and contribute to Project MU).
- nixpulvis 7y ago
  Reading up on Project MU now, and I'm sorry, what is this about firmware as a service? This seems like exactly what I don't want. XaaS (X as a Service) is great when there's something external that is only temporarily or optionally required, (or too expensive). Otherwise it's an ongoing dependency. But with firmware, once I own the hardware, I should own the firmware too. Without knowing more about this specific Firmware as a Service I can only imagine how this will actually look. Maybe it just means that updates are automatic? Even that alone is an interesting debate. Otherwise, Prohect MU looks like a modern wrapper around UEFI, what's being done to address the fundamental issues? Firmware code running after boot, modifications to firmware possible by changing code between boots, etc...
  - kr99x 7y ago
    The only firmware code running after boot that UEFI mandates is not below ring 0 and is fully optional - called only if and when the OS asks for it. The UEFI runtime services table is not a kernel and is parked in ordinary memory waiting to be jumped to/called. SMM is supported but not mandated, which is exactly how any hardware feature should be treated. Blame those enabling the SMM code you don't like. Or blame the hardware manufacturer for putting the feature in at all. UEFI is not your enemy. Its only sin is being overly complicated, which is (somewhat) debatable given the complexity of systems and OSes needing to be bootable.
    - 7y ago
nixpulvis 7y ago
Great overview of much of the firmware and general "OS" stack (for lack of a better word). I'm surprised not to read a mention of the micro-code which all instructions our programs ask the processor to run actually convert to. I suppose that's starting to get too close to a discussion of open hardware, which this post mostly sidesteps. Both are important issues.
sara7262 7y ago
They found world's biggest fish Even you can't believe how big fish is this That's unbelievable http://bit.ly/2FHl4pM http://bit.ly/2FHl4pM A cute dog is dancing in video Just watch this video and try to control your laugh http://bit.ly/2ZK1XVs http://bit.ly/2ZK1XVs See how a Turkey saved the life of his friends Even those birds also have love in their hearts http://bit.ly/2WhAiZS http://bit.ly/2WhAiZS Sometimes our feet smell are so bad even we feel ashamed due to our feet smell Now you can get rid from this just follow this simple method https://zoomtips.blogspot.com/2019/04/Smelly-feet.html https://zoomtips.blogspot.com/2019/04/Smelly-feet.html Guy made world record He drive car on two wheels See his video how he is driving http://bit.ly/2ZOYaWX http://bit.ly/2ZOYaWX
ignoramous 7y ago
I wish the smartphone side of things gets more attention and someone engineers their way to an open source baseband firmware ala OpenWrt [0]. Not sure why after the breakthrough for GSM/2G with OsocomBB [1], no viable libre alternative LTE or 4G has emerged [2]. The smartphone is an always-on, always-connected computer with 2B or more (30% of world's population) unsuspecting (to almost a point of being gullible) BSD/Linux users who are exposed and don't even know it, to an unprecedented degree, to adversaries with deep pockets (ad-networks [3], nation-states [4], carriers [5]) who don't need a second invitation. Most of the privacy and security battles, I feel, will be won and lost with smartphones. That's discounting IoT security altogether which is a scary proposition in itself for rather silly reasons [6][7]. RMS has had the right idea all along? -- [0] https://news.ycombinator.com/item?id=6722292 https://news.ycombinator.com/item?id=6722292 [1] https://news.ycombinator.com/item?id=8987931 https://news.ycombinator.com/item?id=8987931 [2] https://news.ycombinator.com/item?id=8813098 https://news.ycombinator.com/item?id=8813098 [3] https://news.ycombinator.com/item?id=11265751 https://news.ycombinator.com/item?id=11265751 [4] https://news.ycombinator.com/item?id=3295341 https://news.ycombinator.com/item?id=3295341 [5] https://news.ycombinator.com/item?id=17081684 https://news.ycombinator.com/item?id=17081684 [6] https://news.ycombinator.com/item?id=17785162 https://news.ycombinator.com/item?id=17785162 [7] https://news.ycombinator.com/item?id=11266796 https://news.ycombinator.com/item?id=11266796
commandersaki 7y ago
Curious what the author thinks about open sourcing the secure enclave co-processor in iPhone/iPad/etc.
farshaddx619 7y ago
پودر جوانه گندم https://20to20.ir https://20to20.ir خرید عطر http://20to20.biz http://20to20.biz دانلود آهنگ جدید http://dlfun.ir http://dlfun.ir دانلود موزیک ویدیو جدید http://downloadbazan.ir http://downloadbazan.ir خبرهای بدون سانسور http://zamennews.ir http://zamennews.ir دانلود آهنگ جدید بندری http://reza-sadeghi.ir http://reza-sadeghi.ir http://top-store.ir http://top-store.ir http://reza-sadeghi.vcp.ir http://reza-sadeghi.vcp.ir http://bigstars.persiangig.com http://bigstars.persiangig.com خرید خرما http://sepandtd.com http://sepandtd.com mazafati date http://livco.nl http://livco.nl http://bidestan.com http://bidestan.com travel to Iran http://irantours.biz http://irantours.biz http://the20.4kia.ir http://the20.4kia.ir https://20to20.shopfa.com https://20to20.shopfa.com http://the20.somee.com http://the20.somee.com https://drfniazi.ir/what-we-offer/ https://drfniazi.ir/what-we-offer/ http://ow.ly/AsAK30ot8n4 http://ow.ly/AsAK30ot8n4 http://free-ad.ir http://free-ad.ir https://gitlab.com/farshaddx619/20to20.ir https://gitlab.com/farshaddx619/20to20.ir https://gitlab.com/farshaddx619/20to20 https://gitlab.com/farshaddx619/20to20
peter_retief 7y ago
Great overview, I have had many disagreements with IT managers that blame open source for security breaches.
workrockin 7y ago
First of all love it that someone is thinking about bootloaders. Thank you and I hope you're successful in this project. I think that the article though is only targeted towards desktop PC/laptop/servers and mobile phones. Also not sure whether the it is talking about first level bootloader vulnerabilities or of second level bootloader vulnerabilities. In the embedded world there often is no second stage loading, there are simply bootloaders. There are many, many bootloaders and opensource is the most popular option here, both first and second level. Here's a table of hardware filtered by the booloaders used https://openwrt.org/toh/views/toh_admin_bootloader https://openwrt.org/toh/views/toh_admin_bootloader - around 800 device types use uboot - around 200 use cfe Both of them are opensource. I think we can use the research done opensource router os like openwrt[1] to design a BIOS that works across all devices. One interesting point to note here is that in many routers entire bootloader can be replaced easily using network booting. It takes seconds to flash the ROM (network booting is in-secure in theory but secure in practical since you need physical connectivity to book via a network). While many modern machines support network booting,replacing the first level bootloader (BIOS) is (impossibly) hard. Distributions of linux use GRUB which is nice and also opensource. But again its a second stage bootloader that comes into play after BIOS (first stage bootloader) has been executed. I'd love to see more development in u-boot as they have already done the hard work of supporting multiple devices [2] and amazingly they also support direct booting from an SD card (not an sd card adapter via a usb stick). Here is the list of architectures supported /arc /arm /m68k /microblaze /mips /nds32 /nios2 /openrisc /powerpc /riscv /sandbox /sh /x86 Another key point to note is as a user there is very little control that I have on my bootloader (first level). Since it is loaded from a ROM which I can't replace/rewrite even if opensource firmware exists I can't use it. While I can install a new operating system I have not found any easy way to switch firmwares. Unless a project like linux foundation takes it up and brings together the stake holders to use an opensource firmware I think it will be really difficult to get adoption. On the other hand bootloader is probably the only piece of software left that gives device manufactures some kind of control over their hardware. What's in it for them to use a free opensource technology? [1] https://openwrt.org/docs/techref/bootloader https://openwrt.org/docs/techref/bootloader [2] https://en.wikipedia.org/wiki/Das_U-Boot https://en.wikipedia.org/wiki/Das_U-Boot

615 points by eindiran 7y ago

Awesome post, but a very minor nitpick: > Chromebooks use both, coreboot on x86, and u-boot for the rest. This isn't entirely true. Coreboot is used on a number of ARM Chromebooks, including rk3288 and rk3399 based devices. It seems like u-boot is used less and less in the space. Libreboot has builds for a few devices that kill the annoying "untrusted os" message, and even allow you to set your own trust root.

sneak 7y ago
Is there a way to flash Pixelbooks? Being able to reflash a current nvme Pixelbook with my own trust root and build and sign my own OS images would be super excellent. The platform security of the Pixelbook is lovely; the only way it could be better is if I were able to control it.
- subway 7y ago
  I'm not sure -- I haven't messed with a Pixelbook. On Chromebooks, the trust root lives in the bootloader's flash with no security beyond the write protect screw. A quick googling led to a reddit post that indicates it's possible with the Pixelbook, but likely a PITA: https://www.reddit.com/r/PixelBook/comments/7kv944/does_anyone_know_how_to_disable_writeprotection/drsxfny/ https://www.reddit.com/r/PixelBook/comments/7kv944/does_anyo...
- aspenmayer 7y ago
  https://mrchromebox.tech https://mrchromebox.tech

yingw787 7y ago

Great blog post Jess! I think this is an extension of Kerckhoff's Principle that a secure cryptosystem should be able to keep your data secure even if everything (except the key) is compromised: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle Is there a Dockerfile or bash script anywhere that demonstrates how to install all these tools on bare metal? I operate at a higher level in the tech stack and I'm unfamiliar with these tools and how they work. A Dockerfile would be nice because then you could create a virtualish environment where you could play with the new stuff in docker exec before blowing away the old stuff.

justincormack 7y ago
Hey, also look into post compromise security eg see https://eprint.iacr.org/2016/221.pdf https://eprint.iacr.org/2016/221.pdf This stuff is way off Dockerfile level, sorry.
mlaretallack 7y ago
I would start with qemu and uefi coreboot. Docker is too high level for this.
voltagex_ 7y ago
Not a dockerfile, but it may be worth looking at buildroot [0] and qemu [1]. I'd like to say that I started 5 years ago with these tools and ended up working on embedded systems, but it's more like I started 5 years ago and ended up with drawers full of unsupported ARM boards. 0: https://buildroot.org https://buildroot.org 1: https://www.qemu.org/ https://www.qemu.org/

sneak 7y ago

Slightly offtopic, but relevant: Note that the recently-popular "Docker Desktop" product (I believe it uses the xhyve framework in OSX) that brings up a VM to run a linux-based Docker daemon on a local OSX system is not f/oss. The source isn't even publicly available. It surprised me when I found out, considering that all of the other tools shipped by Docker have been.

transpute 7y ago

Videos from the 2018 Open Source Firmware conference are available: https://osfc.io/archive https://osfc.io/archive See also "Firmware is the new Software" from Trammell Hudson, https://www.platformsecuritysummit.com/2018/speaker/hudson/ https://www.platformsecuritysummit.com/2018/speaker/hudson/ > Secure firmware is the foundation of secure systems. If we want to build slightly more secure systems they will require open, auditable and measured firmware. If we can’t read and audit the firmware code, we can’t reason about what is going on during the critical phases of the boot process; if we can’t modify and reproducibly build the firmware, we can’t fix vulnerabilities or tailor it to our needs; and if the firmware isn’t measured and attested, we can’t be certain that our system hasn’t been tampered with.

josteink 7y ago

I’m curious about NERF. What hardware do I need to run it? Is the HW-support as limited as Coreboot? And what do I do if I decide it’s not for me? Are there known safe ways to revert to your mainboards factory firmware?

classichasclass 7y ago

I'm surprised there is no mention of the Raptor Talos II, which is designed to be auditable in exactly this fashion.

Lutzb 7y ago
I am also perplexed why the Raptor Talos II does not receive more attention in the open hardware/software community. For me it is basically everything I've ever wanted from a libre system.
- monocasa 7y ago
  Because it costs as much as my car and has been on backorder for a long time?
  - jancsika 7y ago
    Just curious-- what kind of car?
    - phaer 7y ago
      > Starting at $5,649.00 > Current Status: Backordered For the workstation: https://www.raptorcs.com/content/base/products.html https://www.raptorcs.com/content/base/products.html Fantastic machine, but sadly still 2 or 3 times as much as many people, including me would spend for a workstation.
      - jancsika 7y ago
        The criticism as I understood it was, "I can get a car for that!" To really sting, that criticism should imply a decent run-of-the-mill car, not a clunker. Therefore, I wanted to know the car make/model. Because $6,000 for a decent run-of-the-mill car isn't bad.
    - monocasa 7y ago
      2004 Infinti G35X

deleted 7y ago

[deleted]

acd 7y ago

Agree with the author that UEFI is bad for security. You have this huge binary UEFI blob in a pre os boot environment that does not run open source. After the motherboard,laptop manufacturer looses interest and they loose interest as soon as the product does not sell more new products UEFI remains unpatched and insecure. The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source. Management processors like Intel ME built into the CPU, firmware another x86 insecurity.

fghtr 7y ago
>The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source. I do not see why it would be different for any other software.
- jraph 7y ago
  It's not, in my opinion. And if the piece of software is simple and dumb, I don't really see why it should not be open source neither.
- adrianratnapala 7y ago
  Well simple and dumb generally is good for all engineered things, as long as they aren't so dumb that they can't do their job. This principle applies especially well to boot loaders, because the job of a bootloader is to hand control off to some other, more sophisticated piece software.
- marcosdumay 7y ago
  Well, you can sandbox anything that is loaded on top of a Free layer, you computer's boot firmware is certainly not on such place.
parentheses 7y ago
Unpatched UEFI is more about the reputation of the manufacturer/provider of UEFI. If a major manufacturer releases a motherboard, you can be sure (1) they are patched often and (2) they use similar components across many motherboards so bugs and vulnerabilities are patched across many simultaneously are worked out sooner

fghtr 7y ago

Although mentioned in the article, I would like to emphasize that https://puri.sm https://puri.sm are selling laptops with disabled and cleaned (with me_cleaner) bios. I hope more companies follow.

tty2300 7y ago
The purism devices look great but they are so expensive and its really hard to justify a $900 phone that has worse specs than my old $300 one
metildaa 7y ago
Purism seems to be rather inept, they shat the bed with their recent Librem One product launch, whereby they rebranded Tusky and disabled all moderation tools on their Mastodon instance, then were suprised when their employees started quiting due to this ridiculous behaviour. Purism doesn't seem to want to invest in the software that makes their services work, hence the commentary by Matrix devs on which services are helping to push development forward (and thus deserve subscribers).
- ptx 7y ago
  Where can I read the details of this? (I have preordered a Librem 5. Employees quitting doesn't sound good.)
  - metildaa 7y ago
    https://social.libre.fi/objects/140ca2e8-addd-4dbb-8e03-8d6affd5f724 https://social.libre.fi/objects/140ca2e8-addd-4dbb-8e03-8d6a... Gnome dev ended his contract with Purism over their inept management of the Mastodon instance they are selling accrss to: https://wandering.shop/@KelsonV/102057489260188127 https://wandering.shop/@KelsonV/102057489260188127
PascLeRasc 7y ago
System76 also does this for some machines: https://news.ycombinator.com/item?id=15819636 https://news.ycombinator.com/item?id=15819636

yc-kraln 7y ago

This is a very PC centric article, but the same can be said about any connected device--from cars, to baby monitors, to buttplugs. If it has an internet connection, the firmware should either be open source or in open source escrow, so that if the company dies or decides to not support their device anymore, the hardware itself can continue to live.

crispyambulance 7y ago
> open source escrow I think that's a good idea, but ARE there real and reliable escrow agents for this kind stuff? Is it better than, say, a gentleman's agreement to make the source public on github (or some other channel) upon dissolution of company?
- rtempaccount1 7y ago
  Software escrow agents are definitely a thing (e.g. https://www.nccgroup.trust/uk/our-services/software-escrow-and-verification/ https://www.nccgroup.trust/uk/our-services/software-escrow-a... ) (Disclaimer, I work for that company, but not in the escrow area)
jraph 7y ago
A concrete argument for this: Qualcomm recently released a patch for a vulnerability that makes it possible to access private data stored in the TrustZone of many of its SoCs: https://www.nccgroup.trust/us/our-research/private-key-extraction-qualcomm-keystore/ https://www.nccgroup.trust/us/our-research/private-key-extra... The patch needs to be provided by phone and tablet manufacturers. Except that many otherwise capable phones are not supported anymore and will not be fixed. Were the firmware of these devices open source, the community could fix this (given that the firmware does not have to be signed, or a signing key can be added). But no, many devices will remain forever vulnerable. Including my phone, 4G RAM, 32G internal storage, excellent battery and screen, great computing capabilities, in a excellent physical shape. Will probably last a few years more. Last updated on November 2017 by its manufacturer. Some parts will never be updated again and there is no way to audit this stuff. This is a shame. Edit: and I'm lucky my phone resembles an Android One phone, so some stuff can be taken from this phone to update mine.

nickpsecurity 7y ago

Nice article. A few comments: “Rings 1 & 2 - Device Drivers: drivers for devices, the name pretty much describes itself.” STOP and GEMSOS did use four rings. The evaluators griped that UNIX’s didn’t. Microkernel proponents kept pushing mainstream OS’s to move drivers from kernel mode to another mode. Maybe my memory is off again but arent the drivers for Nix’s and most monolithic kernels in kernel mode (Ring 0)? Maybe Xen does something different with its use of protected mode. Then, some things in user-mode later on like FUSE. “Each of these kernels have their own networking stacks and web servers. The code can also modify itself and persist across power cycles and re-installs. We have very little visibility into what the code in these rings is actually doing” Which is why I put money down that the backdoors NSA paid for in direct money and/or defense contracts would be in management systems. That we’d definitely find services with 0-days in there. Sure enough… “Linux is already quite vetted and has a lot of eyes on it since it is used quite extensively.” That’s total nonsense. Empirical evidence below that’s been consistent over long periods of time. If anything, using Linux is guaranteeing you vulnerabilities if they can call anything in the kernel. If a subset or just one function, maybe OK. Careful analysis case by case on that. We’d be better off with something clean-slate for this purpose that can reuse Linux drivers where necessary. Then, we’d check the drivers and the interfaces. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... It is true that it’s better than the closed-source stuff they’re using, has better tooling, folks understand it better, and so on. All true. “We need open source firmware for the network interface controller (NIC), solid state drives (SSD), and base management controller (BMC).” The problem with this and Intel/AMD internals are that they’re secretive partly to avoid patent suits and new competition. You’re not getting this stuff opened. Not easily at least. Might be better to literally do a closed-source product for them vetted by multiple parties. Otherwise, get the actual specs under NDA to build the open-source code against in a way that doesn’t leak the specs a lot. Alternatively, gotta build your own hardware doing this yourself with whatever the I.P. vendors give you. I mean, good luck on the reverse engineering efforts but these are usually lagging behind. “We need to have all open source firmware to have all the visibility into the stack but also to actually verify the state of software on a machine.” You actually need open, secure hardware for that since attackers are now hitting hardware. I kept telling people this would happen. Just wait till they do analog and RF more. What she’s actually saying here is “verify the state of the machine if the hardware works and is honest and doesn’t do anything malicious between verifications.” “ is the same code running on hardware for all the various places we have firmware. We could then verify that a machine was in a correct state without a doubt of it being vulnerable or with a backdoor.” Case in point: I put a secret coprocessor on the machine for “diagnostic purposes,” it can read state of system, it can leak over RF or network, and we leak stuff out of that signed, crypto code. Good thing no major vendors are including hidden or undocumented coprocessors on their chips. ;) “Chromebooks are a great example of this, as well as Purism computers. You can ask your providers what they are doing for open source firmware or ensuring hardware security with roots of trust.” End with some good advice: buy stuff that’s more open and secure to get more of it. Market demand incentivizing suppliers. That could solve a lot of these problems if enough people do it.

dopamean 7y ago

I have a completely honest question here that I'm hoping some people can answer. Is open source really more secure? My default answer would be yes absolutely but when I think about it I'm not sure I understand why. If something is open source then bugs and security problems can be found more easily and then fixed. This sounds great to me and I'm sure that works out just fine most of the time. This makes me wonder though...are there really fewer intrusions into production systems that are built entirely on open source software than there are in ones built with lots of proprietary, closed source software? What does the data look like about this stuff?

seanhandley 7y ago
I guess it's the principle of "many eyes make all bugs shallow". If the source is freely available, then every day someone is going to read it and maybe see/fix the bug. You can't know what bugs are in code for which you do not have the source, and the pool of people reading it is likely to be much smaller.
- krapp 7y ago
  >If the source is freely available, then every day someone is going to read it and maybe see/fix the bug. How many years did Heartbleed go unnoticed? How many exploits in open source software get reported here? It's not true that someone reads all of the open source code every day. The truth is, few people ever read any of it, and fewer still have the domain expertise necessary to be able to spot and patch any obvious bug, much less subtle ones. And yet this metaphysical belief in the "many eyes" persists. Sure, it exists, but there are supposed to be eyes on the proprietary code as well, and the effect is probably smaller than people think, with no one outside of a project's maintainers ever actually studying the code for most open source projects.
  - marenkay 7y ago
    I'd like to add one thing to this: Heartbleed also went unnoticed because the OpenSSL code ad build process was in such a state that simply looking at it, and having to build it costs an insane amount of effort. So if you truly want to benefit from open source firmware, it needs to also come in at least some minimal form of quality. Things such as good build documentation, automated builds in CI, and also low requirements for setting up development builds are a thing often not present in software all of us deem critical. It is much more intriguing to contribute to a project, use it and submit improvements when the entrance barriers are low.

shmerl 7y ago

I wish AMD would provide open source AGESA, GPU firmware and CPU microcode.

warmwaffles 7y ago
Opensource GPU firmware I am willing to bet has license issues if they were to try and go open source.
- shmerl 7y ago
  Not according to AMD. It's more an organizational issue, since to make it open, they'll need to maintain two versions. One without DRM garbage (HDCP), and one with it. And it costs more to do it naturally. As usual, DRM poison ruins technology.

Paianni 7y ago

The Socionext E-series Developerbox has open source firmware and is at least cheaper than the Raptor stuff.

classichasclass 7y ago
It's a nice system, and definitely cheaper, but it isn't a reasonable price comparison as it isn't even remotely in the same performance ballpark as POWER9. https://www.phoronix.com/scan.php?page=article&item=arm-24core-developer&num=1 https://www.phoronix.com/scan.php?page=article&item=arm-24co...
- iamnothere 7y ago
  Depends on the workload and the # of cores in the POWER9 chip(s). The Socionext has 24 cores! Edit: Admittedly only massively parallel workloads will be faster than the POWER9, and only if the POWER9 has limited cores. A bit of a stretch for most use cases.

matthewfcarlson 7y ago

I agree- this is a very PC focused article but firmware is everywhere. It needs to be updateable and making it open makes it far easier to update. As far as UEFI goes, I'd just like to point out Microsoft's open source Firmware efforts (Project Mu). https://microsoft.github.io/mu/ https://microsoft.github.io/mu/ The goal is to make firmware easier to service and easier to update with security fixes for older projects. While it's not perfect, it is a great step forward. I think we need to see more of this in the future from other companies. (Disclaimer: I work for Microsoft and contribute to Project MU).

nixpulvis 7y ago
Reading up on Project MU now, and I'm sorry, what is this about firmware as a service? This seems like exactly what I don't want. XaaS (X as a Service) is great when there's something external that is only temporarily or optionally required, (or too expensive). Otherwise it's an ongoing dependency. But with firmware, once I own the hardware, I should own the firmware too. Without knowing more about this specific Firmware as a Service I can only imagine how this will actually look. Maybe it just means that updates are automatic? Even that alone is an interesting debate. Otherwise, Prohect MU looks like a modern wrapper around UEFI, what's being done to address the fundamental issues? Firmware code running after boot, modifications to firmware possible by changing code between boots, etc...
- kr99x 7y ago
  The only firmware code running after boot that UEFI mandates is not below ring 0 and is fully optional - called only if and when the OS asks for it. The UEFI runtime services table is not a kernel and is parked in ordinary memory waiting to be jumped to/called. SMM is supported but not mandated, which is exactly how any hardware feature should be treated. Blame those enabling the SMM code you don't like. Or blame the hardware manufacturer for putting the feature in at all. UEFI is not your enemy. Its only sin is being overly complicated, which is (somewhat) debatable given the complexity of systems and OSes needing to be bootable.
  - 7y ago

nixpulvis 7y ago

Great overview of much of the firmware and general "OS" stack (for lack of a better word). I'm surprised not to read a mention of the micro-code which all instructions our programs ask the processor to run actually convert to. I suppose that's starting to get too close to a discussion of open hardware, which this post mostly sidesteps. Both are important issues.

sara7262 7y ago

They found world's biggest fish Even you can't believe how big fish is this That's unbelievable http://bit.ly/2FHl4pM http://bit.ly/2FHl4pM A cute dog is dancing in video Just watch this video and try to control your laugh http://bit.ly/2ZK1XVs http://bit.ly/2ZK1XVs See how a Turkey saved the life of his friends Even those birds also have love in their hearts http://bit.ly/2WhAiZS http://bit.ly/2WhAiZS Sometimes our feet smell are so bad even we feel ashamed due to our feet smell Now you can get rid from this just follow this simple method https://zoomtips.blogspot.com/2019/04/Smelly-feet.html https://zoomtips.blogspot.com/2019/04/Smelly-feet.html Guy made world record He drive car on two wheels See his video how he is driving http://bit.ly/2ZOYaWX http://bit.ly/2ZOYaWX

ignoramous 7y ago

I wish the smartphone side of things gets more attention and someone engineers their way to an open source baseband firmware ala OpenWrt [0]. Not sure why after the breakthrough for GSM/2G with OsocomBB [1], no viable libre alternative LTE or 4G has emerged [2]. The smartphone is an always-on, always-connected computer with 2B or more (30% of world's population) unsuspecting (to almost a point of being gullible) BSD/Linux users who are exposed and don't even know it, to an unprecedented degree, to adversaries with deep pockets (ad-networks [3], nation-states [4], carriers [5]) who don't need a second invitation. Most of the privacy and security battles, I feel, will be won and lost with smartphones. That's discounting IoT security altogether which is a scary proposition in itself for rather silly reasons [6][7]. RMS has had the right idea all along? -- [0] https://news.ycombinator.com/item?id=6722292 https://news.ycombinator.com/item?id=6722292 [1] https://news.ycombinator.com/item?id=8987931 https://news.ycombinator.com/item?id=8987931 [2] https://news.ycombinator.com/item?id=8813098 https://news.ycombinator.com/item?id=8813098 [3] https://news.ycombinator.com/item?id=11265751 https://news.ycombinator.com/item?id=11265751 [4] https://news.ycombinator.com/item?id=3295341 https://news.ycombinator.com/item?id=3295341 [5] https://news.ycombinator.com/item?id=17081684 https://news.ycombinator.com/item?id=17081684 [6] https://news.ycombinator.com/item?id=17785162 https://news.ycombinator.com/item?id=17785162 [7] https://news.ycombinator.com/item?id=11266796 https://news.ycombinator.com/item?id=11266796

commandersaki 7y ago

Curious what the author thinks about open sourcing the secure enclave co-processor in iPhone/iPad/etc.

farshaddx619 7y ago

پودر جوانه گندم https://20to20.ir https://20to20.ir خرید عطر http://20to20.biz http://20to20.biz دانلود آهنگ جدید http://dlfun.ir http://dlfun.ir دانلود موزیک ویدیو جدید http://downloadbazan.ir http://downloadbazan.ir خبرهای بدون سانسور http://zamennews.ir http://zamennews.ir دانلود آهنگ جدید بندری http://reza-sadeghi.ir http://reza-sadeghi.ir http://top-store.ir http://top-store.ir http://reza-sadeghi.vcp.ir http://reza-sadeghi.vcp.ir http://bigstars.persiangig.com http://bigstars.persiangig.com خرید خرما http://sepandtd.com http://sepandtd.com mazafati date http://livco.nl http://livco.nl http://bidestan.com http://bidestan.com travel to Iran http://irantours.biz http://irantours.biz http://the20.4kia.ir http://the20.4kia.ir https://20to20.shopfa.com https://20to20.shopfa.com http://the20.somee.com http://the20.somee.com https://drfniazi.ir/what-we-offer/ https://drfniazi.ir/what-we-offer/ http://ow.ly/AsAK30ot8n4 http://ow.ly/AsAK30ot8n4 http://free-ad.ir http://free-ad.ir https://gitlab.com/farshaddx619/20to20.ir https://gitlab.com/farshaddx619/20to20.ir https://gitlab.com/farshaddx619/20to20 https://gitlab.com/farshaddx619/20to20

peter_retief 7y ago

Great overview, I have had many disagreements with IT managers that blame open source for security breaches.

workrockin 7y ago

First of all love it that someone is thinking about bootloaders. Thank you and I hope you're successful in this project. I think that the article though is only targeted towards desktop PC/laptop/servers and mobile phones. Also not sure whether the it is talking about first level bootloader vulnerabilities or of second level bootloader vulnerabilities. In the embedded world there often is no second stage loading, there are simply bootloaders. There are many, many bootloaders and opensource is the most popular option here, both first and second level. Here's a table of hardware filtered by the booloaders used https://openwrt.org/toh/views/toh_admin_bootloader https://openwrt.org/toh/views/toh_admin_bootloader - around 800 device types use uboot - around 200 use cfe Both of them are opensource. I think we can use the research done opensource router os like openwrt[1] to design a BIOS that works across all devices. One interesting point to note here is that in many routers entire bootloader can be replaced easily using network booting. It takes seconds to flash the ROM (network booting is in-secure in theory but secure in practical since you need physical connectivity to book via a network). While many modern machines support network booting,replacing the first level bootloader (BIOS) is (impossibly) hard. Distributions of linux use GRUB which is nice and also opensource. But again its a second stage bootloader that comes into play after BIOS (first stage bootloader) has been executed. I'd love to see more development in u-boot as they have already done the hard work of supporting multiple devices [2] and amazingly they also support direct booting from an SD card (not an sd card adapter via a usb stick). Here is the list of architectures supported /arc /arm /m68k /microblaze /mips /nds32 /nios2 /openrisc /powerpc /riscv /sandbox /sh /x86 Another key point to note is as a user there is very little control that I have on my bootloader (first level). Since it is loaded from a ROM which I can't replace/rewrite even if opensource firmware exists I can't use it. While I can install a new operating system I have not found any easy way to switch firmwares. Unless a project like linux foundation takes it up and brings together the stake holders to use an opensource firmware I think it will be really difficult to get adoption. On the other hand bootloader is probably the only piece of software left that gives device manufactures some kind of control over their hardware. What's in it for them to use a free opensource technology? [1] https://openwrt.org/docs/techref/bootloader https://openwrt.org/docs/techref/bootloader [2] https://en.wikipedia.org/wiki/Das_U-Boot https://en.wikipedia.org/wiki/Das_U-Boot