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

Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

www2.eecs.berkeley.edu

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#41

Post by wk_end »

LegionMammal978 wrote: post #38
bdowling wrote: post #26

Would copying an instruction set and ABI to make an interoperable processor and system be fair use in light of Google v. Oracle (2021) [0][1]? [0] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf [1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_... . Edit: Changed phrasing of question. Also, to be clear I think the answer is probably yes.

Google v. Oracle was not about interoperability: as the decision presents it, Google copied the APIs for Android specifically because they didn't want false interoperability with desktop Java. Instead, the court found that the use was transformative (bringing Java to a new, distinct platform), insubstantial (the declarations being non-central to the overall implementation), and with little market effect (Sun/Oracle h…

Just to prod at this a little bit:

The vast majority of ARM licensees aren't doing anything transformative, that's for sure. But would something like the M1 - bringing ARM to the desktop when all past attempts have failed - have been considered transformative?

The question of what constitutes a "large market effect" is a big one...if I make a chip to serve as a controller in my brand of hard drives, is that a large market effect? ARM loses out on a few pennies per drive or something.

And I'd dispute the characterization of micro-architecture design as "insubstantial". Not accusing you of this, but this really has been the most frustrating thing about RISC-V - software engineers who don't know anything about CPU design comparing it to Linux when really it's more like POSIX or, yes, the Java class library. The insides of microcomputer CPUs haven't really resembled their interfaces very much since the early 80s - even the 68000, a consumer-grade CPU that's 45 years old (!) was designed so that the microcode engine that drove it could be used to implement an array of instruction sets. Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#42

Post by lambdaone »

cesarb wrote: post #39
abdullahkhalids wrote: post #24

Earlier quoted context omitted.

I imagine, with knowledge of the ISA, can help one can define a verification algorithm, in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor.

> in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor. There are 2^64 possible values for a single register . It's not possible to probe all possible combinations of values for the over 60 user-accessible registers, to find the single combination which, when calling a specific one of the more than 2^30 possible instructions, silently flips a secret "disable all permissions…

It is, however, in principle possible to prove that a processor implements the spec and only the spec; seach for "formal verification risc v" to find out more.

Of course if someone can sneak a backdoor into the spec, all bets are off.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#43

Post by LegionMammal978 »

wk_end wrote: post #41
LegionMammal978 wrote: post #38

Earlier quoted context omitted.

Google v. Oracle was not about interoperability: as the decision presents it, Google copied the APIs for Android specifically because they didn't want false interoperability with desktop Java. Instead, the court found that the use was transformative (bringing Java to a new, distinct platform), insubstantial (the declarations being non-central to the overall implementation), and with little market effect (Sun/Oracle h…

Just to prod at this a little bit: The vast majority of ARM licensees aren't doing anything transformative, that's for sure. But would something like the M1 - bringing ARM to the desktop when all past attempts have failed - have been considered transformative? The question of what constitutes a "large market effect" is a big one...if I make a chip to serve as a controller in my brand of hard drives, is that a large m…

> Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.

If anything, I'd say that it's precisely because of this independence that an ISA can be seen as a separate work from any of its existing implementations. So what I'm trying to get at, is that if an ISA is copyrightable at all, in whole or in part, then any complete re-implementation will be copying most of the ISA's own substance, regardless of differing internal details. (Where by 'ISA' I specifically mean the external interface that software can access.)

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#44

Post by topspin »

bee_rider wrote: post #21
ysofunny wrote: post #19

free instruction sets: this "langauge" should be spoken by all! a public ISA private instruction sets: this is a private matter, restricted to a need-to-know basis. private ISA the main difference is the private one can sneak in magic backdoor instructions, lost in the vastness of a 2^bit_depth space which is better for a languge? to be spoken used and known by many? or to be unkown and obscure? the funky business is…

It seems like, if someone has the ability to slip an evil instruction into a proprietary ISA, they could also slip an evil instruction into their implementation of an open ISA and just not document it. RISC-V leaves room for proprietary extensions, right? Why not use that? I think RISC-V is very cool and the future, but I don’t really see how it helps here.

> I don’t really see how it helps here.

It doesn't help at all. That issue is entirely orthogonal to "open vs proprietary" ISA. The ways a compromise can be implemented are effectively infinite and need not be anything as obvious as an undocumented instruction. A predictor, for instance, can detect a specific sequence of instructions and fill the pipeline with whatever it wants: no undocumented instructions involved at all.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#45

Post by hmry »

lambdaone wrote: post #42
cesarb wrote: post #39

Earlier quoted context omitted.

> in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor. There are 2^64 possible values for a single register . It's not possible to probe all possible combinations of values for the over 60 user-accessible registers, to find the single combination which, when calling a specific one of the more than 2^30 possible instructions, silently flips a secret "disable all permissions…

It is, however, in principle possible to prove that a processor implements the spec and only the spec; seach for "formal verification risc v" to find out more. Of course if someone can sneak a backdoor into the spec, all bets are off.

You would also need to prove that the physical processor in your hands was actually manufactured according to the verified design, and not a slightly different design with a back door added. Which is infeasible for all processors manufactured in the last 30 years.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#47

Post by Vt71fcAqt7 »

leucineleprec0n wrote: post #22

Instruction set baselines should ideally be well-regulated open standards. They should also be good, and not moronic academic projects running of 32B opcode space because of religious dedication to silly extensions and the uniformity of an ISA for saving pennies on microcontrollers to high performance CPUs. RISC-V in principle is a great idea. Hopefully we’ll get something that’s at the caliber of a well-oiled machin…

I don't see why "moronic" was needed there. Also Risc-V has profiles that group multiple extensions together for specific use cases. For example RVA23[0] which requires 64 bit and vector extension among many others. Operating systems like android can (and most likely will) specify that they only support certain profiles.[1] Lastly, ARM is also fragmented between Armv8 and Armv7 which android developers are still supporting.

>RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation.

Do you have any evidence to support this? Seems like RVA23 will be the first majorly supported extension. All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.

[0] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...

[1] https://opensource.googleblog.com/2023/10/android-and-risc-v... (note: the blog mentions RVA22 but this has most likely been switched to RVA23 before full Risc-V support lands in Android).

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#48

Post by calf »

fidotron wrote: post #18
crote wrote: post #16

Earlier quoted context omitted.

So rather than getting stuck in potential future tarpit of AWS or GCS or Azure, or probably a dozen other companies, we should voluntarily put ourselves into the IP tarpit developed by ARM? How exactly is that a win? Over the last two decades ARM has developed a stranglehold on the non-x86 world, and they have already considered abusing this position to increase their profit margin[0]. As a chipmaker you're essential…

Arm didn't develop the IP tarpit, they're one of the few players that learned how to operate in it. The SuperH example is relevant because what Arm did was "that's neat, let's license it" for some of the Hitachi innovations, and then licensed it to other people too. This is a positive development, and how trade and innovation has worked through the most successful periods in history. There is a respect in which they…

ARM exists because of the tarpit's ecology. The ecology permits an IP monopolizer to become entrenched in it and to suppress other players.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#49

Post by abdullahkhalids »

cesarb wrote: post #39
abdullahkhalids wrote: post #24

Earlier quoted context omitted.

I imagine, with knowledge of the ISA, can help one can define a verification algorithm, in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor.

> in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor. There are 2^64 possible values for a single register . It's not possible to probe all possible combinations of values for the over 60 user-accessible registers, to find the single combination which, when calling a specific one of the more than 2^30 possible instructions, silently flips a secret "disable all permissions…

I did a 5 minutes search. There seems to be a lot of work in detecting hardware trojans. Sec 3.12 here [1] discusses some of these approaches. One line is one of the things I was thinking of when I commented. Basically, there are tradeoffs of how logically hidden the trojan is against how physically exposed it is.

> Using this defense method, any Trojan that can analyze the entire configurable structure must use complicated logic functions and take up a large silicon area, which greatly increases the possibility of being detected by security tools.

There are live methods of detecting trojans as well, where you have an additional chip checking what the CPU is doing at all times [2].

One of the main thing I have learned in my life is to not underestimate the ingenuity of cryptographers.

[1] https://arxiv.org/pdf/2107.04175

[2] https://re.public.polimi.it/bitstream/11311/1204477/1/DFTS_2...

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#50

Post by calf »

CalChris wrote: post #7

There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...

Here's the 2014 conference debate between industry and academics that probably precipitated the exchange:

"Proprietary versus Open Instruction Sets" https://www.ele.uri.edu/faculty/sendag/papers/micro2016_2.pd... (pdf)

--4th Workshop on Computer Architecture Research Directions, https://ieeexplore.ieee.org/document/7542457 Mark D. Hill; Dave Christie; David Patterson; Joshua J. Yi; Derek Chiou; Resit Sendag

And 2015 full video recording of the debate between Patterson and Christie: "CARD 2015 Mini-Panel #1: Open Source versus Proprietary ISAs" https://www.youtube.com/watch?v=novCbl4Wq3I

Post reply on HN