VisionFive 2 rework loading the main stage via DTFS #720
Conversation
|
this comes after #716 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #720 +/- ##
=====================================
Coverage 0.20% 0.20%
=====================================
Files 23 23
Lines 962 962
=====================================
Hits 2 2
Misses 960 960 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Daniel Maslowski <info@orangecms.org>
Signed-off-by: Daniel Maslowski <info@orangecms.org>
orangecms
force-pushed
the
vf2-load-main-rework
branch
from
144061e
to
820b6b2
Compare
| let psize = v.unwrap_or(0); | ||
| if !found { | ||
| if DEBUG { | ||
| println!("No main stage yet, inc offset by 0x{psize:x}"); |
There was a problem hiding this comment.
| println!("No main stage yet, inc offset by 0x{psize:x}"); | |
| println!("No main stage yet, inc offset by {psize:#x}"); |
| } | ||
| (SRAM0_BASE, SRAM0_SIZE) // occupied space | ||
| }; | ||
| let slice = unsafe { core::slice::from_raw_parts(transmute(base), size) }; |
There was a problem hiding this comment.
Maybe add a SAFETY comment here since we are loading executable memory from FLASH/RAM?
|
|
||
| let hart_id = mhartid::read(); | ||
| // U-Boot proper | ||
| fn exec_payload(addr: usize) { | ||
| unsafe { |
There was a problem hiding this comment.
Similar to above, maybe add a SAFETY comment about transmuteing executable memory into an EntryPoint?
Since we're not doing a signed/secure boot setup, we're assuming the memory is valid, but I think that should at least be mentioned.
There was a problem hiding this comment.
The secure boot topic is a very good point.
If we reverse engineer the previous vendor tool that apparently had some signing capabilities and we figure out how to burn keys into the SoC, then we could offer secure boot; though that is somewhat outside the current scope. :D It would be cool to have though and I'm sure we can do it!
We do jump to code under our own control here, since you would build oreboot fully, and so it is no more or less secure than the rest of the code.
The point on safety - same with the above - is indeed something to take care of. Let's add those notes.
There was a problem hiding this comment.
Re secure boot; see starfive-tech/Tools#1 where I reversed said tool for the simpler header generation that we also have in oreboot
There was a problem hiding this comment.
It would be cool to have though and I'm sure we can do it!
I think we could just choose an unused offset in the QSPI flash, write a public key there, and load it into memory on boot. Not perfect, since an attacker with write access to the QSPI could rewrite with their own key, but they could also do whatever they want at that point.
Then in the bt0/SPL (or some earlier stage), we load the key + signature, and verify whatever signed pieces of firmware and/or kernel we want.
No description provided.