HiFive1 RevB Support?

[Daniel Hayes]

Any plans on having board support for the HiFive1 RevB?  I'm working on my senior design project on IoT security using RISC-V and Rust on the HiFive1 RevB board.  I saw Tock on GitHub and it seems kind of interesting.  Thanks!

[Amit Levy]

Hi Daniel,

@Brad is more authoritative to speak on this, but absolutely. In particular, I believe the RevB has a chip with memory protection, making it actually amenable to isolating processes (whereas the RevA does not). We've been mostly using the RevA for doing RISC-V development without a board since there is support for it in QEMU, and most of the RISC-V development so far has gone into OpenTitan and the Arty E21, both on FPGAs since real hardware isn't available yet.

If you're interested in working on the HiFive port for a senior design project, I strongly encourage you to do so and we'll help however we can!

-Amit

On 2/19/20 9:13 AM, Daniel Hayes wrote:

Any plans on having board support for the HiFive1 RevB?  I'm working on my senior design project on IoT security using RISC-V and Rust on the HiFive1 RevB board.  I saw Tock on GitHub and it seems kind of interesting.  Thanks!

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/fd924140-4185-4765-a445-0adc6b39bf5f%40googlegroups.com.

[Daniel Hayes]

Thanks for quick reply Amit, 

I'm not a developer necessarily, I'm studying electrical engineering, but I don't mind trying to do the port as Tock seems to align very well with my original intentions.  I have a Rev B board in my possession right now and I have another one on order.  Rev B uses the FE310-G002 chip and according to the manual, it has 8 PMP registers (physical memory protection) with user and machine modes too.  Note that SparkFun has a Red-V board that has the FE310-G002 chip so it has same memory protections as the RevB board and is available for purchase ($40).  That would be another board to look into.  Let me know where I should start with the porting process, and I'll see if I can make it happen.  Appreciate it,

               Daniel 

   

[Daniel Hayes]

Here is the link for the FE310-G002 RISC-V chip 

[Brad Campbell]

Having support for rev B is definitely a goal. In fact it has long been an unchecked box on the tracking issue: https://github.com/tock/tock/issues/1135.

Also, thanks for pointing out the sparkfun board, that is an interesting development. I think the hifive b is still more compelling, however, as it allows for wireless connectivity.

- Brad

--

You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/5a3fab52-27fe-4b3f-bdc2-4450dd6634e0%40googlegroups.com.

[Daniel Hayes]

I agree on the HiFive1RevB board being more interesting with the on-board esp32.  I've found the GitHub page on porting boards.  I don't know how much help I could be, but I'll do anything I can to help move this along.  Appreciate it!

To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.

[Daniel Hayes]

A while back, I found this Maixduino board from SeeedStudio.  It uses their Kendryte 210 chip that has dual-core 64 bit RISC-V IMAC.  They have a lot of support for AI type stuff and it has an onboard esp32 module.  I have no idea if it has PMP or U-mode, but it's cheap!  I also have one of these on hand, haven't played with it yet though.  Just another board I thought you guys might be interested in at some point.    

[Daniel Hayes]

I've decided to try and port Tock to the HiFive1 RevB.  I know that the RevA did not have the memory protection features.  With that being said, would any of the RevA crates translate to the RevB like the chip and arch crates?  It seems that I should start with the Hifive1 arch crate and make adjustments for configuring the memory protection.  Any suggestions or comments on starting?  Thanks,

Daniel  

[Guillaume Endignoux]

On Sat, Feb 22, 2020 at 8:05 PM Daniel Hayes <dhay...@uncc.edu> wrote:

I've decided to try and port Tock to the HiFive1 RevB.  I know that the RevA did not have the memory protection features.  With that being said, would any of the RevA crates translate to the RevB like the chip and arch crates?  It seems that I should start with the Hifive1 arch crate and make adjustments for configuring the memory protection.  Any suggestions or comments on starting?  Thanks,

Daniel

I'm not sure about HiFive, but in the case of Nordic chips, there are multiple crates that depend on each other and re-export relevant part to avoid code duplication (nrf5x, nrf52, nrf52832, nrf52840).

If that helps, you can get inspiration from https://github.com/tock/tock/pull/1422 and https://github.com/tock/tock/pull/1505.

In terms of boards, there's also code sharing with the nrf52dk_base crate.

It has overall worked quite well for Nordic boards, so there could definitely be some streamlining of this process for other chips/boards that share a common structure.

Guillaume

On Thursday, February 20, 2020 at 11:01:20 AM UTC-5, Daniel Hayes wrote:

A while back, I found this Maixduino board from SeeedStudio.  It uses their Kendryte 210 chip that has dual-core 64 bit RISC-V IMAC.  They have a lot of support for AI type stuff and it has an onboard esp32 module.  I have no idea if it has PMP or U-mode, but it's cheap!  I also have one of these on hand, haven't played with it yet though.  Just another board I thought you guys might be interested in at some point.    

On Wednesday, February 19, 2020 at 2:36:34 PM UTC-5, Daniel Hayes wrote:

I agree on the HiFive1RevB board being more interesting with the on-board esp32.  I've found the GitHub page on porting boards.  I don't know how much help I could be, but I'll do anything I can to help move this along.  Appreciate it!

On Wednesday, February 19, 2020 at 2:24:04 PM UTC-5, Brad Campbell wrote:

Having support for rev B is definitely a goal. In fact it has long been an unchecked box on the tracking issue: https://github.com/tock/tock/issues/1135.

Also, thanks for pointing out the sparkfun board, that is an interesting development. I think the hifive b is still more compelling, however, as it allows for wireless connectivity.

- Brad

On Wed, Feb 19, 2020 at 1:44 PM Daniel Hayes <dhay...@uncc.edu> wrote:

Here is the link for the FE310-G002 RISC-V chip 

On Wednesday, February 19, 2020 at 11:23:14 AM UTC-5, Daniel Hayes wrote:

Thanks for quick reply Amit, 

I'm not a developer necessarily, I'm studying electrical engineering, but I don't mind trying to do the port as Tock seems to align very well with my original intentions.  I have a Rev B board in my possession right now and I have another one on order.  Rev B uses the FE310-G002 chip and according to the manual, it has 8 PMP registers (physical memory protection) with user and machine modes too.  Note that SparkFun has a Red-V board that has the FE310-G002 chip so it has same memory protections as the RevB board and is available for purchase ($40).  That would be another board to look into.  Let me know where I should start with the porting process, and I'll see if I can make it happen.  Appreciate it,

               Daniel 

   

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/5a3fab52-27fe-4b3f-bdc2-4450dd6634e0%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/c87b5c0a-2178-43c9-b0eb-a7f9dea6619c%40googlegroups.com.

[Brad Campbell]

Yes, you should be able to largely copy the e310x crate and use the sifive and rv32i crates. You will also notice that the e310x crate is mostly just assigning memory addresses to the drivers defined in the shared sifive crate.

- Brad

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/c87b5c0a-2178-43c9-b0eb-a7f9dea6619c%40googlegroups.com.

[Patrick Mooney]

On Mon, 24 Feb 2020 at 10:27, Brad Campbell <bra...@gmail.com> wrote:
>
> Yes, you should be able to largely copy the e310x crate and use the sifive and rv32i crates. You will also notice that the e310x crate is mostly just assigning memory addresses to the drivers defined in the shared sifive crate.

I picked up one of the aforementioned RED-V boards and Tock bring-up
hasn't been quite that straightforward so far. I'm not sure if there
are changes between it and the "official" HiFive1B which would make
the experience there any better, though.

[Daniel Hayes]

Thanks for the replies.  I will start reviewing the existing crates mentioned and get a feel for what will need to be changed.  Also, I'm new with GitHub, should I clone the repo to my local machine and work on it there or submit a pull request?

[Brad Campbell]

Ultimately, a pull request would be awesome, but to start you want to clone the repository to your local machine and make changes there. When things are working you can open a pull request. We have some general directions in the contributing document: https://github.com/tock/tock/blob/master/.github/CONTRIBUTING.md

- Brad

--

You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/15dd3071-3cc4-4706-bb9e-fae1cbbf0970%40googlegroups.com.

[Daniel Hayes]

Perfect, I will clone the repo tonight and go by the contributing link you provided.  Thanks

On Monday, February 24, 2020 at 12:09:52 PM UTC-5, Brad Campbell wrote:

Ultimately, a pull request would be awesome, but to start you want to clone the repository to your local machine and make changes there. When things are working you can open a pull request. We have some general directions in the contributing document: https://github.com/tock/tock/blob/master/.github/CONTRIBUTING.md

- Brad

On Mon, Feb 24, 2020 at 11:53 AM Daniel Hayes <dhay...@uncc.edu> wrote:

Thanks for the replies.  I will start reviewing the existing crates mentioned and get a feel for what will need to be changed.  Also, I'm new with GitHub, should I clone the repo to my local machine and work on it there or submit a pull request?

On Monday, February 24, 2020 at 11:30:42 AM UTC-5, Patrick Mooney wrote:

On Mon, 24 Feb 2020 at 10:27, Brad Campbell <bra...@gmail.com> wrote:
>
> Yes, you should be able to largely copy the e310x crate and use the sifive and rv32i crates. You will also notice that the e310x crate is mostly just assigning memory addresses to the drivers defined in the shared sifive crate.

I picked up one of the aforementioned RED-V boards and Tock bring-up
hasn't been quite that straightforward so far.  I'm not sure if there
are changes between it and the "official" HiFive1B which would make
the experience there any better, though.

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.

[Daniel Hayes]

I'm new to embedded system development. I do have basic understanding of things like makefiles, source files, header files, toolchain, etc.  I want to learn more about development with embedded OS, especially Tock, to not only aid in my attempt to port Tock to the HiFive RevB, but in general as well.  Any suggestions on what topics would get the furthest the quickest?  I'm studying Rust in-depth currently.  Thanks

Daniel

On Monday, February 24, 2020 at 12:09:52 PM UTC-5, Brad Campbell wrote:

Ultimately, a pull request would be awesome, but to start you want to clone the repository to your local machine and make changes there. When things are working you can open a pull request. We have some general directions in the contributing document: https://github.com/tock/tock/blob/master/.github/CONTRIBUTING.md

- Brad

On Mon, Feb 24, 2020 at 11:53 AM Daniel Hayes <dhay...@uncc.edu> wrote:

Thanks for the replies.  I will start reviewing the existing crates mentioned and get a feel for what will need to be changed.  Also, I'm new with GitHub, should I clone the repo to my local machine and work on it there or submit a pull request?

On Monday, February 24, 2020 at 11:30:42 AM UTC-5, Patrick Mooney wrote:

On Mon, 24 Feb 2020 at 10:27, Brad Campbell <bra...@gmail.com> wrote:
>
> Yes, you should be able to largely copy the e310x crate and use the sifive and rv32i crates. You will also notice that the e310x crate is mostly just assigning memory addresses to the drivers defined in the shared sifive crate.

I picked up one of the aforementioned RED-V boards and Tock bring-up
hasn't been quite that straightforward so far.  I'm not sure if there
are changes between it and the "official" HiFive1B which would make
the experience there any better, though.

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.

[Brad Campbell]

Some places to look might be:

• The course in the Tock Book, particularly the section on writing a capsule: https://book.tockos.org/capsule.html
• The overview and design documents in the kernel doc folder.

Much of Tock, particularly in the chips/ folder, is fairly common to any embedded systems software. The documents in the doc/ folder describe the Tock-specific aspects.

- Brad

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/00b8cf7b-da4f-412c-a004-2affbc046329%40googlegroups.com.

[Daniel Hayes]

I'm hoping to finish going through Rust in the next week or so.  I will go through all the documents you've mentioned next, and hopefully I will be up to speed for the port in a couple of weeks.  Appreciate the support, and I will keep this thread updated.  

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/00b8cf7b-da4f-412c-a004-2affbc046329%40googlegroups.com.

[Daniel Hayes]

@Brad I've setup my computer with the https://github.com/riscv-rust/riscv-rust-quickstart guide.  I was able to upload the led_blink example successfully.  The programming looks a little foreign to me compared to what I'm used to.  Where can I learn more about the code below?  Thanks!

use riscv_rt::entry;
	use hifive1::hal::prelude::*;
	use hifive1::hal::delay::Sleep;
	use hifive1::hal::DeviceResources;
	use hifive1::pin;

[Brad Campbell]

The embedded Rust project has its own book: https://rust-embedded.github.io/book/, but I'm not personally familiar with it so I'm not sure if it would be able to answer your question. The code you sent looks like Rust imports for various resources from the risc-v port of the embedded rust project. But I'm not super involved and do not immediately know the details of how the hifive1 support is architected.

- Brad

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/a15755b4-f4b5-48f8-93d5-fe4c29841bf7%40googlegroups.com.

[Daniel Hayes]

Oh okay.  The repo said it was maintained by the risc-v team, and you were listed on it.  The main contributor was in Russia, I think, so I wasn't sure about getting a prompt response.  I appreciate your time, and I will add this book to the 10 others I need to read to be able to do my project.  Dang what I wouldn't give to be able to learn this stuff like in The Matrix.  Just plug me in!!!  This project is going to bring me to tears, sigh.  Thanks,

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/a15755b4-f4b5-48f8-93d5-fe4c29841bf7%40googlegroups.com.

[Daniel Hayes]

Does anyone know if I can use a secure bootloader to launch the Tock OS? I am thinking about using WolfBOOT for secure boot and secure OTA updates.

[Philip Levis]

You can — we do this on Titan:

https://github.com/google/tock-on-titan

Depending on how your secure boot loader works, you might need to forego dynamically loading apps. I.e., you have to put the apps and kernel into an image and sign that image. This is what the above code does. The key part of the Makefile is in the user space directory:

https://github.com/google/tock-on-titan/blob/b35d985b322b017bd60005d406f6662dcdc94b2b/userspace/Build.mk#L108

This compiles the userspace app, compiles the kernel, combines them into a merged image, signs it, prepends a stage 2 boot loader (the stage 1 checks that this stage 2 boot loader hasn’t been tampered with), and makes that the final image.

Phil

On Mar 14, 2020, at 5:43 AM, Daniel Hayes <dhay...@uncc.edu> wrote:

Does anyone know if I can use a secure bootloader to launch the Tock OS?  I am thinking about using WolfBOOT for secure boot and secure OTA updates.  

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/8fa10c6a-bade-435f-9304-a64482d79543%40googlegroups.com.

———————
Philip Levis (he/him)
Associate Professor, Computer Science and Electrical Engineering

Faculty Director, lab64 Maker Space
Stanford University
http://csl.stanford.edu/~pal

[Daniel Hayes]

Makes sense.  Thanks for the info Phillip.  I'm not ready for this just yet, but I wanted to make sure that everything will work once I do get there.  Appreciate It,

Daniel

On Saturday, March 14, 2020 at 10:58:27 AM UTC-4, Phil Levis wrote:

You can — we do this on Titan:

https://github.com/google/tock-on-titan

Depending on how your secure boot loader works, you might need to forego dynamically loading apps. I.e., you have to put the apps and kernel into an image and sign that image. This is what the above code does. The key part of the Makefile is in the user space directory:

https://github.com/google/tock-on-titan/blob/b35d985b322b017bd60005d406f6662dcdc94b2b/userspace/Build.mk#L108

This compiles the userspace app, compiles the kernel, combines them into a merged image, signs it, prepends a stage 2 boot loader (the stage 1 checks that this stage 2 boot loader hasn’t been tampered with), and makes that the final image.

Phil

On Mar 14, 2020, at 5:43 AM, Daniel Hayes <dhay...@uncc.edu> wrote:

Does anyone know if I can use a secure bootloader to launch the Tock OS?  I am thinking about using WolfBOOT for secure boot and secure OTA updates.  

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/8fa10c6a-bade-435f-9304-a64482d79543%40googlegroups.com.

[Daniel Hayes]

I'm now looking at configuring the physical memory protection (PMP) registers in Rust.  This should apply to the HiFive1 RevB port at some point.  I have not been able to find any implementation of using PMP in Rust.  SiFive has a Freedom Metal library that has pmp.c and pmp.h files that are used in their PMP configuration example code.  Obviously, it is in C and I'm wanting to focus writing code in Rust for my project.  I'm thinking of writing the Freedom Metal implementation in Rust.  Does that seem legit?  I tried to post this on the SiFive forum, but it says it's in read only mode??  If this post belongs on another forum, apologies, and just point me in the right direction if possible.

Appreciate it, Daniel

C library file - https://github.com/sifive/freedom-metal/blob/v201908-branch/src/pmp.c

Header file - https://github.com/sifive/freedom-metal/blob/v201908-branch/metal/pmp.h

Example C Program to configure PMP - https://github.com/sifive/example-pmp/blob/57e15fee6a1dbbb06f0f615892488090a0b05d26/example-pmp.c

[Brad Campbell]

We have a basic PMP implementation in Rust: https://github.com/tock/tock/blob/master/arch/rv32i/src/pmp.rs. But it is based on the Tock MPU trait, the Tock process loading model, and the Tock register format, so I'm not sure how helpful it will be for you.

- Brad

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/fb2a4591-180b-4e88-b318-a6d60bbd41b3%40googlegroups.com.

[Daniel Hayes]

I didn't realize that the PMP configuration was already there for rv32i chip for the Tock OS.  Most likely, I'm going to have to make a much simpler implementation without an OS to begin with. I don't think I can get Tock ported to the RevB in time to meet my project deadlines.  I'm hoping to still incorporate Tock into my masters thesis after my senior design project though.  Hopefully, I will be better versed on the subject by then  Thanks Brad,

Daniel     

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/fb2a4591-180b-4e88-b318-a6d60bbd41b3%40googlegroups.com.

[Daniel Hayes]

I'm a little confused on how the MPU configuration works.  I'm using RISC-V so I will refer to it as PMP (physical memory protection).  Is the idea to use the pmp configurations to isolate each user app?  How many pmp entries are needed per app?  I originally thought that you would setup one pmp per user app, but now I'm thinking that it may take 2 or 3 entries because of RAM and ROM for each user app stack.  Can someone give me a little more clarity on this?  Thanks

Daniel

[Amit Levy]

You can use as many entries you need per app. On ARM we use 3 at least, and the remaining 5 are used for shared IPC regions.

The trick is that the kernel dynamically changes the PMP configuration when it context switches between user space processes. So using all PMP entries for a single process doesn't preclude also using all entries for a different process, since they never run at the same time.

--

You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/450c0356-1c50-4459-9900-4e39d2a12fd0%40googlegroups.com.

[Daniel Hayes]

Okay that helps my understanding a lot.  Is there a possibility for a bad actor to modify the PMP configuration from the network stack?  I know that having dynamic PMP entries gives you "unlimited" zoning, but it seems that smaller applications could use the Lock bit to prevent even machine mode from altering the entries and increasing security. 

I took this photo from the tock's github, does this stack show two pmp entries?  One for flash and one for RAM?  Also, I understand that the pmp address register is 32bits.  For TOR it just lists the top address for the range, where NA4/NAPOT uses the most significant bits to specify a starting address, and the least significant bits to determine the range size.  Is this correct?

I hate to bother you guys too much with this stuff.  I'm trying to learn and this forum has proven to be the most useful so far, so thanks!  Hopefully, I can make some worth while contributions to Tock at some point :)

Daniel

On Thursday, March 26, 2020 at 5:35:58 PM UTC-4, Amit Levy wrote:

You can use as many entries you need per app. On ARM we use 3 at least, and the remaining 5 are used for shared IPC regions.

The trick is that the kernel dynamically changes the PMP configuration when it context switches between user space processes. So using all PMP entries for a single process doesn't preclude also using all entries for a different process, since they never run at the same time.

On 3/26/20 3:49 PM, Daniel Hayes wrote:

I'm a little confused on how the MPU configuration works.  I'm using RISC-V so I will refer to it as PMP (physical memory protection).  Is the idea to use the pmp configurations to isolate each user app?  How many pmp entries are needed per app?  I originally thought that you would setup one pmp per user app, but now I'm thinking that it may take 2 or 3 entries because of RAM and ROM for each user app stack.  Can someone give me a little more clarity on this?  Thanks

Daniel

On Wednesday, February 19, 2020 at 9:13:19 AM UTC-5, Daniel Hayes wrote:

Any plans on having board support for the HiFive1 RevB?  I'm working on my senior design project on IoT security using RISC-V and Rust on the HiFive1 RevB board.  I saw Tock on GitHub and it seems kind of interesting.  Thanks!

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.

[Amit Levy]

On 3/26/20 7:36 PM, Daniel Hayes wrote:

Okay that helps my understanding a lot.  Is there a possibility for a bad actor to modify the PMP configuration from the network stack?  I know that having dynamic PMP entries gives you "unlimited" zoning, but it seems that smaller applications could use the Lock bit to prevent even machine mode from altering the entries and increasing security.

Not really. I'll explain.

A process can't modify the lock bit, or any other PMP registers for that matter, because processes are run in U mode, and U mode can't access those registers. So a malicious process can't do anything like that, at least not on it's own.

Inside the kernel, Tock isolates components using the Rust module and type system into components called "capsules." These components aren't allowed to use `unsafe` Rust, and as a result, can only do things that the rest of the kernel allows them to (the Threat Model document that Johnathan is currently drafting goes into more detail about exactly what a capsule can and cannot do: https://github.com/tock/tock/pull/1632)

So, the only code that can affect the PMP is the trusted part of the kernel, which includes the "kernel" crate (which performs process scheduling and context switching, as well as the lowest level of interrupt handling), and the chip-specific crate (which is responsible for mapping hardware registers to Rust).

There are caveats, of course... in the process case, there could be a bug in the hardware that would somehow allow the process to bypass U-mode constraints.

In the kernel case, there could be a bug in some trusted code that either exposes the PMP somehow or that violates Rust soundness constraints, in which case more or less all bets might be off. So the goal is to keep this code to a minimum and as simple as possible, and try to reason about it carefully.

Does that make sense?

 

I took this photo from the tock's github, does this stack show two pmp entries?  One for flash and one for RAM?

Close. We actually use one for text, one for RAM, and another one for the grant region. Using an additional entry for the grant region is actually a hold over from ARM, where the PMP is less granular. And there is, of course, an implicit region that covers the entire address space and prevents access by default.

Also, I understand that the pmp address register is 32bits.  For TOR it just lists the top address for the range, where NA4/NAPOT uses the most significant bits to specify a starting address, and the least significant bits to determine the range size.  Is this correct?

Hopefully someone who understands RISC-V specifically better can answer this better :)

I hate to bother you guys too much with this stuff.  I'm trying to learn and this forum has proven to be the most useful so far, so thanks!  Hopefully, I can make some worth while contributions to Tock at some point :)

<3

Daniel

On Thursday, March 26, 2020 at 5:35:58 PM UTC-4, Amit Levy wrote:

You can use as many entries you need per app. On ARM we use 3 at least, and the remaining 5 are used for shared IPC regions.

The trick is that the kernel dynamically changes the PMP configuration when it context switches between user space processes. So using all PMP entries for a single process doesn't preclude also using all entries for a different process, since they never run at the same time.

On 3/26/20 3:49 PM, Daniel Hayes wrote:

I'm a little confused on how the MPU configuration works.  I'm using RISC-V so I will refer to it as PMP (physical memory protection).  Is the idea to use the pmp configurations to isolate each user app?  How many pmp entries are needed per app?  I originally thought that you would setup one pmp per user app, but now I'm thinking that it may take 2 or 3 entries because of RAM and ROM for each user app stack.  Can someone give me a little more clarity on this?  Thanks

Daniel

On Wednesday, February 19, 2020 at 9:13:19 AM UTC-5, Daniel Hayes wrote:

Any plans on having board support for the HiFive1 RevB?  I'm working on my senior design project on IoT security using RISC-V and Rust on the HiFive1 RevB board.  I saw Tock on GitHub and it seems kind of interesting.  Thanks!

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/450c0356-1c50-4459-9900-4e39d2a12fd0%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/b589895a-f09d-471f-8ec1-80711a591ec8%40googlegroups.com.

[Daniel Hayes]

Thanks for the detail Amit.  I have couple of more questions.  I noticed that the stack is at the bottom of the diagram, usually the stack is at the top and grows down towards the heap.  Is there a significant reasoning behind this addressing scheme?  Also, is the tockloader responsible for setting up the pmp addresses for each application space?  Does the tockloader have a custom linker to setup the sandboxes?  Finally, Does Tock utilize any user interrupts, or is the request sent to the kernel which then calls the interrupt.  Thanks,

Daniel  

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/b589895a-f09d-471f-8ec1-80711a591ec8%40googlegroups.com.

[Amit Levy]

On 3/28/20 1:37 PM, Daniel Hayes wrote:

Thanks for the detail Amit.  I have couple of more questions.  I noticed that the stack is at the bottom of the diagram, usually the stack is at the top and grows down towards the heap.  Is there a significant reasoning behind this addressing scheme?

There are two.

First, there are three dynamically growing sections instead of just two: the stack, heap and grant sections (grants belong to the kernel, but are allocated in process space).

Second, putting the stack at the bottom helps to catch stack overflows. When the stack overruns it'll result in memory access outside of the process memory and thus in a memory fault, as opposed to potentially accessing heap data.

Also, is the tockloader responsible for setting up the pmp addresses for each application space?

No, the kernel is. Tockloader just flashes the process binary onto the device.

Does the tockloader have a custom linker to setup the sandboxes?

There isn't a custom linker per-se (we just use GNU LD), but Tock does rely on a particular configuration of the linker, in coordination with the user space `_start` symbol's implementation for the code to be properly position in dependent.

Finally, Does Tock utilize any user interrupts, or is the request sent to the kernel which then calls the interrupt.  Thanks,

Exactly, interrupts are handled by the kernel, and the kernel decides whether and which process to notify. In fact, typically a hardware interrupt will go through a device specific software stack in the kernel and may or may not result in a user-space callback. For example, userspace can get callbacks for a temperature reading being available, but that involves 10 or so I2C interrupt in the kernel before it's propagated to userspace.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/7c7830fb-fecb-4ebc-b377-4a1a83e8a3eb%40googlegroups.com.