101–110 of 124 posts
Earlier quoted context omitted.
It's either a DTB per device or a firmware blob per device . I'll take the open source device tree anytime!
A DTB is a blob. Whether you have the source is a vendor decision, just like ACPI. There's no inherent difference here.
dtc -I dtb -O dts -o devicetree.dts blob.dtb
Big, biiig, biiiiig difference!
PS: You can also examine it directly as a directory tree in /sys/firmware/devicetree/*
Earlier quoted context omitted.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
> Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2. Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring…
It's not the same!
A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.
Earlier quoted context omitted.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.
Earlier quoted context omitted.
I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .
And you're stuck with whatever fucked up kernel the vendor gave you, assuming they even followed their obligations and gave you access to the source. The vast majority of x86 systems run mainline kernels because there's a sufficient level of abstraction. The number of Arm devices that's true for is a tiny percentage of the Arm devices out there running Linux.
Earlier quoted context omitted.
UEFI switches the CPU into 32bit v86 mode or directly in 64bit mode and you can't go back to real mode without a CPU reset, which v86 won't allow (you don't have ring -2 privileges) and 64bit mode can't do at all. I don't have a UEFI system, so I might be wrong (I even hope I'm wrong - it would mean slightly more freedom still exists), but from what I read about it, I'm 90% certain it's not possible.
You're confusing several things here. The only x86 processor that didn't allow returning to real mode was the 16-bit 80286 - on all later ones it's as simple as clearing bit 0 of CR0 (and also disabling paging if that was enabled). Nothing more privileged than ring 0 is required for that. "v86" is what allowed real mode to be virtualized under a 32-bit OS. This is no longer available in 64-bit mode , but the CPU stil…
Earlier quoted context omitted.
Microsoft keeps trying to go ARM for a decade already, most Windows devs and consumers don't care, backwards compatibility rules on PC world, regardless of Prism and ARM64EC. Additionally beware what to wish for, as CoPilot+ PC are locked down with Pluton security processor, from XBox and Azure Sphere.
The x86 emulation for fallback is (I’ve heard - not tried) usable for the first time. Microsoft tried in the past without a Rosetta equivalent; Apple succeeded twice with Rosetta. They did not try to switch cold turkey the way Microsoft did.
Apple doesn't care about backwards compatibility like the PC, who doesn't move, stays behind.
Earlier quoted context omitted.
A DTB is a blob. Whether you have the source is a vendor decision, just like ACPI. There's no inherent difference here.
You can convert a DTB blob back into source code: dtc -I dtb -O dts -o devicetree.dts blob.dtb Big, biiig, biiiiig difference! PS: You can also examine it directly as a directory tree in /sys/firmware/devicetree/*
Earlier quoted context omitted.
What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.
Let's say some hw manufacturer would open-source the required specs to implement it on it's chips. (Very unlikely, but let's say they do...) So what? Dangerous capabilites remain.
Earlier quoted context omitted.
> Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2. Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring…
> there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0 It's not the same! A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.
Suggested reading:
* https://www.maven-silicon.com/blog/privilege-levels-in-arm-a...
* https://projectzero.google/2017/02/lifting-hyper-visor-bypas...
* https://en.wikipedia.org/wiki/ARM_architecture_family#Securi...
* https://docs.samsungknox.com/admin/fundamentals/whitepaper/s... (in which Samsung uses firmware running under the kernel to protect against kernel exploits)
Earlier quoted context omitted.
Which x86 devices ship with a free UEFI/ACPI? Or even allow users to replace the preinstalled UEFI/ACPI with a free one?
I've a bunch of devices running coreboot with a Tianocore payload, but they're largely either very weird and now unavailable or I haven't upstreamed them so it's not super helpful, but it's absolutely not impossible and you can certainly buy Librebooted devices