Freedom and security issues on x86 platforms • Hacker News Board

Re: Freedom and security issues on x86 platforms

#121

Post by haikuginger » Mon, Apr 04, 2016, 6:26 PM UTC

muricula wrote: post #34

DenisM wrote: post #19

Earlier quoted context omitted.

Apple will be sitting pretty with their own CPU, heh? At least in the iOS devices, but who knowns what the (near) future brings to the Mac line.

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.

I don't think that's necessarily the case - I think that if Apple switched architectures now, there would be a lot fewer issues than there were with the Intel switch.

Over the past few years, Apple's done a lot of work in making the same system APIs available across multiple processor architectures; at a base level, iOS and OS X have very similar cores. You can see this with the ease of the transition from ARMv7 to ARMv8, which in most cases just required a new compilation.

As general-purpose applications have been migrated to higher-level APIs, the difficulty of porting those applications to a new processor architecture decreases; if an application is Cocoa-based and compiled for x64, then if those Cocoa APIs are available on an ARMv8 platform, they can be compiled natively for that platform.

Re: Freedom and security issues on x86 platforms

#122

Post by gsnedders » Mon, Apr 04, 2016, 6:27 PM UTC

simcop2387 wrote: post #104

BrainInAJar wrote: post #72

Earlier quoted context omitted.

Not to mention that ARM's ABI is hidden behind a paid NDA. ARM is even less open than x86

I'm not sure I know what you mean by ABI here? ABI in this case to me would mean Application Binary Interface, IE the C ABI that's defined by the platform and not the processor.

A number of architectures have published standard ABIs. ARM, PowerPC, MIPS, Itanium are all in this category. In some cases these are explicitly embedded ABIs (sometimes EABI).

For ARM, all major OSes I'm aware of use the ARM EABI2. (Note both the Linux kernel and gcc support other ABIs, so there is a real practical choice here.)

For PowerPC, at least all the little-endian 64-bit work for POWER8 has been done targeting the standard ABI. (I have no memory of whether big-endian ABIs for PowerPC follow the standard.)

Re: Freedom and security issues on x86 platforms

#123

Post by mtgx » Mon, Apr 04, 2016, 6:27 PM UTC

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…

Because Oracle tends to be hostile towards anything open source? With such an attitude, why ever bother supporting their technologies?

Re: Freedom and security issues on x86 platforms

#124

Post by oconnore » Mon, Apr 04, 2016, 6:27 PM UTC

kabdib wrote: post #52

Even if the ME was opened, the chips themselves are complex enough that nearly anything could be hidden. State machines that enable backdoors from instruction sequences can be pretty small (triggering these from a preferred vector, such as a web browser, seems hard-ish though).

On the CPU: extract some bits from sequentially allocated memory, a la steganography. When those bits match a certain predicate, run a decryption and feed them into a subroutine.

Now release a bunch of png, jpg, and mp4 media on the internet with the low order bits set to match.

Re: Freedom and security issues on x86 platforms

#125

Post by nickpsecurity » Mon, Apr 04, 2016, 6:28 PM UTC

kristoffer wrote: post #117

nickpsecurity wrote: post #106

Earlier quoted context omitted.

"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU." There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in i…

I agree that LEON is overlooked in the MCU market. Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!

That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics.

Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling.

Always looking for HW people's review on these things. What you think?

Re: Freedom and security issues on x86 platforms

#126

Post by SXX » Mon, Apr 04, 2016, 6:29 PM UTC

edwintorok wrote: post #91

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.

It doesn't include the CPU itself?

According to the side it's include "entry-level 8-core 130W POWER8 CPU". It's still damn expensive.

Re: Freedom and security issues on x86 platforms

#127

Post by wtallis » Mon, Apr 04, 2016, 6:30 PM UTC

ricardobeat wrote: post #97

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.

Judging by the specs on their current lineup, it looks like Apple already gave up on performance anyway.

Aside from the stale Mac Pro, which current Macs do you think are indicative of Apple giving up on performance?

Re: Freedom and security issues on x86 platforms

#128

Post by CyberDildonics » Mon, Apr 04, 2016, 6:31 PM UTC

nickpsecurity wrote: post #111

kristoffer wrote: post #84

Earlier quoted context omitted.

Then you are missing the point he is making. LEON is a GPL implementation of SPARCv8 which you can download and use in an FPGA, tape out your own ASIC or buy one of the existing SoCs built with it (might not be that easy...). In other words, more open than the alternatives listed.

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.

Re: Freedom and security issues on x86 platforms

#129

Post by petra » Mon, Apr 04, 2016, 6:31 PM UTC

nickpsecurity wrote: post #106

kristoffer wrote: post #71

Earlier quoted context omitted.

I thought it was pretty bad as well ... But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU. I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC. I say this…

"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU." There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in i…

Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc.

Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?

Re: Freedom and security issues on x86 platforms

#130

Post by nickpsecurity » Mon, Apr 04, 2016, 6:33 PM UTC

mtgx wrote: post #123

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…

Because Oracle tends to be hostile towards anything open source? With such an attitude, why ever bother supporting their technologies?

SPARC is owned by SPARC International, a non-profit. Its specs and everything are open:

http://sparc.org/technical-documents/

One embedded implementation with a ton of supporting I.P. is GPL'd, FPGA-proven, ASIC-proven, and rad-hard in some verisons:

http://www.gaisler.com/index.php/downloads/leongrlib?task=vi...

And then there's Oracle, their badass chips, and their evil ass lawyers. We can stay away from all that. SPARC is better and safer than Oracle but very importantly SPARC != Oracle.