Revist ppc64el platform support #2309
Replies: 22 comments
-
|
Is raptor engineering related to raptor computing systems? |
Beta Was this translation helpful? Give feedback.
-
|
@jstkdng Yes, that is correct. On my side I have the exact opposite problem -- I use ppc64el systems, and do not use x86_64 systems, so cannot use this as-is. The patchset is current and Raptor has been maintaining it (including security updates) for a while now. We're on Chromium 101 and have the resources to continue moving it forward. Typing this from the Debian ungoogled package Raptor maintains, on a ppc64el box. 😉 Edit: If CI/CD is an issue we can provide build resources for that. |
Beta Was this translation helpful? Give feedback.
-
|
Oh thats nice, I was certainly interested on power pc computers as current cpus are backdoored (Intel IME and AMD PSP) but I wasn't able to do it due to the Talos workstations being expensive. But, if you are fine maintaining patches and such in your own repositories, why is it that you want to add the patches here? Ease of use? Get a spotlight? |
Beta Was this translation helpful? Give feedback.
-
|
Mainly to keep things in one spot, to make it easier on both us and anyone that just wants to grab the source and compile it. If Google wants to keep everything in their repos locked to backdoored platforms, and refuses to merge patches for owner controlled platforms, what better way to provide an alternative than to have the only out-of-the-box build for the platform be for a version that has the rest of the Google tracking ripped out? Edit: Here's a link to the current Debian builds for ppc64el w/ the ungoogled patches layered on top: https://quickbuild.io/~raptor-engineering-public/+archive/ubuntu/chromium/+packages At the moment this is a rather unelegant process of taking stock Debian Chromium, layering the ppc64el patches, then trying to layer and merge the Ungoogled patches on top. To be honest, if upstream Chromium is never going to merge these (for "unspecified reasons") I'd rather just have us switch the builds in that repository over to direct builds from the Ungoogled sources here. |
Beta Was this translation helpful? Give feedback.
-
So right now there are conflicts between both patch sets? Are your patches different than the ones used here? https://github.com/kth5/archpower/blob/master/chromium/PKGBUILD |
Beta Was this translation helpful? Give feedback.
-
|
@jstkdng No, there are no conficts between ungoogled and the ppc64el support that I know of, the conflicts are between the ungoogled patches and the stock Debian chromium version. One of the problems here is that while all of the ppc64el patch sets have originated from the same common source, they have all morphed and deviated from one another in various ways over time. I'd like to have a central place to collaborate on them as well as a location that users can be pointed to in order to download known-good sources / build binaries from. |
Beta Was this translation helpful? Give feedback.
-
|
In then end I guess the only way the patches could be added here is if they don't interfere with other architectures, probably ppc specific repositories on https://github.com/ungoogled-software could work as well. Like ungoogled-chromium-archlinux-ppc or ungoogled-chromium-debian-ppc and/or publish ppc binaries here https://github.com/ungoogled-software/ungoogled-chromium-binaries . |
Beta Was this translation helpful? Give feedback.
-
|
@jstkdng In general, the patches have been specifically crafted so as not to interfere with any of the other architectures -- this is why I'm a bit puzzled as to why Google isn't willing to merge, and starting to wonder what the motivation there actually is. We could start with a separate repository I suppose, with maybe a reference in the main readme that if you want to run ungoogled chromium on properly secure hardware to go to the other repo? |
Beta Was this translation helpful? Give feedback.
-
well, not all powerpc devices are properly secure, not everyone owns a talos workstation and I think most of the powerpc users run linux on old powerpc macs. Those aren't as open as what raptor offers.
An ungoogled-chromium repository? or a uc-debian-ppc repository?
Yeah, the new repo should replace the existing one since it looks to be dead https://github.com/Eloston/ungoogled-chromium#related-projects |
Beta Was this translation helpful? Give feedback.
-
Yeah, I should clarify the old ppc stuff isn't supported -- from a technical level, the patches assume ISA 3.0 (i.e. POWER9 or compatible) or higher.
ungoogled-chromium, or maybe even a branch in there? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how feasible a branch here is, a separate repo would be fine, plus any additional distribution specific repositories. Man I wish I had a powerpc rig, once I get some money I'll buy a complete one. Is raptor the only company that sells ppc workstations? |
Beta Was this translation helpful? Give feedback.
-
OK, I could start on our own Gitlab instance if that's easiest, then once you see what I have in mind we can figure out next steps?
We're definitely the only OpenPOWER ODM that has 100% owner control as a hard requirement, and likely the only ODM doing desktop designs. We're also the only OpenPOWER vendor that's engaging with and investing in the wider ecosystem to keep the open source desktop software at feature parity with x86 (hence Chromium, etc.) -- most of the other vendors are focused on the server space exclusively, and aren't really concerned about various binary blobs in their systems. We do have some resellers and system integrators worldwide (notably Vikings) that might make things easier for people in the EU as well.
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Just a FYI. Gentoo upstream Chromium has patches for ppc support and I just copy them to be available for ungoogled-chromium I maintain, so not an issue actually. And I'd tell you more: my overlay has even electron and vscode supporting ppc: PF4Public/gentoo-overlay#134 |
Beta Was this translation helpful? Give feedback.
-
Yeah sure I don't mind giving some feedback
Ohhh, that's awesome, have you had problems ever since you started using the patches? |
Beta Was this translation helpful? Give feedback.
-
|
@PF4Public That's great! I think what we really need is a central repository that is distro-agnostic (hence why I've been trying to upstream patches again), so we're not all duplicating each other's effort downstream. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
Unfortunately I don't have the hardware. I'm aware of only two people, who actually have and use the hardware. I'll wire them here in case they might have something to say on the topic: @darkbasic and @skrinakron. |
Beta Was this translation helpful? Give feedback.
-
I'm writing this from Chromium 101 on my Talos 2, it's been working very well so far. The problem is the lack of an upstream: Timothy Pearson does the heavy lifting on his ppa, Georgy Yakovlev and Stephan Hartmann co-maintain their own patchset for Gentoo, I maintain my own on the PF4Public overlay because sometimes they lack the time to forward port it and I don't have write access to Gentoo's repos, Void has its own patchset which (AFAIK) only supports 4K page sizes and the list goes on. I think that everybody would greatly benefit from a centralized place, especially since @madscientist159 is able to provide CI/CD and even more because ungoogled-chromium perfectly aligns with the philosophy of a totally open platform like Raptor's ppc64le. |
Beta Was this translation helpful? Give feedback.
-
it's not totally open as some devices still require some binary blobs last time I checked, but it's still a lot more open than other systems.
I believe so as well, but it seems some distribution specific patches are also required |
Beta Was this translation helpful? Give feedback.
-
Which blobs are you thinking of? The only ones on a standard Talos II are offboard -- basically if your GPU needs firmware or if you are using a hard disk / NVMe device with proprietary firmware. Those in turn are isolated behind the IOMMU so they cannot attack the main system, and we always recommend all data is encrypted before it reaches the storage devices anyway.
It could be a central location for everyone to layer the distro patches on top of? |
Beta Was this translation helpful? Give feedback.
-
I believe wendell mentioned the nvme controller needing blobs on his overview of the talos system, that video is old though.
yeah, and maybe even further the development of ungoogled-chromium if we ever get the boot from github. |
Beta Was this translation helpful? Give feedback.
-
Right, most (all?) NVMe devices use an internal proprietary firmware. So do all modern hard disk drives, it's just the nature of the storage subsystem. That said, this is the easiest threat to work around, by using host-based LUKS encryption and relying on the fact that all storage is replaceable (i.e. nothing is soldered down to the mainboard). The worst thing that could happen would be your storage system DoSes your main system (returning corrupted data, or not responding to data requests), which is something that is likely to happen with any storage device anyway at some point in time just due to the underying physics.
Sounds reasonable enough. I spun up a group here [1] and will be working on adding an intial repository this week. |
Beta Was this translation helpful? Give feedback.
-
|
@madscientist159 would it be possible to allow login using github/gitlab credentials like freedesktop does?
I think that would lower the contribution barrier while keeping a dedicated gitlab instance. |
Beta Was this translation helpful? Give feedback.
-
I'd like to reopen discussion on this, especially in light of the fact that upstream Chromium (by Google design) only supports architectures where there is support for deep low-level DRM / device tracking functionality, and Google has been refusing to accept patches that would enable architectures (such as ppc64el) where this level of control and tracking is absent.
Raptor has been maintaining the ppc64el patchset for a while now, as well as shipping Debian binaries of ungoogled chromium for ppc64el, and overall I think the ungoogled chromium and ppc64el port are philosophically well aligned. We can provide both developer support and hardware in support of a truly tracking-free, modern browser if the project is willing to accept our help?
Originally posted by @madscientist159 in #747 (comment)
Beta Was this translation helpful? Give feedback.
All reactions