Android user since ~2010 (before that, Symbian).. I tried one of Apple's "Pro" phones with IOS 2021, last year I went back to Android and back to freedom even if it is Google's walled garden. Still, being able to control many aspects of the phone (choice of browser, do I need to mention different volume controls, can compile own stuff, automation) is unbeatable.
To me using iPhone left me with the same crippled feeling that I would have if someone forced me to use Windows on a computer. On the plus side, my screen time was actually lower during those two years..
"After exfiltrating the /data partition we turned our attention to the rest of the device. This is probably a good time to point out what base operating system Ivanti is using: CentOS 6.4; which was released in 2013 and officially end of life in 2020. You read that correctly: Pulse Secure runs an 11-year-old version of Linux which hasn’t been supported since November 2020. More on this later."
It seem popular in corporate environments to just rely on vendors and their binary blobs.. not at all surprised to see such findings.
Yes? As opposed to, what? You need to think back 15–20 years ago, people needed VPNs to remote into company networks, that's why there are so many Cisco ASA's out there, and they just keep chugging along.
Sure NOW there is zscaler and cloudflare tunnels and wireguard, but those are fairly new and companies don't want to rip out gear “that works”
Ridiculous fee for for-profit companies that want to sell their software for free, aka where you are the product?
Sorry, I won’t be crying that no MetaStore will be financially possible. But an FDroid alternative can work, and that’s the only thing I wanted (and many end-users who didn’t even know they wanted it)
Developer fee for the Play Store yes, but no developer fee for using the open stores (although I'm well aware that in certain environments it is disallowed to use other than the Play Store) or developing local apps.
> The Libreboot project provides free, open source (libre) boot firmware based on coreboot, replacing proprietary BIOS/UEFI firmware on specific Intel/AMD x86 and ARM based motherboards, including laptop and desktop computers. It initialises the hardware (e.g. memory controller, CPU, peripherals) and starts a bootloader for your operating system.
> What more vulnerabilities hides in the proprietary UEFI?
Most UEFI vulnerabilities seem to come from bugs in the open source reference implementation making it down to the proprietary firmware.
That said: as much as you would expect from any low-level C program. I hope that EDK will eventually find itself rewritten in a safer language to it easier to spot mistakes. I would say Rust would be the best fit, but I admit that it's not a perfect fit; sadly, we lack safe low-level languages.
As for running without UEFI/BIOS: most ARM devices have an alternate bootloader (usually uBoot with some proprietary magic) but I don't know if that's much better. This approach usually requires per-device support from the operating system you want to install.
> I would say Rust would be the best fit, but I admit that it's not a perfect fit; sadly, we lack safe low-level languages.
Rust is a safe low-level language. You can start writing your UEFI implementation in rust today [1], [2]
> As for running without UEFI/BIOS: most ARM devices have an alternate bootloader
UEFI/BIOS is not a bootloader, they initialize hardware and then pass on responsibility to a bootloader. Popular bootloaders are the Windows bootloader, grub, etc etc.
Rust is _a_ safe language, but if you're interacting with a lot of low-level hardware, you end up with a lot of unsafe {} code and manual analysis that takes away some of the advantages.
I see Rust as a C++ replacement more than a C replacement. I'm not sure if object oriented languages (well, "struct with functions" in Rust's case) with vtables and dynamic allocation and the like are a good match for that kind of code. Rust, as a language, simply can't deal with running out of memory; all allocations are assumed to succeed, which is a dangerous assumption, especially in low-level code like this.
Unfortunately, we don't really have a common C replacement with Rust-like safety guarantees. I'm hoping Zig will be able to provide some safety to the C ecosystem, but it's still a ways away from 1.0.
> UEFI/BIOS is not a bootloader
You're right, I meant "bootstrapping system". I'm sure there's better terminology here but the word escapes me at the moment.
Rust, as a language, doesn’t know anything about heap allocation. The “running out of memory” stuff you’re talking about is a feature of some APIs of the standard library, which you often completely forego in an embedded context. Or you can use the (still unstable, to be fair) APIs that return results instead. This is what the Linux kernel is doing, for example. It was a hard line for Linus, but didn’t prove to be an obstacle in the end.
One could, of course, write their own allocator and heap tracking system as part of the UEFI firmware, or reimplement the entire thing without any of the standard library and simply relying on the core library, but if you want to deal with fallibility, you'll have to reimplement every part of the language toolkit and use Option<> or Result<> for every API call, which would only complicate the rewrite more.
How come that this is the first time (might have visited that site several years ago, recognize the CSS in some way) that I hear about lobster.rs? Is the site entirely by invitation or are there at least a couple yearly signup openings?
