TR Forums

https://www.wdc.com/about-wd/newsroom/p ... ments.html

While the press release is (as with most press releases) rather long on buzzwords/bullsh*t and short on actual content, one takeaway seems to be that WD intends to switch to RISC-V cores for the embedded processors in their HDDs.

If they follow through on that plan, it'll be great for RISC-V (and probably not so great for ARM).

So we are finally seeing RISC-V processors in the wild then?

just brew it! wrote:

If they follow through on that plan, it'll be great for RISC-V (and probably not so great for ARM).

Somehow I think ARM will be ok.

whm1974 wrote:

So we are finally seeing RISC-V processors in the wild then

...More like in the pen (embedded).

UberGerbil wrote:

just brew it! wrote:

If they follow through on that plan, it'll be great for RISC-V (and probably not so great for ARM).

Somehow I think ARM will be ok.

For now...

UberGerbil wrote:

just brew it! wrote:

If they follow through on that plan, it'll be great for RISC-V (and probably not so great for ARM).

Somehow I think ARM will be ok.

Oh, I'm sure ARM will still be huge in the mobile device market; it's too entrenched there. But if devices like HDD logic boards shift to RISC-V that'll be a significant drop in total volume of ARM cores shipped. That'll put a dent in their royalty revenue stream.

JBI wrote:

Oh, I'm sure ARM will still be huge in the mobile device market; it's too entrenched there. But if devices like HDD logic boards shift to RISC-V that'll be a significant drop in total volume of ARM cores shipped. That'll put a dent in their royalty revenue stream.

Yeah, it's a pretty important product win, I'd definitely agree.

Somewhat surprised, actually.

Glorious wrote:

JBI wrote:

Oh, I'm sure ARM will still be huge in the mobile device market; it's too entrenched there. But if devices like HDD logic boards shift to RISC-V that'll be a significant drop in total volume of ARM cores shipped. That'll put a dent in their royalty revenue stream.

Yeah, it's a pretty important product win, I'd definitely agree.

Somewhat surprised, actually.

I don't see why. After all the ISA was designed to scale from micro-controllers to Supercomputers.

whm1974 wrote:

I don't see why. After all the ISA was designed to scale from micro-controllers to Supercomputers.

There's nothing special about an ISA that makes it particularly good (or bad) for supercomputers. It's mostly about how you implement the communication fabric that ties everything together, and (these days) how many GPUs you can cram into the system to handle the heavy duty number crunching.

The newer ARM-based server chips could be used in supercomputers too, with a little tweaking.

just brew it! wrote:

whm1974 wrote:

I don't see why. After all the ISA was designed to scale from micro-controllers to Supercomputers.

...and (these days) how many GPUs you can cram into the system to handle the heavy duty number crunching.

This is only true for "small" problems - anything that sweeps DRAM ends up almost entirely bottlenecked by memory bandwidth and, in the case of GPUs, PCIe bandwidth.

Waco wrote:

just brew it! wrote:

whm1974 wrote:

I don't see why. After all the ISA was designed to scale from micro-controllers to Supercomputers.

...and (these days) how many GPUs you can cram into the system to handle the heavy duty number crunching.

This is only true for "small" problems

Or large problems which can easily be chunked up into smaller problems which don't need a lot of data from the other chunks.

In any event, the ISA isn't a relevant factor.

Doesn't this also provide a boost for security? Viruses and spyware (particularly state sponsored kit if I remember right) still like to install onto hard drives and run from within controller board itself, so changing to RISC-V would reduce what code could execute on the controller boards, right?

Kougar wrote:

Doesn't this also provide a boost for security? Viruses and spyware (particularly state sponsored kit if I remember right) still like to install onto hard drives and run from within controller board itself, so changing to RISC-V would reduce what code could execute on the controller boards, right?

While theoretically possible, I am not aware of anyone detecting exploits "in the wild" that run from the HDD's controller board. The capabilities of such an exploit would be somewhat limited -- the HDD does not have access to any external communication interfaces, so it can't "phone home" without additional cooperating malware elsewhere on the system. I suppose you might be able to use it to inject a rootkit at boot time, but this seems like an awful lot of effort to implement a fragile (very specific to particular HDD models) method of doing something which could be accomplished more reliably by other means.

The NSA was/is using it, but security researchers have also been able to do it years ago. https://motherboard.vice.com/en_us/arti ... a-year-ago When most of the world's HDDs come from two vendors the NSA doesn't need to design that many HDD firmware variations.The controller board is a self-contained computer, would be immune to OS level scanning, provide a reinfection vector, and would have free reign to record additional data on the drive spare area until the main OS was re-compromised and the data sent/pulled.

Granted it wouldn't stop the NSA, if the NSA still wanted to do it they would, but RISC adding more deterrents for hackers or anyone else from it would be a nice bonus.

OK, I guess I missed that.

I still don't think RISC-V will make much of a difference in this area though. Adapting the exploit to RISC-V will be child's play for NSA-level TLAs, and it only takes one hacker to leak an exploit toolkit to the black hat community and we're back in the same boat we're in now with ARM-based controllers.

I really hope HDD makers implement cryptographic signing of firmware updates, and that the signature is checked by the drive itself (not the update tool). At least this way an exploit would require a compromised signing key, or physical access to the drive's PCB (firmware flash via internal JTAG/debug port to bypass the cryptographic check).

Nvidia is using RISC-V for their next generation microcontroller as well. (https://riscv.org/wp-content/uploads/20 ... ermans.pdf)

just brew it! wrote:

Waco wrote:

just brew it! wrote:

...and (these days) how many GPUs you can cram into the system to handle the heavy duty number crunching.

This is only true for "small" problems

Or large problems which can easily be chunked up into smaller problems which don't need a lot of data from the other chunks.

GPUs are still nowhere near the memory density of DRAM on a node, though.