I call shenanigans, this is a fake page. First off the page isn't coming from arm's own domain yet it appears to mimic the look and feel of the arm site. No cookie acceptance policy and the missing links from the bottom of the page are further proof.
ARM: “RISC-V Architecture: Understand the Facts”
31–40 of 123 posts
Re: ARM: “RISC-V Architecture: Understand the Facts”
#32I call shenanigans, this is a fake page. First off the page isn't coming from arm's own domain yet it appears to mimic the look and feel of the arm site. No cookie acceptance policy and the missing links from the bottom of the page are further proof.
This actually looks like a smear campaign against ARM.
Re: ARM: “RISC-V Architecture: Understand the Facts”
#33Some of the "facts" here are pretty weak. The "years of security expertise" is not really a feature I'd be proud of given the recent processor-level vulnerabilities that in fact, paint a very different picture about how traditional processor vendors treat security. Even if there is some validity here, this is in surprisingly poor taste. I've known people who have worked for ARM. I wonder what they think about this.
How would an open source processor be better from a security perspective? I might still be a little shell shocked from my attempts to setup a MythTV Box 10 years ago but this is what's running through my head: "Did you RTFM?" "Debain CPU doesn't have that issue." "Just disable the ALUs in firmware, they're not necessary in modern processors anyways." "That's been patched, just download processor v2.3.4.432 and send i…
Re: ARM: “RISC-V Architecture: Understand the Facts”
#34Re: ARM: “RISC-V Architecture: Understand the Facts”
#35Earlier quoted context omitted.
How would an open source processor be better from a security perspective? I might still be a little shell shocked from my attempts to setup a MythTV Box 10 years ago but this is what's running through my head: "Did you RTFM?" "Debain CPU doesn't have that issue." "Just disable the ALUs in firmware, they're not necessary in modern processors anyways." "That's been patched, just download processor v2.3.4.432 and send i…
All of that sounds better than: "Oh, our new processors don't have that issue. Trust us, pay me. Oh, you just bought one? Too bad."
Re: ARM: “RISC-V Architecture: Understand the Facts”
#36Some of the "facts" here are pretty weak. The "years of security expertise" is not really a feature I'd be proud of given the recent processor-level vulnerabilities that in fact, paint a very different picture about how traditional processor vendors treat security. Even if there is some validity here, this is in surprisingly poor taste. I've known people who have worked for ARM. I wonder what they think about this.
Re: ARM: “RISC-V Architecture: Understand the Facts”
#37I call shenanigans, this is a fake page. First off the page isn't coming from arm's own domain yet it appears to mimic the look and feel of the arm site. No cookie acceptance policy and the missing links from the bottom of the page are further proof.
Re: ARM: “RISC-V Architecture: Understand the Facts”
#38Re: ARM: “RISC-V Architecture: Understand the Facts”
#39Earlier quoted context omitted.
How would an open source processor be better from a security perspective? I might still be a little shell shocked from my attempts to setup a MythTV Box 10 years ago but this is what's running through my head: "Did you RTFM?" "Debain CPU doesn't have that issue." "Just disable the ALUs in firmware, they're not necessary in modern processors anyways." "That's been patched, just download processor v2.3.4.432 and send i…
Some open source projects are different. A lot of them do not cater to end users directly. But if you want to talk about open source security, take a look at how OpenBSD handles issues; they definitely aren't messing around.
If everyone is running the same CPU design but sourced from different manufacturers who had them spun up at different fabs, how would that affect support? Today we have one or two device manufacturers we rely on for support and answers about if security fixes can be done in firmware vs requiring a hardware fix. We can pull the CPU ID of our system and then check with AMD or Intel for an authoritative answer. What does that look like when anyone can manufacture a chip?
Will there still end up being one or two predominant CPU manufactures for desktop/mobile/server CPUs to simplify support? Are we going to have to rely on OEMs to support the CPUs they put in their machines?
I'm fearful we might end up in a situation similar or worse to what we have with Android where smartphones are shipped in their final state and never receive anything beyond failure support from the OEM/ODM.
Re: ARM: “RISC-V Architecture: Understand the Facts”
#40Some of the "facts" here are pretty weak. The "years of security expertise" is not really a feature I'd be proud of given the recent processor-level vulnerabilities that in fact, paint a very different picture about how traditional processor vendors treat security. Even if there is some validity here, this is in surprisingly poor taste. I've known people who have worked for ARM. I wonder what they think about this.
How would an open source processor be better from a security perspective? I might still be a little shell shocked from my attempts to setup a MythTV Box 10 years ago but this is what's running through my head: "Did you RTFM?" "Debain CPU doesn't have that issue." "Just disable the ALUs in firmware, they're not necessary in modern processors anyways." "That's been patched, just download processor v2.3.4.432 and send i…
Notwithstanding your terrible MythTV experience, there's seveal companies offering commercial support for Linux today, and a lot of effort has been put into making it as secure as the Windows equivalent. I suspect the same could happen with RISC-V.