haukem (u/haukem) - Readit News

haukem commented on OpenWrt: A Linux OS targeting embedded devices openwrt.org/... · Posted by u/pykello

echelon · 3 days ago

Can we accept a pragmatic world where we have OSS + binary blobs?

That's better than a fully commercial world or a fully "pure" world with no functionality.

haukem · 3 days ago

OpenWrt accepts binary only firmware running outside of the Linux kernel address space on the wifi chip itself. This matches what upstream Linux also accepts. This works well with most recent Wifi drivers. OpenWrt does not accapt binary only kernel modules or binary only userspace applications, they are very hard to maintain if you do not have the source code.

This works well with Mediatek and also Qualcomm and most other vendors.

haukem commented on OpenWrt: A Linux OS targeting embedded devices openwrt.org/... · Posted by u/pykello

mifydev · 3 days ago

But then you get annoying firmware providers like Broadcom who refuse to write OSS drivers for linux and a lot of work is being spent on the reverse engineering

haukem · 3 days ago

MediaTek chips are well supported by OpenWrt. Broadcom is not good supported. Mainline Linux kernel supports recent MediaTek Wifi chips quite well [1]. MediaTek is also working on these upstream Linux drivers, but they still have a proprietary Linux driver in addition.

Also the rest of the recent MediaTek SoC is supported quite well by upstream Linux and OpenWrt.

You can run OpenWrt on recent MediaTek SoCs with all code running on the main CPU being open source, no closed source code needed inside the Linux kernel address space or in user space. The chips need firmware running directly on the IP cores. It needs a firmware running on the wifi core itself, there are probably one or more CPUs inside the wifi cores doing real time stuff. The Ethernet PHYs also need a firmware which is running on the PHY.

[1]: https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/ne...

haukem commented on OpenWrt: A Linux OS targeting embedded devices openwrt.org/... · Posted by u/pykello

esseph · 3 days ago

A lot of companies were built on this.

haukem · 3 days ago

I assume that about 20% to 50% of the home routers, Access points and Wifi mesh devices sold world wide are based on OpenWrt. Often some old versions of OpenWrt with many vendor modifications, the UI is always custom.

I know that the main vendor SDKs from Qualcomm, Mediatek, and Maxlinear are based on OpenWrt. I think only Broadcom uses an own Linux distribution which is not based on OpenWrt in their main SDK. Linux has a market share of about 99% in this market, I haven't seen VxWorks in any recent home router or access point.

haukem commented on OpenWrt: A Linux OS targeting embedded devices openwrt.org/... · Posted by u/pykello

_giorgio_ · 3 days ago

Is the router only available on AliExpress?

No EU vendor?

Apparently the firmware is shipped without the GUI (LUCI). And only 900 units have been sold in 10 months. Something fishy is going on.

https://www.reddit.com/r/openwrt/comments/1h0pkbw/openwrt_on...

haukem · 3 days ago

Sorry, we know that the EU and NA distribution channels are not so good. The OpenWrt project depends on Banana Pi here. There are some resellers on Amazon.

About 10k OpenWrt one units were sold as of today. The first 900 were sold in about 3 days.

haukem commented on Experimental release of GrapheneOS for Pixel 9a grapheneos.social/@Graphe... · Posted by u/moelf

strcat · 5 months ago

All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones.

We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though.

Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us.

Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a).

We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack.

If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.

haukem · 5 months ago

Thank you for all the insights.

Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.

Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?

Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.

haukem commented on Experimental release of GrapheneOS for Pixel 9a grapheneos.social/@Graphe... · Posted by u/moelf

strcat · 5 months ago

Open source doesn't provide any magical privacy or security. iPhones have solid privacy and security despite being mostly closed source software. iPhones are the next best options for privacy and security in most ways. They have great privacy from apps and aren't awful at privacy from Apple particular if people use Advanced Data Program for iCloud, and they have solid security overall along with some useful settings for it. GrapheneOS of course provides better privacy from the OS services. We provide a full list of default connections made by the OS at https://grapheneos.org/faq#default-connections and none are made by the hardware without the OS prompting it. GrapheneOS also defends better against sophisticated real world attacks, and there's real world evidence for that from leaked capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB (XRY) along with some basic info about remote exploit sellers.

All of the kernel drivers are open source, which would be the case for Snapdragon too.

Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things.

There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help.

If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.

haukem · 5 months ago

> If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access.

Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.

I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.

I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.

haukem commented on Linux 6.12 Features Super Real-Time, Sched_ext, Intel Xe2 and Pi 5 phoronix.com/review/linux... · Posted by u/rbanffy

hamandcheese · a year ago

The Pi 5 support is surprising, or rather that it's only landing now.

haukem · a year ago

The Raspberry Pi Foundation does not do a good upstream support. It is not very bad, but also not good. They should start adding support for their new chips in the upstream projects before they get into the market, like Intel does it for example. They could add support for some new IP cores, without reveling when and how it will be used later. When the product comes out the only add small patches linking the code together like device tree files.

It would also be good if they would release all the closed source firmware files needed for their devices under a redistributable license in the linux-firmware repository. For some time it was not allowed to redistribute the binary wifi firmware needed for the Raspberry Pi devices. This is needed for Linux distributions to package the binaries.

I hope they do this only because of lack of resources and not intentionally to lock people into their Linux distribution.

haukem commented on Lidl's Cloud Gambit: Europe's Shift to Sovereign Computing horovits.medium.com/lidl-... · Posted by u/taubek

mns · a year ago

Open Telekom Cloud is a whitelabeled AWS, so they are still doing this, but with other technologies.

haukem · a year ago

This press release from 2020 says Open Telekom Cloud is from Software and Hardware from Huawei.

https://www.open-telekom-cloud.com/de/blog/vorteile/die-sich...

Do you have any source that they switched to AWS?

haukem commented on Lidl's Cloud Gambit: Europe's Shift to Sovereign Computing horovits.medium.com/lidl-... · Posted by u/taubek

mkesper · a year ago

Open Telekom Cloud has at least a great part of the functionality you expect when talking about a cloud provider: VMs (even GPU ones), VPCs, managed databases, block storage, Logging, IAM, API Gateway, Container Engine etc. https://www.open-telekom-cloud.com/

haukem · a year ago

Open Telekom Cloud was at least in 2020 running fully on Huawei Software and hardware: https://www.open-telekom-cloud.com/de/blog/vorteile/die-sich...

Deutsche Telekom used Huaweis OpenStack implementation.

I haven't found any information that this changed, so I assume it is still running completely on Huawei. At least they made sure that they still get chips from the US despite sanctions. ;-)