Whether it's cost prohibitive or not, it's impossible to keep those devices secure and updated. That's just how it is. People are misled by many cultists that the OS is the only thing you need to update, which is completely false.
@inference
It is false, but it's not unreasonable. What are the chances of encountering a threat targeted at specific hardware in the wild? If someone has physical access to your device, you're fscked anyway. And that's security, their privacy is more often threatened by newer software, by stuff marketed as useful features that come built right into their ROM.
I don't disagree with you, but claiming older devices a privacy nightmare is a bit of a stretch too 🤷
@rqsd@borg.social
@inference
> Apple have mitigated M1 vulnerabilities, same as how Intel and AMD have done in their chips.
Exactly! That's why the ones who expect vulnerabilities to be fixed on OS level aren't crazy (I thought that was your point), it's possible, but there is a 99,(9)% chance that it'll never get done😄
The ones who don't want to upgrade aren't unreasonable, maybe the troubles that (ALWAYS!) come with new devices outweight the security risk for them🤷
@rqsd@borg.social
@inference
Because it's *more reasonable* to fix it at firmware level, not because it's the only way. They can't fix it on hardware level, and OS-level patch will likely be more complex and have a bigger impact on performance — and that's it. Imagine we don't have flashable firmware and patchable microcode, would they go for that more complex OS-level solution? Yes, they most probably would. It's possible — that's my point.
@rqsd@borg.social
@inference
> can partially mitigate Spectre and Meltdown etc, but cannot fully do so
It could if it didn't use flat memory model. Spectre/Meltdown wouldn't have happened in the first place if that was the case. 386 protected mode looked so… protected to me with segmented addressing. I've lost track of how stuff works when everyone was transitioning to x86-64 — this design is just asking for trouble. And look where it got us 😂
@rqsd@borg.social
@inference But address randomization won't even be needed if segmented addressing is used 🤔
As there is no way for one process to do what CPU might treat as addressing memory of another process. Yeah, it makes IPC more complex, microkernels make it more complex as well. But isn't that the proper fundamental solution to this problem? Address randomization is just a quirk!
Neither Linux, nor Windows ever used all the features of PM, only OS/2 did that AFAIK
@inference
Not completely! Secure boot and chain of trust stuff was there for decades, but we still have jailbroken iPhones and all that. Yeah, I know, verified boot is different, okay-okay 😅
And we're only talking well-known exploits here, you can't prove there aren't any 0-day ones. There is no such thing as 100% secure and with physical access the amount of attack vectors is *always* higher. You just choose what security level is acceptable to you.
@rqsd@borg.social
An example in any phone, regardless of OEM or OS, is the SoC TEE; an exploit in that means even apps could see other apps' and even system encryption keys. Only SoC firmware patches can prevent that.
@inference
> You're basically allowing everyone to pwn you for the entire time
Well, yeah! But if it is not a remote exploit, maybe it's an acceptable threat level for me? I don't want to get a new phone, but I consider physical access fatal so I don't have anything sensitive on my phone. You, being into infosec, have everything patched and up to date and may have more on your phone than me. Neither of us is crazy, let's not get dogmatic — that was my original point actually 😅
@rqsd@borg.social
@inference
> Neither of us is crazy
Well, except for those who neither take security measures, nor are conscious about what to expect from their devices, who are like: "Oh, I have all my photos synced eyeCloud, using 'password' as password and now all my nude pics are online!" 😱
@rqsd@borg.social
I don't lie about how things *actually* work, nor do I use ideology over fact, logic, and evidence. I will never join a cult like the FOSS cult.
@inference
> state that it *decreases* security and privacy when that's outright malicious to state
I think what they state is that if firmware was open everyone could audit it, and eventually it'll get more secure. Making firmware closed and harder to access does make vulnerabilities harder to find, but makes them impossible to fix by anyone other than the original developer. The fact that making something open makes it more secure by itself is just a widespread misinterpretation.
Proprietary at least has monetary incentive behind it and is often properly signed etc. It also has paid developers working on it.
Open source is auditable, but that means nothing if the codebase is massive or people aren't actually auditing it. I know I don't bother if the code is more than something like 100-200 lines long.
If someone thinks I'm going to audit Clang or Linux just because I'm a security researcher, they have another thing coming.
I think it's mostly a matter of voluntary vs obligatory labor, but I think there's an illusion of inherent security that leads to complacency.
@inference
M1racles is known for over a year — it's a hardware fault that cannot be fixed properly, only mitigated at other levels to a certain point. Is everyone advised to put their M1-bases Macs in the dumpster? I think not, because that hardware isn't exactly old. People expecting vulnerabilities to be fixed on other levels (OS in our case) aren't oblivious, this can be done in theory, but they are wrong because no one has incentive to do so.
@rqsd@borg.social