5 ms·

How would that change anything?

by q3k 6y ago

sliken 6y ago
By nature RISC-v machines will tend to be more open, have an open bootloader, and be friendly to running an open OS. Much less likely to block installing Linux, like Apple has done. Much less likely to block running linux, like on the Microsoft Surface. Sure some Apple like company could make a fork of RISC-v and then lock down the environment, spy on a user's network traffic, what binaries they run, etc.
- tpush 6y ago
  There is exactly nothing about RISC-V that makes things built on it more open. RISC-V itself is an Open Source ISA, but that has nothing to do with having an open boot loader or whatever.
- q3k 6y ago
  How does RISC-V imply an open bootloader or open hardware? It's just an ISA, and there is currently no RISC-V extension that I'm aware of that goes into details like platform boot or platform boot security. In fact, Si-Five have implemented their own from scratch [1], because there was no existing RISC-V blessed way of doing these things. And their implementation is open, but nothing prevents anyone else from implementing a closed, fused implementation. Or taking the Si-Five implementation and using it to prohibit any modifications by end-users, like vendors already do with U-Boot. [2] I already have in my hands a RISC-V microcontroller that can be locked down by the firmware developers to prohibit me from reading it out or modifying it [3]. And finally - even running your code on a RISC-V core is not enough to actually make a platform usable. You need documentation for every single peripheral around the core (and/or core complex). And even when you have that, implementation is still a lot of work. See: how much effort it was to do a decent Linux port onto the Tegra X1 on the Nintendo Switch, which is extremely thoroughly and publicly documented (in comparison to other platforms in this class, at least). And the only blocker there was secure/fused boot. Which again, RISC-V will not prevent. [1] - https://riscv.org/wp-content/uploads/2019/12/12.10-14.20-SiFive-Shield-RISC-V-Summit-FINAL3.pdf https://riscv.org/wp-content/uploads/2019/12/12.10-14.20-SiF... [2] - https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boo... [3] - http://www.gd32mcu.com/data/documents/shujushouce/GD32VF103_User_Manual_EN_V1.2.pdf http://www.gd32mcu.com/data/documents/shujushouce/GD32VF103_... ; C-f security

How would that change anything?

by q3k 6y ago

How would that change anything?

By nature RISC-v machines will tend to be more open, have an open bootloader, and be friendly to running an open OS. Much less likely to block installing Linux, like Apple has done. Much less likely to block running linux, like on the Microsoft Surface. Sure some Apple like company could make a fork of RISC-v and then lock down the environment, spy on a user's network traffic, what binaries they run, etc.

tpush 6y ago
There is exactly nothing about RISC-V that makes things built on it more open. RISC-V itself is an Open Source ISA, but that has nothing to do with having an open boot loader or whatever.
q3k 6y ago
How does RISC-V imply an open bootloader or open hardware? It's just an ISA, and there is currently no RISC-V extension that I'm aware of that goes into details like platform boot or platform boot security. In fact, Si-Five have implemented their own from scratch [1], because there was no existing RISC-V blessed way of doing these things. And their implementation is open, but nothing prevents anyone else from implementing a closed, fused implementation. Or taking the Si-Five implementation and using it to prohibit any modifications by end-users, like vendors already do with U-Boot. [2] I already have in my hands a RISC-V microcontroller that can be locked down by the firmware developers to prohibit me from reading it out or modifying it [3]. And finally - even running your code on a RISC-V core is not enough to actually make a platform usable. You need documentation for every single peripheral around the core (and/or core complex). And even when you have that, implementation is still a lot of work. See: how much effort it was to do a decent Linux port onto the Tegra X1 on the Nintendo Switch, which is extremely thoroughly and publicly documented (in comparison to other platforms in this class, at least). And the only blocker there was secure/fused boot. Which again, RISC-V will not prevent. [1] - https://riscv.org/wp-content/uploads/2019/12/12.10-14.20-SiFive-Shield-RISC-V-Summit-FINAL3.pdf https://riscv.org/wp-content/uploads/2019/12/12.10-14.20-SiF... [2] - https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boo... [3] - http://www.gd32mcu.com/data/documents/shujushouce/GD32VF103_User_Manual_EN_V1.2.pdf http://www.gd32mcu.com/data/documents/shujushouce/GD32VF103_... ; C-f security