So, does this affect dual boot systems, if e.g. Windows is compromised, now that malware in the efi partition can compromise the Linux system next time it boots? Yikes!
I suppose in principle malware from one OS can attack the other anyway, even if the other is fully encrypted and/or the first OS doesn’t have drivers for the second’s filesystems: because malware can install said drivers and attack at least the bootloader - though that night have been protected by secure boot if it weren’t for this new exploit?
Yes, it can execute code regardless of OS installed because it persists on the Mainboard and loads before any OS, making it possible to inject code into any OS.
You’re right, that’s exactly what happened. If you look at the top of the trace, it says __handle_sysrq. Moreover, it’s in the sysrq_handle_crash. That gets called when a sysrq combo is pressed.
One of my biggest pet peeves with Linux by far. Usually my use of Linux is generally just parsec and that’s it. But I can’t ever select the right driver, and then I forget, idk it’s a whole thing and I just wish it was baked in and easy, but then again it is linux
I don’t exactly know why, but part of it could be that due to different open source licences they have to keep things separate, because the kernel is licenced under the GPL, and the Intel video libraries probably aren’t.
Another reason could be simply not wanting bloat, but with everything a standard kernel does come with I guess probably not
Cool. Do you know if this project will support PowerPC-era Mac OS X apps or if that makes any difference? There are a bunch of quirky and fun games that could avoid being lost to time if an “emulator” can run them.
CLI’s are likely not specifically the target. I suspect the CLI is just the “low hanging fruit” and core set of software that needs to be supported before you build up to a fully functional GUI apps.
For software that’s currently available on both Windows and MacOS, how does the performance of the Windows version under Wine compare to the MacOS version under Darling?
Wine is much, much better at this point. In particular, Darling doesn’t have much support for GUIs yet, so unless it is a command line tool you probably want to stick with Wine.
I imagine if Darling gets as well supported it would be better. But it will not be optimized as much, even though the core architecture may be way more similar
Is there not issues with filling up the NVRAM with efi entries, even if you’re deleting old ones? I’ve bricked a computer by distrohopping so many times it couldn’t write new entries.
No, I just duckduckwent “Hacker Cat” and nabbed the pic where the cat had the smuggest look on her face.
My own cat made sure to dispose of all incriminating evidence.
Is this potentially useful to me? Since it is persistent, can I use it on this motherboard I have over here that insists on using UEFI even if I do not want to?
It took an hour or two to compile and takes up about 5GB of space. The only program I’m really interested in is Xcode, which doesn’t work at the moment.
Haven’t tried it yet, but I can see myself using it in the future. It could be great for automating Mac/iOS development and administrative workflows. I don’t think you can compile, sign, notarize, or inspect Mac/iOS apps without Xcode tools (which are, of course, Mac-only). It’s a pain in the ass to operate Mac VMs for such purposes, and it’s only getting more difficult as time goes on. IIRC Apple only allows 2 guest VMs per host now.
Not sure if there are any non-Mac tools to work with dmg files (Mac disk images).
If GUI support is sufficiently developed in the future, there are plenty of Mac apps I would like to run. iPhone app support on Linux would be an absolute game-changer.
Safari is by far the best browser for battery performance. I’m uncertain if this would translate over to safari running in darling when it supports guis fully.
It's rare that I get to feel anything remotely comforting about not being able to afford new hardware, but if I understand correctly, my BIOS-only dinosaur can't be exploited.
Still vulnerable to thousands of other exploits no doubt, but not this one.
This latest UKI work for Fedora will lead to better UEFI Secure Boot support, better supporting TPM measurements and confidential computing, and a more robust boot process.
and HOPEFULLY lead to a less jerky-flashy-switchy boot xperience, looks like a Vegas light show at present. switched to systemd-boot, but it’s only a tiny bit better, still switches modes/blanks screen like five times.
Omg yes, I hate those. I’m sitting here thinking it’s probably one of those simple things that scares people away from Linux…“Oh god, I see black text on white background. Abort, abort, ABORT!!”
yeah, if you don’t have an encrypted drive (which I’m gonna do on a laptop NEVER) on some OEMs this can look semi-seamless.
here’s what it looks like on a laptop:
OEM logo
screen goes blank, backlight off
light on, OEM logo
blank screen
decrypt password
blank screen
loading spinner with OEM logo
gdm/sddm login screen
blank screen
9a. (sddm) loading animation
9b. (sddm) jerk when fractional scaling kicks in
and finally there’s the desktop
with additional mode switching interjected and occasionally the horror that is GRUB inserts a ‘Loading blah blah’ text message; thankfully we’re getting rid of that.
My HP crapbook doesn’t have this OEM logo bullshit. Only the windows bootloader shows it, and the logo file is stored in the BGRT. So I don’t think I’m affected unless the WBM or systemd-boot have this vuln.
Mine:
<span style="color:#323232;">1. Screen turns on
</span><span style="color:#323232;">2. I pick EndeavorOS in systemd-boot
</span><span style="color:#323232;">3. It starts spitting out logs (I love this behavior)
</span><span style="color:#323232;">4. It switches modes once the backlight is loaded
</span><span style="color:#323232;">5. I log in
</span><span style="color:#323232;">6. KDE loads
</span>
I will never understand people who install Plymouth, it just adds complexity in the boot process. If your distro installs this then I understand why: so it doesn’t look like you’re “hacking the government”. If your distro doesn’t install it and you install it then you probably picked the wrong distro.
I have almost a dozen installs of it in the wild for a few years now, with friends and relatives that aren’t very computer literate. It has been virtually maintenance free. This is on wildly disparate hardware as well, and it’s always installed nicely and with little messing around after to get things working.
People like to hate on it; it’s been by far the most reliable distro I’ve used, far better than "just works^TM " distros like Fedora and Ubuntu. I’d ignore the naysayers and use if it works for you.
A distro isn’t just a way to interact with the Linux operating system. It’s a collection of tools that helps you do it. Some tools are just sharper that others. The community just likes debating about this important nuance. It’s not that complicated.
My tools of choice come from the famous blue logo distro.
I think it’s fairly obvious that they mean Arch because they are sharing which distro they use without being prompted, which is inline with a common running joke about doing the same thing, btw.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.