|
so if clear linux is so great why doesn't anybody else merge their patches upstream
|
#
?
Feb 26, 2024 21:39
|
|
|
|
| # ? Jun 9, 2024 09:29 |
|
|
(for those who don't remember, because you may have needed to pay attention for this one: the powervr thing was intel shipping a series of atom chips with powervr gpus, intended for phones and ultra-low-power netbooks, and while intel paid up for a bunch of driver dev it was still ip blobs and bugs all the way down until they abandoned it for in-house graphics next gen)
|
|
#
?
Feb 26, 2024 21:40
|
|
|
lol I forgot they tried to make Atom a thing
|
|
#
?
Feb 26, 2024 21:41
|
|
|
on the theme i'm going we'd have all been better off had atom phones been a thing. there's people out there still running the asus atom phones because you can pretty much install a stock linux on it and it'll work. as opposed to any and every arm phone.
|
|
#
?
Feb 26, 2024 21:42
|
|
|
remember when ARM developers threw a temper tantrum over their endless poo poo being labeled "cute embedded nonsense hacks" should give them all "I make e-waste" T-shirts
|
|
#
?
Feb 26, 2024 21:46
|
|
|
phones really ought to have uefi and acpi firmware like any respectable computer system these days imagine having a laptop from february 2019 and being told "oh i'm sorry sir that model no longer qualifies for security updates, would you be interested in our 2024 model?" (of course apple silicon moved in precisely the opposite direction because lol gently caress the existence of general purpose computers i guess)
|
|
#
?
Feb 26, 2024 21:52
|
|
|
european union save me pls
|
|
#
?
Feb 26, 2024 21:53
|
|
|
to make this a clear-cut popular opinion, gently caress qualcomm in particular forever. far from alone, but as far as mustasche-twirling ewaste-creation they're the loving peak.
|
|
#
?
Feb 26, 2024 21:55
|
|
|
Sapozhnik posted:so if clear linux is so great why doesn't anybody else merge their patches upstream honestly idk. i know some of the optimizations they do are intel hardware specific, but it's certainly not all of them, and amd cpus still benefit from using it anyway (benchmarks back this up iirc) i'd guess it being x86-specific probably being the reason why more than anything else, but like i said i have no idea. not really my domain
|
|
#
?
Feb 26, 2024 23:01
|
|
|
Cybernetic Vermin posted:gently caress qualcomm in particular forever. yep
|
|
#
?
Feb 26, 2024 23:04
|
|
|
Sapozhnik posted:phones really ought to have uefi and acpi firmware like any respectable computer system these days android does use acpi, but uefi not so much
|
|
#
?
Feb 26, 2024 23:05
|
|
|
the Qualcomm parts I was evaluating last time I worked at an Android OEM could boot Linux on top of UEFI. you could also still do littlekernel if you wanted to but iirc some SoC features and support were gated on enabling UEFI secure boot. seemed like that was the direction the SoC makers were pushing everyone. unfortunately whether or not it’s UEFI has nothing to do with whether Qualcomm will keep the BSP updated or whether the OEM will ship the software updates past 2-3 years
|
|
#
?
Feb 26, 2024 23:58
|
|
|
spankmeister posted:it's ok to like things or not like things 
|
|
#
?
Feb 26, 2024 23:58
|
|
|
zero knowledge posted:the Qualcomm parts I was evaluating last time I worked at an Android OEM could boot Linux on top of UEFI. you could also still do littlekernel if you wanted to but iirc some SoC features and support were gated on enabling UEFI secure boot. seemed like that was the direction the SoC makers were pushing everyone. yeah i know it can (even ios devices can too, technically, they did before iboot was finished), it just almost always doesn't i imagine they have to have UEFI compatibility for windows though. probably explains the secure boot requirements too
|
|
#
?
Feb 27, 2024 00:39
|
|
|
the only thing qualcomm got right was eudora
|
|
#
?
Feb 27, 2024 02:07
|
|
|
lolhttps://computerhistory.org/blog/the-eudora-email-client-source-code/ posted:• sanitization of “bad words”, mostly in comments, as requested by Qualcomm
|
|
#
?
Feb 27, 2024 02:25
|
|
|
man those computer magazine ads for Eudora brought back a nostalgia wave for mid-90s optimism. What were we going to do with this burgeoning platform called the information superhighway?
|
|
#
?
Feb 27, 2024 03:23
|
|
|
Sapozhnik posted:phones really ought to have IEEE-1285 open firmware like any respectable computer system these days
|
|
#
?
Feb 27, 2024 09:11
|
|
|
Sapozhnik posted:phones really ought to have uefi and acpi firmware like any respectable computer system these days imagine thinking uefi and acpi are in any way acceptable standards unless you're forced to use them because you want to build something compatible with the pc clone ecosystem uefi secure boot is so deficient apple had to put a second computer (the t2 security chip) inside late model intel macs to provide all the security features they wanted, as detailed here https://www.youtube.com/watch?v=3byNNUReyvE&t=147s there was never a chance apple was going to use uefi on apple silicon macs, it's poo poo. you only think it's not poo poo because it is orders of magnitude better than what it replaced, but what it replaced was so incredibly bad that there's plenty of room to be amazingly better while still being objectively poop
|
|
#
?
Feb 27, 2024 10:25
|
|
|
https://thehackernews.com/2023/12/logofail-uefi-vulnerabilities-expose.html?m=1
|
|
#
?
Feb 27, 2024 14:52
|
|
|
the security features they wanted: - full control of end user devices - gently caress you e: not saying uefi is great, but it's less bad than "gently caress you"
|
|
#
?
Feb 27, 2024 14:58
|
|
|
well a lot of android phones do indeed give you full control of your device, but all of the power management stuff lives in out-of-tree kernel hacks instead of system firmware, because the system firmware is a first-stage bootloader and nothing else beyond that. you would need a few other things on top of that, like a pci bus and nvme storage. and i suppose some sort of xhci extension that allows for the device to operate as a usb gadget. but that gives you enough firmware services and generic device classes to boot up a generic operating system image and suspend/resume it. arm macs are ipads with an unlocked bootloader. well, an unlocked bootloader on the application processor, but not on the dozen other cpus located inside the machine, the totality of which all run macos. so you can't really run alternative operating systems on it, you can dismember macos (which you cannot legally redistribute in whole or in part, by the way) and then reanalyze and reintegrate the undocumented interfaces every single time somebody in cupertino cuts a build. could those accessory cpus each run a generic firmware that provides a stable firmware interface? sure, but why would they, it's not supposed to be a hardware platform, it's supposed to be an appliance. easier to just drop support after five years and turn millions of machines into ewaste.
|
|
#
?
Feb 27, 2024 15:24
|
|
|
you do get a pci bus on android and nvme (on some devices, most are probably eMMC or UFS), and xhci like, lspci/lsusb will work exactly as you expect it to. android phones are, ime, more like a pc than not. ios devices are a different thing entirely, apple kinda dropped the whole "general purpose computer" concept
|
|
#
?
Feb 27, 2024 16:11
|
|
|
BobHoward posted:imagine thinking uefi and acpi are in any way acceptable standards unless you're forced to use them because you want to build something compatible with the pc clone ecosystem do you already have your "I make e-waste" T-shirt or do you still need to get it?
|
|
#
?
Feb 27, 2024 20:14
|
|
|
Beeftweeter posted:you do get a pci bus on android and nvme (on some devices, most are probably eMMC or UFS), and xhci android phones still put a lot of peripherals on the soc with shared memory being the primary means of communication between cores at least iphones put their modem out on usb (or maybe pcie)?
|
|
#
?
Feb 27, 2024 20:28
|
|
|
outhole surfer posted:android phones still put a lot of peripherals on the soc with shared memory being the primary means of communication between cores some do, some don't. the palm phone definitely has mostly everything on the soc for example, but you can still get an ACPI description of the hardware, list pcie devices (which the gpu is at least nominally attached to), list usb devices (mostly cameras, unless you have something else attached), check out the i2c bus, etc. i mean, it's still linux. there's only so many ways to get a running system, and why reinvent the wheel
|
|
#
?
Feb 27, 2024 20:39
|
|
|
Beeftweeter posted:some do, some don't. the palm phone definitely has mostly everything on the soc for example, but you can still get an ACPI description of the hardware, list pcie devices (which the gpu is at least nominally attached to), list usb devices (mostly cameras, unless you have something else attached), check out the i2c bus, etc. it isn't a some do, some don't sorta thing i challenge you to find an android device from the last 5 years that uses an off-chip baseband android devices either have the baseband on the soc, or they don't have a baseband at all (and in the case of no baseband at all, it's often still there, it just doesn't have the external hardware available to be useful)
|
|
#
?
Feb 27, 2024 20:42
|
|
|
well, i don't have any android devices that are newer than that lol palm phone is the newest, and the highest end one is a 2018ish huawei mate 10 pro and while the palm definitely has it on chip, the huawei might have a separate modem, i'm not sure. since the bootloader is permanently locked i can't really find out
|
|
#
?
Feb 27, 2024 20:47
|
|
|
actually i did get a LTE hotspot from t-mobile for free recently that turns out runs android. maybe that has separate baseband? i mean, probably not, but it's possible i suppose
|
|
#
?
Feb 27, 2024 20:52
|
|
|
the huawei has a kirin 970, which has a built in baseband https://www.hisilicon.com/en/products/Kirin/Kirin-flagship-chips/Kirin-970 basically the only android capable arm socs that don't ship with a built in baseband are destined for set top boxes, cars or cameras, and are probably rockchip, allwinner, or freescale chips. pinephone and librem both have separate baseband controllers, but those baseband controllers run their own copy of linux and are basically a smartphone within a smartphone, with the inner smartphone sharing memory between the dsp and a hosed up android
|
|
#
?
Feb 27, 2024 21:03
|
|
|
outhole surfer posted:the huawei has a kirin 970, which has a built in baseband ahh. well, ok. not much i can really do about it i guess outhole surfer posted:basically the only android capable arm socs that don't ship with a built in baseband are destined for set top boxes, cars or cameras, and are probably rockchip, allwinner, or freescale chips. incidentally i think the t-mobile thing i got (https://www.t-mobile.com/support/coverage/test-drive-hotspot) seems to use a qualcomm soc, (from reading this https://github.com/c-herz/TMOHS1-Root-Utility source) so that probably has on-chip baseband too. i don't feel like digging it out to check for sure, but that'd be not terribly surprising anyway e: huh, there's a buildroot for it here https://github.com/c-herz/tmohs-buildroot i poked around a bit but couldn't determine the specific platform. doesn't really matter tbh. interestingly it seems to support uefi though Beeftweeter fucked around with this message at 22:11 on Feb 27, 2024 |
|
#
?
Feb 27, 2024 22:01
|
|
|
Truga posted:the security features they wanted: is it opposite day in here? microsoft requires all pcs capable of running windows to do UEFI secure boot only, no unsigned operating systems. PC OEMs mostly don't bother including certs from anyone but microsoft in their UEFI images. put these things together and debian has to pay microsoft to sign their bootloaders with one of microsoft's private signing keys to microsoft's credit, their signing service isn't excessively costly (~$100 per signature iirc), and they don't seem to be abusing it to gatekeep anyone from being able to ship alternate operating systems, but if you're going to go around holding up UEFI as something which doesn't say "gently caress you", imo it should give you pause that its deficiencies plus market forces have put microsoft in a position where they can gatekeep apple silicon macs also have always-on secure boot, but provide their owners the ability to attest that they'd like to boot an unsigned OS. this attestation creates and enrolls a signature in that mac's secure enclave, meaning boot is still fully secure and tamper proof up to the point where apple's firmware hands control over to the user-attested binary so, though the OOTB config of an apple silicon mac is extremely "locked down", its owner has the power to downgrade security for apple's own operating systems, or install an unsigned OS. this is more control than modern UEFI PCs give you! and on the topic of "gently caress yous", how about SMM, or intel ME? apple silicon does not appear to have equivalents to these, there's no stay-behind networks baked in to the platform doing random poo poo behind the kernel's back. linux owns 100% of the application processor cycles and the coprocessors are sharply limited in what they can do (more on that below) Sapozhnik posted:arm macs are ipads with an unlocked bootloader. well, an unlocked bootloader on the application processor, but not on the dozen other cpus located inside the machine, the totality of which all run macos. so you can't really run alternative operating systems on it, you can dismember macos (which you cannot legally redistribute in whole or in part, by the way) and then reanalyze and reintegrate the undocumented interfaces every single time somebody in cupertino cuts a build. could those accessory cpus each run a generic firmware that provides a stable firmware interface? sure, but why would they, it's not supposed to be a hardware platform, it's supposed to be an appliance. easier to just drop support after five years and turn millions of machines into ewaste. the coprocessors don't run macos. most run RTKit, apple's minimalist RTOS, hosting essentially the bottom half of a darwin device driver for the peripheral (or collection of peripherals) managed by that coprocessor it is true that, unlike the application processors, they're only allowed to boot blobs signed by apple, but that's not the whole picture. the asahi linux project established early on that coprocessors are mostly optional. the registers of hardware peripherals managed by each coprocessor are visible to the application processors too, so if you want to fully reverse engineer the hardware, you can write traditional linux device drivers running on the APs and just halt the coprocessors and ignore them despite this, asahi devs have chosen to use the coprocessors in most cases, as it's much less reverse engineering work. they have excellent protection from apple fuckery in the firmware blobs, since apple gives each coprocessor its own private IOMMU managed by the application processors. these are set up to silo each coprocessor into the minimum amount of memory and MMIO it needs to do its job (apple does this sandboxing in macos too. it's part of their "defense in depth" security philosophy - if someone finds a vuln in a coprocessor firmware blob, it should be as hard as possible to develop that into an exploit which affects anything outside that one coprocessor) none of this dooms an apple silicon mac to suddenly teleport itself to ewaste the second apple drops support. linux should be able to give such machines a longer life
|
|
#
?
Feb 28, 2024 12:45
|
|
|
secure boot is lovely security theater, which you can disable iphone isn't lovely security theater, but you can't disable it either so it's worse idk how it works on a m1 macbook because i haven't worked with one yet, but if it lets you sign your own kernel, good on them Truga fucked around with this message at 13:05 on Feb 28, 2024 |
|
#
?
Feb 28, 2024 13:02
|
|
|
BobHoward posted:is it opposite day in here? this is straight up misinformation - windows 11 only requires that the PC is *capable* of secure boot - you can toggle secure boot off and it will boot windows 11 just fine (you can also turn TPM off, windows will just disable the features that rely on it) - you can toggle secure boot off and it will obviously boot any unsigned OS you want - most motherboards will happily let you enroll your own secure boot key. here are ventoy's, a little utility bootloader, instructions for enrolling keys and re-enabling secure boot. or you can do that from the UEFI software directly if you want to be safe and never boot anything unsigned, eg. mine looks like this:  - the reason debian and fedora have their images signed by Microsoft is only so that their users don't have to go through the step described above i don't know anything about macos but if you speak so confidently about stuff that can be verified in two minutes I am not going to trust anything you say about other platforms either NihilCredo fucked around with this message at 14:36 on Feb 28, 2024 |
|
#
?
Feb 28, 2024 14:33
|
|
|
|
|
#
?
Feb 28, 2024 17:49
|
|
|
KDE MegaRelease 6
|
|
#
?
Feb 28, 2024 17:52
|
|
|
proper chain of trust is good and important, linux nerds have cried about it for decades, and it has caused basically no issues in itself. hating uefi is pointless, the competition for it is hardware shipping a basically a blob (usually a mindlessly hacked up linux for those that want to view that as a win) that is supported for a tiny fraction of the devices life (importantly i here do consider zero a tiny fraction)
|
|
#
?
Feb 28, 2024 17:53
|
|
|
secure boot turns people into total dipshits in the same way wayland does. the only system i've ever had any trouble with custom keys on was a lenovo laptop that depended on some signed option rom, and wiping the default keys would brick the laptop. i returned that machine and went on with my life. every other machine i've touched since secure boot became a thing has offered the ability to install your own secure boot databases with no issue.
|
|
#
?
Feb 28, 2024 17:54
|
|
|
Do windows laptops with arm processors allow you to disable secure boot?
|
|
#
?
Feb 28, 2024 17:55
|
|
|
|
| # ? Jun 9, 2024 09:29 |
|
|
BobHoward posted:is it opposite day in here? This is not correct. Linux distros do not pay for signatures; signing review happens in public; Debian doesn't have particular difficulty with this process.
|
|
#
?
Feb 28, 2024 17:57
|
|
