Slashdot Mirror
Privacy-Centric Linux Distro Tails 3.0 Will Drop 32-Bit Processor Support (betanews.com)
All of its outgoing connections are routed through Tor, and it even blocks non-anonymous connections. You can carry it around on a USB stick, and Edward Snowden uses it. But a big change is coming with Tails 3.0. BrianFagioli quotes BetaNews: Unfortunately for some users, Tails will soon not work on their computers. The upcoming version 3.0 of the operating system is dropping 32-bit processor support. While a decline in compatibility is normally a bad thing, in this case, it is good. You see, because there are so few 32-bit Tails users, the team was wasting resources by supporting them. Not to mention, 64-bit processors are more secure too...
"In the beginning of 2016, only 4% of Tails users were still using a 32-bit computer. Of course, some of these computers will keep working for a while. But once the number had fallen this low, the benefits of switching Tails to 64-bit outweighed the reasons we had to keep supporting 32-bit computers," says the Tails team... "In the last few years, the developers who maintain Tails have spent lots of time addressing such issues. We would rather see them spend their time in ways that benefit our users on the long term, and not on problems that will vanish when Tails switches to 64-bit eventually."
"In the beginning of 2016, only 4% of Tails users were still using a 32-bit computer. Of course, some of these computers will keep working for a while. But once the number had fallen this low, the benefits of switching Tails to 64-bit outweighed the reasons we had to keep supporting 32-bit computers," says the Tails team... "In the last few years, the developers who maintain Tails have spent lots of time addressing such issues. We would rather see them spend their time in ways that benefit our users on the long term, and not on problems that will vanish when Tails switches to 64-bit eventually."
Not to mention, 64-bit processors are more secure too...
I'm not posting to doubt the author's assertion here, but rather to request more information: a link to the security benefits of one size over another would be nice. Is DEP something inherently impossible on 32-bit processors? Is the advantage really linked to word size, or is it more a function of new parts added to more recent processors?
Consumer 64 bit CPUs have been around since the 2003 AMD Opteron, so getting on towards a decade and a half soon now. And workstation class 64 bit was available for many years before that.
It's cool that Linux itself supports really old hardware, but when it comes to a small distro team trying to support niche architectures, sometimes you have to pick your battles. If there's sufficient interest in 32 bit, then the interested parties can provide the necessary support.
Dealing with security and privacy is hard, and there aren't many OSs trying to do it at all, so it seems apt for the Tails team to focus where they can have the maximum impact for the resources they have available.
... that 4% of users are using 32-bit systems? Can't be that private if they're collecting telemetry from their own userbase...
Considering who the platform was meant to help in the first place, this is not good news.
Imagine this scenario, you're an informer on the run, you have to hide because you've got a secret that must eventually get out to the public. You have no access to modern computer, but could possibly scrape together some old computer parts to make one, perhaps an old disgarded 32 bit laptop somewhere in the dumpsters in an opressed country where even old computers are gold.
And you can't install it because it requires a 64 bit processor, well - bummer.
Any other day I'd agree with that decision, but in this case - I think it should be as compatible as possible with as much hardware as possible, focus less on modern things, and focus more on safe communications.
What this world is coming to - is for you and me to decide.
You have to go back over 10 years for Intel and a few generations for AMD to be able to build firmware for your mainboard that is all open source, without all the closed Blobs. So what's the point of a secure OS with a backdoored BIOS?
plain and simple
See my subject: I said it the other day in an Apple article (they're heading same way & soon so am I) https://apple.slashdot.org/comments.pl?sid=10190241&cid=53786367/
* It makes sense & makes things easier not having to pay attention to 2 builds vs. 1... in my case, this may be the last 32-bit build ever in SR-7 that I released yesterday.
(Mine's simple to do though - I build the 64-bit model 1st, & then simply copy it's single unit over to the 32-bit model's folder, editing "32-bit" strings to "64-bit" for string resources + retargetting it to 32-bit - it's EXACTLY the same code is why it's simpler to do - gotta LOVE Delphi for that & the fact it compiles on all the 'majors' in 32 bit, mostly in 64-bit, & soon ALL 64-bit, AGAIN including Linux (then, I port this program to 'everywhere'))
APK
P.S.=> However, I ask users who email me on questions on how to fully use the program, what version they use - 1st few years, it was rougly a 50/50 split between 32 & 64 bit usage - now? It's almost PURE 64-bit, 4++ yrs. later (after public release, it's MUCH older than that but I kept it to myself but the 'malware explosion' circa 2008-2011 is what made me let it out as a freebie)... apk
> 64-bit processors are more secure too...
Sure, when Apple does it it's because they're money-grubbing pricks, but when a Linux vendor does it, it's because of security.
We already dropped 32-bit support in DFly. There are many good reasons for doing it on Linux and the other BSDs as well. I will outline a few of them.
(1) The big reason is that kernel algorithms on FreeBSD, DragonFly, and Linux are starting to seriously rely on having a 64-bit address space to be able to properly size kernel data structures and KVM reservations. While (for FreeBSD) 32 bit builds still work, resource limitations are fairly confining relative to the resources that modern machines have (even 32-bit ones).
(2) Being able to have a DMAP makes kernel programming a whole lot easier. You can't have one on a 32-bit system unless you limit ram to something like 1GB. Being able to make a DMAP a kernel-standard requirement is important moving forwards.
(3) Modern systems are beginning to rely more and more (on x86 anyway) on having the %xmm registers available. To the point where many compilers now just assume that they will exist. ARM's 64-bit architecture also has some nice goodies that it would be nice to be able to rely on being available in-kernel.
(4) Optimizations for 64-bit systems create regressions on 32-bit systems. Memory copies, zeroing, and setmem, for example. Even if 32-bit support is kept, performance on those systems will continue to drop.
(5) There is a lot of ancient cruft in 32-bit code that we kernel programmers don't like to have to sift through. For example, being able to get rid of the EISA and most of the ISA support went a long ways towards cleaning up the codebase. Old drivers are a stick in the craw because nobody can test them any more, so the chances of them even working on an old system is reduced for every release. Eventually it gets to the point where there's no point trying to maintain the old driver.
(6) People should not expect modern features on old machines. The cost of replacing that old machine is minimal. Live with it. It's part of the price of progress. If the industry is a bit slow understanding what 'old' means, than the fewer systems which support these older architectures the better, it will make the point more obvious to the corporations who've lost their innovative edge.
(7) For ARM, going back to the corporate point, there's really no reason under the sun to continue to produce 32-bit cpus, even for highly embedded and IOT stuff. The world has moved on, and even embedded systems have major resource limitations in 32-bit configurations. If kernel programmers have to put an exclamation mark on that point, then so be it.
-Matt
It is being done to give a false sense of security since over half of the computers out today have Intel ME or AMD's equivalent on them, and make it easier to make Tails appear secure for whistleblower usage when in actuality the backdoored ME means everything you thought was done securely via Tails has actually been backdoored. Whereas the slightly less secure 32 bit processors are actually more secure because they didn't leak your keys!
I honestly thought Edward Snowden might use OpenBSD because it is more secure than Linux. The allegations of backdoors in the IPSEC stack were proven to be false during an intensive security audit by the OpenBSD team. The OpenBSD team regularly audits their code and is transparent about bugs found. But, I digress, I am an OpenBSD fanboi. OpenBSD powers my router/gateway, server, desktop, and laptop. In my world, if it is capable of running OpenBSD, it does.
Is it really such a bitch to abstract word size in this software? That's a rhetorical question, really. It shouldn't be that hard if you had actually been thinking about it all along. What happens when 128-bit CPUs become preferred? I remember the bad old days of segment:offset in 16-bit, and boy was I glad to forget about that. OTOH, if we can emulate floating-point on 8-but CPUs, why can't we just drop down to an emulator on 32-bit and at least sort of support it? Sure it'd run slower than native but at least it'd be something.
Thanks for projecting you care & are scared shitless mr. advertiser/malwaremaker/botnetmaster/inferior competitor!
* If you advertisers didn't infect us, slow us down, track us (same w/ malwaremakers-botnet herders)? You wouldn't have ever seen my program in the light of day - I'd have kept it to myself... & you inferior competitors? LOL - truly are, inferior - I do FAR more for FAR less far more efficiently giving users more speed, security, reliability + anonymity online than you could EVER do (& you know it).)
APK
P.S.=> How damn dumb could you be with a reply like that? 10 below plantlife IQ is how dumb, lol... apk
Seems a bit odd to drop 32 bit with the Raspberry Pi and clones all over the place.
Anything in ring 0 or equiv can back door any older CPU with malicious firmware.
All of you faggots claiming to be secure on 32 bit don't realise 1 malicious kernel module is all that is needed, and you are fucked.
At least intel ME is manageable to an extent. Put it on a vlan, or just don't enable remote access.
Sure, there might be similar bugs in more recent CPU, but we know older chips are now unsafe from a root level attack.
... as my preferred privacy-centric OS. It's not as if there weren't alternatives. And 32-bit machines will be good enough to access the internet for many years to come. I'm allergic to software producers forcing me to upgrade hardware for no reason, and seeing what the audience for systems like Tails is, the decision is even more despicable, and I'd expect there to be a lot of people who'll be much less inclined, if even able, to upgrade their hardware on a whim than I am.
we will not remove 32-bit x86 support from T2SDE:
Also still got some mice 32-bit vintage machines, like Oqo01+ with Transmeta Efficieon, or Nokia Booklet 3G, with 32-bit only Atom Z, ...
In general I find it a bit sad to remove support to use older machines for poor families and third world countries.
sooo, im not a computer guy but, arent the 64 bits computers perfectly capable of running 32 bits stuff?
so the obvious question is: why dont they make only a 32 bit version of tails, so everybody can use it? because ive got the feeling the people running tails are not using it to run games so they really dont care if all their ram doesnt show up, and stuff like that, I mean, do you really need 64bits if you are an informer/snowden/spook? do you really need 64 bits to hack podestas email from siberia?
also, arent the new cpus basically botnets? ive read that in some chan somewhere
You are attempting to analyze this on the basis of first principles, but that is the wrong approach and it's steering you in an unhelpful direction.
First principles does indeed dictate that there's nothing fundamental that makes 32-bit processors more secure than 64-bit processors. So what is wrong with the logic?
The problem is that 32-bit processors tend to be older processors. And if they are new processors then they tend towards low cost, fewer features markets. The 64-bit processors are getting most of the feature goodness, most of the design time and attention. And those features certainly include security features.
Just look at the No Execute feature of modern processors. After a couple of false starts, this finally came into it's own in 64-bit processors. Is there any fundamental reason why No Execute cannot be back-ported to 32-bit processors? No, but what incentives to the chip designers have to do this when 64-bit seems to be the way of the future?
Clearly, it's not a sharp either-or, but the financial incentives tend to push the best stuff towards the newer designs and that generally means 64-bit.
"only 4% of Tails users were still using a 32-bit computer."
Tails is NSA, mein punks! Otherwise how would they know this!