[HN Gopher] Mojo-V: Secret Computation for RISC-V
___________________________________________________________________
Mojo-V: Secret Computation for RISC-V
Author : fork-bomber
Score : 60 points
Date : 2025-11-12 11:57 UTC (7 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pjmlp wrote:
| And the relationship to Mojo programming language is?
| shakna wrote:
| This could be:
|
| Great for security - Being able to safely compute secrets is a
| very difficult problem.
|
| Fucking awful for security - More OEM secret controls and
| "analytics" that devolve into backdoors after someone yet again
| post keys online.
| Manfred wrote:
| The platform owner can manage keys and data contracts in the
| processor, that should enable them to rotate secrets
| constantly.
|
| In other hardware there is an OEM secret because the
| manufacturer is trying to keep users out of "their hardware",
| in this case we're trying to keep everyone except the data
| owner out.
| snvzz wrote:
| RISC-V is inevitable.
| LarsDu88 wrote:
| Was it really wise to name this Mojo when Chris Lattner, former
| Head 9f Engineering at SiFive also called his well funded
| programming language Mojo?
| left-struck wrote:
| It's called Mojo-V not just Mojo
| craftkiller wrote:
| So close to Mojave, I feel like they could have done
| something with that.
| NooneAtAll3 wrote:
| was it really wise to name both Mojo when Mr.Evil stole it from
| Austin Powers back in 1999?
| hyperhello wrote:
| Doctor Evil. He didn't spend six years in evil medical school
| to be called Mister, thank you very much.
| Manfred wrote:
| After skimming through the documentation this seems like a nice
| solution, but I'm not sure if this is a problem we want to solve.
|
| Consumers are finding out the issue with cloud computing when
| their heating system can't turn on because Cloudflare is down. A
| cheaper and more reliable solution is still on-premises
| computing.
|
| Large social network and content platforms don't have any
| incentive to keep your data safe because they want to monitor and
| own everything.
|
| Maybe this is for something like a government running a public
| service?
| throawayonthe wrote:
| i want good confidential compute for cases where e2ee is
| impractical, like an email server or immich with server-side
| ml/processing etc
| Manfred wrote:
| Who are you protecting data access from in those cases? My
| suggestion was that it's probably more practical to run those
| kinds of solutions on a hardware stack you trust; in our
| basement or in a small box on the wall in your living room.
|
| Besides, the specific extension we're talking about protect
| registers and computation and not shared memory.
| tonetegeatinst wrote:
| Issue is, unless you can be 100% sure you hardware has not
| been built with a vulnerability or backdoor, or subject to
| an evil maid attack....then you can't be sure its
| trustworthy.
| nl wrote:
| > I'm not sure if this is a problem we want to solve
|
| Who is this _we_ you speak of?
|
| I for one much prefer my cloud services and would love TEE I
| can control.
|
| > A cheaper and more reliable solution is still on-premises
| computing.
|
| I assure you that my use of Cloudflare services ($0 in nearly
| 10 years) is much more reliable and much cheaper than hardware
| I run.
| Manfred wrote:
| I was genuinely asking, what cloud service do you use where
| trusted computing is essential for the core functionality of
| that service? What elements of the computational process do
| you not trust those services to perform for you?
|
| My point about Cloudflare was more about them taking down
| essential services that could run just as well on-premises
| like a heating controller.
| tromp wrote:
| This should not (so much) be compared with Fully Homomorphic
| Encryption (FHE) but with a Trusted Execution Environment (TEE).
| It is a very elegant and minimal way to implement TEEs, but
| suffers from the same drawbacks: a data owner has to trust the
| service provider to publish the public keys of actual properly
| constructed Mojo-V hardware rather than arbitrary public keys or
| public keys of maliciously constructed Mojo-V hardware.
|
| [1] https://en.wikipedia.org/wiki/Trusted_execution_environment
| api wrote:
| You could have the keys signed by a chip maker, which cuts the
| hosting provider out and reduces the trust surface to the
| manufacturer only. Unless your adversary is someone
| sophisticated enough to do surgery on chips.
|
| It's still not FHE but it's about as good as you can get
| otherwise.
| childintime wrote:
| Couldn't the keys be loaded once, in private write-only flash
| memory, by the user of the chip?
| tromp wrote:
| The intended use case is for remote execution where the
| user (data owner) pays a service provider to run services
| on their hardware. It could still work if the user somehow
| prepares the chip herself and ships it to the service
| provider to be used on their future data, but most users
| would not want to bother with that first step.
| goku12 wrote:
| > Unless your adversary is someone sophisticated enough to do
| surgery on chips.
|
| Since the threat assessment is important for deciding the
| strength of countermeasures, let me just add that this isn't
| as uncommon as you may believe. A company that I worked for
| had a decent capability to do this, and they were using it
| just to investigate the failures of electronic subsystems in
| their projects. Imagine what a more dedicated entity could
| achieve. This is why standards like FIPS 140-2/3 level-3/4
| are very relevant in a significant number of corporate cases.
|
| Talking about chip surgeries, I wish our distinguished expert
| Ken Shirrif could throw some light on the process. His work
| on legacy chips is one of the most noteworthy in the field.
| technocrat8080 wrote:
| To be clear, it's not a TEE replacement but does address one of
| the most common use cases of TEEs
___________________________________________________________________
(page generated 2025-11-19 23:01 UTC)