Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Freedom and security issues on x86 platforms

mail.fsfeurope.org

Post reply on HN
Print view View original

191–200 of 282 posts

Re: Freedom and security issues on x86 platforms

#191

Post by broodbucket »

zanny wrote: post #51
mpnordland wrote: post #21

It's great that these guys pushing POWER8 at least have a workable situation, but at least for me, throwing $3,700 at a motherboard (Alone!) just isn't feasible. I would love to be free of proprietary firmware, but it would seem that's only for people better off than myself.

Consider the news of the Model 3 this week. There is no reason POWER8 cannot follow a similar trajectory, start with the Roadster equivalent $4k luxury workstation, move down to the performance desktop around $1500, and then release the mass market mobile / integrated board at $300 that can still go head to head with x86.

It can, but IBM doesn't care about those markets. OpenPOWER members could make their own stuff and aim it at consumers, it just takes a long time given OpenPOWER itself is only a couple years old.

Re: Freedom and security issues on x86 platforms

#192

Post by LargoLasskhyfv »

CyberDildonics wrote: post #128
nickpsecurity wrote: post #111

Earlier quoted context omitted.

Exactly. There's a ton of implementations ranging from free for FPGA's to S-ASIC's from eASIC to embedded CPU's from Gaisler to cloud servers from Oracle to mainframes from Fujitsu & Russia. One can also legally clean-slate a SPARC chip without legal fears. Unlike POWER, ARM, and MIPS. The ISA, its docs, a firmware standard... all of that already open. So, why is it not on the table for... anything in FOSS? Doesn't s…

This makes me wonder why we don't see sparc chips in things like routers or other hardware that doesn't require lots of binary compatibility from 3rd party software.

There were: http://www.kaltech.co.il/pdf/LEONSPARRAIDProcessor.pdf

Re: Freedom and security issues on x86 platforms

#193

Post by rcarmo »

nickpsecurity wrote: post #115
kabdib wrote: post #55

Earlier quoted context omitted.

Is SPARC unpopular because of its power consumption?

There used to be a lot of competition between several types of RISC machine and several x86 vendors. I know about the consolidations on x86 side. I'm not sure why SPARC lost favor versus others, though. I wasn't able to afford RISC workstations back when all that was happening. It would be nice for one of older folks to chime in on what made SPARC unpopular back then.

It was the cost/performance ratio, not of the CPU itself, but of the entire thing, including software. Sun sold highly performing, but extremely overpriced hardware that rode in on the hype it built around the architecture but failed to deliver on flexibility and bang for the buck.

I was involved in launching an ISP where the whole shebang ran on Sun boxes, and which was over-dimensioned to the point where I once stepped into the data center and found a waist-high box full of E250/E450... Feet. The purple plastic ones you had to remove to rack mount the things.

Two years later we'd shrunk down most of the whole thing (except the storage bits, where SPARC still had good performance) to a few racks of Compaq and Dell boxes that were vastly cheaper to maintain (both because they were cheaper, period, and because we didn't need to wrestle with Solaris and the compilers of the time to get stuff working on them).

This was back in 1999 or so, and I never saw a SPARC system in production after 2005 (until a few months back when I visited a telco customer who still swears by them for a very specific purpose).

I still have one of those plastic feet on my desk at home, as a reminder of the folly of buying single-vendor solutions. It sucks as a paperweight. :)

Re: Freedom and security issues on x86 platforms

#194

Post by astrobe_ »

darpa_escapee wrote: post #170
5ilv3r wrote: post #60

Earlier quoted context omitted.

My dtb is generated from a dts at kernel compile time... Chromebook land is fun.

Lucky. I have to hunt around for DTBs based on modified Rockchip and Freescale SoCs to update my devices. I am unwilling to distribute said binaries to make it easier for people with the same hardware as I to update their 3 year old software. That, too, is a shame.

So it's not an "ARM architectures" issue. It's a problem between you and your provider, who for some reason is not willing to provide the DTS.

That said, given that DTB/DTS is an open spec, tools to reverse a DTB into a DTS should probably exist (like this one: http://forum.xda-developers.com/android/software-hacking/how...)

Re: Freedom and security issues on x86 platforms

#195

Post by kristoffer »

nickpsecurity wrote: post #144
wolfgke wrote: post #135

Earlier quoted context omitted.

Because ARM and MIPS chips are a lot more power-efficient.

Because the chip-makers and chip buyers are using ARM and MIPS in power-efficient SOC's. They could do the same with SPARC. They just didn't for whatever reasons. Far as power efficiency, kristoffer might be able to chime in as it's not in the data sheets for Gaisler. That's suspicious: either the numbers are bad or they leave it off given its meant for customization. Anyway, the Leon4... http://www.gaisler.com/index…

Power consumption is of course very much dependent on the chosen fabrication process and SoC configuration. A LEON3/4 core is comparable to something like a ARM Cortex-M7 and it is not the ISA (when comparing ARMv7 vs SPARCv8) but the implementation that will affect power most. LEON is quite small and power efficient.

Re: Freedom and security issues on x86 platforms

#196

Post by vox_mollis »

hackuser wrote: post #36

This sounds similar to basebands on cellular devices: Subsystems controlled by the vendor, not accessible from the 'user' system, remotely updatable and with access to everything.

Except modern baseband processors usually don't have direct access to main memory or peripherals - they are usually linked to the rest of the phone via a serial bus.

ME is very, very different - it transparently has access to everything.

Re: Freedom and security issues on x86 platforms

#197

Post by hackuser »

vox_mollis wrote: post #196
hackuser wrote: post #36

This sounds similar to basebands on cellular devices: Subsystems controlled by the vendor, not accessible from the 'user' system, remotely updatable and with access to everything.

Except modern baseband processors usually don't have direct access to main memory or peripherals - they are usually linked to the rest of the phone via a serial bus. ME is very, very different - it transparently has access to everything.

> Except modern baseband processors usually don't have direct access to main memory or peripherals - they are usually linked to the rest of the phone via a serial bus.

Do you know where I can read more about that? A good, technical, authoritative resource? In my little bit of research, details are sparse and authoritative technical details even more sparse.

Re: Freedom and security issues on x86 platforms

#198

Post by snuxoll »

tinco wrote: post #48
TazeTSchnitzel wrote: post #16

I wonder if Apple might do something about this. They don't care so much for the FOSS side of things, obviously, but I wonder if they might demand chips from Intel without the management engine, because it's a potential attack vector they can't control.

I suspect at some point they will simply drop Intel for their own (ARM) platform. I think moving will be easy once all app store submissions are in bitcode.

bitcode is still architecture dependent, bitcode generated for x86 won't run on ARM. The only reason they are requiring bitcode is so CPU specific optimizations can be done, not to allow for portability between uarchs.

Re: Freedom and security issues on x86 platforms

#199

Post by gravypod »

nickpsecurity wrote: post #42

Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the only architecture that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware ex…

I'm very into operating system development. Does anyone know if the SPARC architecture offers the same problems that other systems require?

Some things like GDT, or lack of a hardware discovery that are anyoying.

Anyone here worked with this?

Re: Freedom and security issues on x86 platforms

#200

Post by xorblurb »

marssaxman wrote: post #158
muricula wrote: post #34

Earlier quoted context omitted.

I doubt it. The powerpc to Intel switch was really painful because the desktop platform has the perpetual ball and chain of backward compatability. I doubt Apple would try to beat Intel at their own high performance game anyway.

Having previously gone through the 68k-PowerPC switch, the PowerPC-x86 switch seemed to me like a non-event. The desktop platform most certainly does not have a perpetual backward compatibility obligation; Apple has always been far more willing than Microsoft to break old stuff after a few years if it happens to conflict with their new stuff. I would expect that they have already been building OS X for ARM internally…

> Apple has always been far more willing than Microsoft to break old stuff after a few years if it happens to conflict with their new stuff.

Sidetracking this conversation a little, but I'm more and more wondering whether MS actually has a retrocompatibility track record that is that good, or if it is just a nice story. Granted, they communicate a lot on how hard they work on that subject, and they even have a guy who blogs about that and about how great he is because he injects patches in third parties programs to let them work on new OS versions, but the end result is just... random. -- Well, maybe that guy should work on compat between MS products before those of others...

First no medium/big company would think of upgrading the OS without months or even years of studies and tries -- they likely could do and already are doing the same with OS X, then MS actually actively deprecate a lot of stuff all the time (and even whole subarchs, like Win16 not avail on Win64 installs), they also have so much tech and product birth fail it is not even funny anymore, and finally even when they don't mean to, their very own products in more or less the same line are often broken by next versions supposed to be able to install side-by-side or even just patches (example: Windows SDK 7.1, which is upset if you try to install it with anything else than the .NET 4 RTM preinstalled, and then is very upset again during builds if you upgrade your .NET to 4.6 -- or on a completely different subject compat of recent Words with old .doc which is not stellar)

And finally on the technical design side, some choices are just plain complete crap and stupid. Why would you, I don't know, leverage UMDF (that is especially well suited for USB drivers, for example) to allow 32 bits drivers to run on 64 bits Windows when you can just not give a fuck and force people to use their old consumer or dedicated pro hardware with their old computer, and let them throw everything in the trash when it eventually fails. I mean, during the 16 -> 32 bits transition they actually made far more insane things working (at least kind of working) while here everything would be neatly isolated yet they manage to... not even attempt to do it.

I'll not even begin to talk about the .dll story, which is just even more complicated each time they try to fix it because you still have to support the old methods, sometime by some kind of virtualisation. And then, like I said, they just decide to change their mind and use the old replacement method again, (ex: the .NET 4 => 4.5/4.6 mess explained before) which breaks again because they are still not THAT good at backward compat. (In a cringeful way: have anybody heard about symbol versioning?)

So maybe Apple is doing worse (I don't know much about them), but on a Linux system you can actually administer it carefully if you are skilled enough to make any random old application crap REALLY work on a modern install (you might need to duplicate a complete userspace to do that, but not all the time thanks to symbol versioning, and it is not necessarily huge when you do, and at least you can).

Post reply on HN