 Awesome, okay. I think I'll I'll make a start to the presentation. So thank you all for coming I'm a dr. Martin of on the mass. I work for low risk low risk is a community interest company and Our goal is to make open silicon a reality. So taking the kind of System that's worked really well for open source software and making that a reality for silicon hardware Etc So a little bit about about low risk. So our tagline is open to the core we're located in Cambridge, UK and in Zurich, Switzerland and As I said before our mission is to make open silicon a reality and it's very important for us that Verification and a fully verified silicon is part of that that answer and verification. I mean I mean What you would usually say as testing in in software. So that's that's what verification in in silicon terms means and A little bit of an introduction to our big project open Titan So open Titan is a silicon root of trust This is a chip that you can put in your products and it'll provide security services like secure boot We have lots of partners. We're very grateful to all those partners for making open Titan a reality It's it really is not cheap to make a chip that is fully verified and you can you're able to tape it out Taping out means that you're actually manufacturing it and actually creating chips out of it So without their their support this really would not be possible So I'm gonna make the case here that open silicon is hard, but why is open silicon hard? So first of all there aren't really any real examples So there there are some open source hardware projects out there But none of them to the level of where you can say these are fully verified all the verification collateral is out there You want you all of your design verification. You want all of your ci runs all of those logs to be open So that's really what we're talking about with an open source example of hardware So that just really doesn't exist open Titan is kind of its first of its kind there Another reason why open source silicon is more difficult than open source software is that updating is very different So once you've manufactured your hardware You can't update it anymore, right? You can update you can update software obviously in the firmware that's running on top of it But you cannot update the hardware itself Unless you're gonna really expensive ship and you chip to all of your customers. That's that's obviously really expensive On top of that we have an ecosystem that has started out very close source so we have For example, we have the tools from synopsis and cadence those EDA tools are used to actually Translate your hardware design into what your chip would actually look like And we just need to support those types of tools because that's those are the people that will actually Manufacture this chip, but we also want to support open source tools like fairer later and variable So we have we have the challenge of supporting both the open and the closed world and Then the other two icons on this slide are UVM, which is a verification methodology It's a way to write tests for your for your silicon and this is inside the system verilog language Which we also use to define Your hardware So that's really what we're trying to do. We're trying to straddle these two two worlds And that's another reason why open source silicon is difficult So what what progress are we making with open Titan? We're not solving everything But if you look at this slide the red is what's open source and the gray is what's proprietary So in in the usual silicon world, you might have some open source firmware You might have some open source PCV designs, but Everything else will be proprietary in open Titan We actually open source a lot of the stuff including the RTL, which is the actual design of your your hardware We have the SOC architecture the instruction set architecture Some of you may know risk 5 risk 5 is an open instruction set So that is what we're using in this in this project process and also the firmware We we open source all of our firmware, which is not always a given with chips There are still some gray blocks as you can see so for example the process design kit or the foundry Hardware IP blocks the analog IP blocks So we're not solving all of these things, but we are making progress For example, there are examples of the physical design kit There are open source examples of those Not many of those are used in commercial chips, but at least we're making progress there There's at least one flow where you can get a completely open source chip And in terms of license we've learned from the software world So we wanted a license that was very permissive We wanted a license that we can be able to be used in open source But we also needed to be able to be used commercially Because those are the people that will actually take this design and actually tape it out and another reason for this is Open Titan is a secure root of trust and one of the reasons to take that particular use case is to really raise the level of kind of the minimum level of security in your in the in the industry So not every person or every company Designs their own security root of trust and you don't really know what the level of security is now at least They can take open Titan and they can still put their all their own secret little sauce on top of it But you have that base level of security that you can rely on in the industry And we believe Apache license 2.0 is is the correct License for us to permissively license open silicon What are other things that we've learned from software so we really want to Leverage the lessons that open source software has learned So open source it sounds kind of Duh, why are we doing open source? But it's not just the code obviously it's the design verification So the testing environment that you want to have open source you want your issue tracks You want your decision-making process all of this stuff open source and that's the case for open Titan You can go on github and actually see all of it working Also version control this is something that we've learned from open source software Continuous integration so this kind of continuous integration cycle is super powerful I don't have to convince any of you here But really applying that in silicon making that sure that every single pull request is tested Making sure that there's nightly regressions on the main branch that make sure that you don't have any Yeah, that you make sure that everything on the main branch is always working correctly and making sure that all of these logs and Artifacts are truly open source and that's not easy to do because a lot of our tests We have to run on proprietary tools So making all those test results available is something that that is not Yeah, not easily done in silicon Another aspect is differential fuzzing so differential fuzzing is a popular software testing technique where you take two To Programs and give them the same input and see if the output is the same So two two different programs that are supposed to do the same thing and you can do a very similar thing in silicon So for example in this case we have a model and an implementation The model could be a an ISA simulator for example a risk 5 simulator And the model and the implementation could be our CPU which is called Ibex risk 532 Bit CPU and then you have a testing Framework that creates constrained random instructions And make sure that the model and the CPU actually do the same thing Coverage a well-known concept in software. We also use this in in hardware. So we have Example code coverage. We have test pass rates Functional coverage all of this increases the confidence that our design is doing what it's supposed to be doing and we can also learn from formal verification in Functional programming languages for example and then use formal analysis to prove properties of our hardware So we do all of those things and then we also add things like finite state machine Coverage and toggle coverage, which are a little bit more specific to hardware and Then governance Governance doing open source as we as we actually learned in one of the in the keynotes It's not just about making your source code open. It's also about having open governance So we have a steering committee to make project-wide decisions and working groups That focus on specific tasks We have standards and developer practices to make sure that everybody is on the same platform Everybody has the same environment to work off of And we have a workflow that includes code review and issues So yeah, this is kind of the introduction of the talk Are there any questions so far That's good. I'm assuming that that's a good sign. So then let's go specifically into Open Titan so We believe that open Titan does it right? So I'll tell you a little bit about kind of the high-level Verification setup that we have for open Titan. So this is open Titan Open Titan. This is a block diagram of open Titan and you can see lots of individual hardware IP blocks So part of making open silicon reality for low risk is making sure that we have a library of hardware IP blocks that anybody can use to do specific tasks But in terms of verification, how do you know that each of these blocks are doing the right thing? How do you know that each of these blocks even if they individually test to do the correct thing? How do you make sure that they interoperate seamlessly? And so this is really the tough question that we're we're trying to answer here Okay, so we have three different tracks. So we take our design and we do simulation on it So simulation you can do both block level simulations where you just take your block and you Run individual tests on them, but you can also do chip level simulations where you do interoperability tests Then we have FPGA tests. So FPGA is a field programmable gate array This is programmable hardware, but it's actually a physical chip So you don't have internal Knowledge of the internal signals like you do with simulation But it is very useful because it's actually running on hardware and you can for example connect some Breakout boards to them to make sure that it interoperates with external devices that you need to interoperate with and eventually we will add silicon to this this design framework as well and then as I mentioned we have all those different IP blocks, but each of these IP blocks can be at different stages of development and verification. So we we've designed these kind of labels that you can label each of these blocks and Make sure that Once you try once you try to hit a milestone for the whole chip You can kind of work block by block and so you you go through specification Developing an initial version Then functional means that you have kind of all the functions there and you're kind of generally happy with with the design and the verification We have a separate A separate stage for security So these are security counter measures that you need in your in a chip like open Titan And then once you're happy with all those design and the verification you can sign off complete So that's the d3 and v3 and then once you have all of your blocks be d3 and v3 Then you sign off the complete chip and you can do a proper manufacturing of that of that chip So it's quite a rigorous process. I haven't specified exactly What what we use but on our documentation you can see the very specific criteria for each of these these stages and That kind of comes back to as I said the documentation is Open-source, but also the dashboards are open source So you can go to the open Titan website and you can see the results of this is the results of the latest nightly Where you can see the actual coverage the coverage and the pass rate for the chip in general But also for each of the individual IP IP blocks. So that's What we believe is very important Okay, is that all a little bit clear So this is kind of the high level overview and I'll go now go into a little bit more of the details But are there any questions so far? Okay, good So then let's go a little bit more into the details about verification of open Titan So I'll zoom back out. So this is the complete Chip overview So we have all these different IP blocks and I mentioned earlier that we would do Specific block-level tests. So I'll zoom in on one of those blocks, which is the top Do I know my left on my right top left I vex so I vex is our our CPU You can go on github and see it its production quality So That means that it's been extensively used both closed source and open source projects and it's undergone Multiple tape outs. So that's why we believe it's it's very mature and it's not just the hardware that's open source It's also the whole design verification Environment that we've created around it Now kind of going into I vex we have a three-stage pipeline. It's a relatively simple processor instruction fetch execute and write back and Those three pipeline stages interact on the one hand with the internal registers And then on the other hand with the memory and the memory is protected by this thing called e pmp Which is a memory protection unit and I'll go into a little bit more detail about that now So I want to talk to you about how what steps we did to verify e pmp So before I do that, I want to explain what e pmp is so e pmp is enhanced physical memory protection In ibex or at least the version of ibex that we use in open Titan We have 16 of these regions so you can specify 16 different regions with different permissions So it has different permissions and different region sizes For example the table I show here is the different types of regions. You can specify in pmp Zero obviously means that you're not using that region at the moment top of range means It's the address in this particular region Up until the address of the previous one Then we have two that are kind of standalone so na4 is a just a four byte region So you can set the permissions on four bytes specifically and then not pot is Power of two aligned region So these are these are very different types of regions and you have to do in your verification You have to make sure that you hit all of these types of regions Fairly if that makes sense so then That's kind of the physical memory protection side of things And but then when they added the e to it the enhanced part to it They wanted to make sure that even in M mode, which is the Highest privilege mode in your processor even that mode should be restricted So that's why why they call it enhance and they did that with three kind of separate permission bits So the first is machine mode lockdown which allows you to create regions that are Accessible in your user programs, but not in your kernel So that's kind of like a weird asymmetric thing So usually everything that's accessible in user land is also accessible in in your in M mode So that that locks that down then there's also mmwp, which is an interesting thing where usually your PMP if If you're in your M mode execution and a region is you're trying to access a memory That's not in your PMP. You're allowed to access it But the wireless policy means that if it's not in your PMP, you're not allowed to access it So that's an extra little bit of security When you're in M mode and then because these mml and mmwp Kind of add extra restrictions to M mode They also had to add this rule lock bypass, which allows you to temporarily bypass the locked rules and this is usually used in the setup where you kind of Bypass the locks you set everything up and then you Undo the the bypass Okay, so that this is kind of the background to PMP E-PMP so for for the testing side of things I wanted to show you a little bit about What this does to our state space so initially without the enhanced part We just had these sets of permissions so we had the lock the right the read and the execute bit and All the different combinations that you can have with that, but now that you add mml to it each of these Regions actually have different permissions. So you actually double the amount of state space. So what each of these regions exactly do is Not super important But it's the important part of it that you're is that you're doubling the space state space The other aspect of it is that the setup process becomes a lot more difficult. So Just from the beginning if you don't have mml or mmwp You can just go from the top. So you you can boot up. You can not worry about mmm mmwp you can configure your PMP with random regions and then you can just start your test That's that's how we used to do things But that doesn't work when you have these machine mode lockdown and machine mode whitelist policies Why doesn't that work? Because you need your code and your trap handler to be executable for example So if you enable if you don't set any regions and you enable machine mode whitelist policy You cannot execute where you're currently in your program If that makes sense because you're not allowed to access anything that's not in your PMP So you have to make sure that there's something in your PMP Before you enable the whitelist policy So that's that's that's what I'm trying to show with this diagram So as I mentioned before if you do have mml or mmwp you first enable the rule lock bypass So you let you can safely change things before you kind of get All your permissions are wiped under your feet Then you generate a random code region which allows you to make your test code and your trap handler executable There's also a kernel stack which you need to make sure are read and write bowl And there's a signature entry which is used for testing purposes If mml mode is set you need to make sure That the code Entry is set to executable both before and after mml Now this needs a little bit of explanation as I said said before we have those different permissions but if you Because in machine mode lockdown you don't have the same permissions as you do in user mode anymore You need to make sure that your code entry actually Like the permissions that you have even if you have execute permissions before you set mml You might not have it afterwards So you need to make sure that the entry that you set of the code that you're currently running is Executable both before and after setting mml. Otherwise you get wiped and then you are in an infinite loop of traps So then after that then you can enable mml and mmwp And then you can actually start configuring the random regions that you generated at the beginning And then once you're happy with it then you set the actual rule log bypass that you needed So sometimes you want to test enabled or disabled and then after that you go into your actual test So that's what I'm trying to Say with this diagram Then what did we achieve? How did what yeah, so before we had 66% coverage of our PMP functional coverage points So this includes just the regular PMP testing that we we had done before Then we added some static tests to just say okay, let's enable mml. Let's enable mmwp Let's see what what happens. So those are just static tests. We got quite a good jump from 66 to 86 percent And then we did the step that I just described where we actually do full random Configuration and we got from 86 to 95 percent Now even with the full random Even with the fully random Testing we still had this 5% that we we didn't Cover and so we added some directed tests to make sure that we cover them And what are those for example one of the caveats of mml and machine mode lockdown is that Once you lock things down, you're not allowed to add any regions that are also executable You're not allowed to add code regions. That's one of the rules of mml But that was not being tested by our completely random Configuration or at least not reliably obviously like sometimes it does get tested Then as I mentioned before there's these four byte regions That you can test our initial test wasn't hitting those reliably You need to bias your random address generation to actually hit these four byte regions if you do set them And then the other thing is Because the test usually is in one part of memory. It usually just hits one PMP Entry what you want to do for certain tests is that you actually go through all of the PMP entries and try to execute from each of them So those are the kind of directed tests that we we used and this is At least in a high overview how we tested EMP. I know it was a bit a bit convoluted But is there any can I clarify anything to anybody on EMP testing? Otherwise I'm gonna go on to the next thing so part of open Titan is that we Have a lot of primitive blocks so primitive blocks are essentially like a standard library for silicon So every single block will use things like alerts or clocks or five foes Etc. So there's a lot of varieties of these things in our library and we make sure that Yeah, we make sure that the whole project uses these particular primitive blocks and they don't use their own thing So that gives us a couple of nice things So one of the things that is very important in silicon testing is clock domain crossing testing So sometimes in your chip well usually blocks are driven off of a clock Which is just a wave so at each clock cycle something happens But if you have a big chip you often have multiple clock domains So multiple different clocks and that means that sometimes when you have two clocks interacting with each other There will be like a one-cycle delay between One signal, but not the other signal just because of that domain crossing So what we can do in our primitive library. We have this thing called the prim CDC ran delay and we can implement that in all the Flip-flops that we we would like to use and the way that we do things is We give it the previous data the source data and the destination data Then it generates a random Bitmask to say certain parts of the signal. I'm going to delay certain parts. I'm not going to delay and then You kind of multiplex the output based on either the previous data or the source data And the reason why each wire is kind of individual is because if you're physically on the chip Each wire can have a different length for example. So sometimes one wire will Be delayed while the other one happens once clock cycle before so that's one of the really powerful things about having this standard primitives library and And then a little bit more on a high level So we believe that open Titan has kind of seven virtues That we believe that every successful open silicon project should do the first one is being commercially relevant. So making sure that Commercial companies would like to use this and also are able to then having a repository that's kind of a given but also having a repository that Has all the decision-making the issue tracking all of that open source The tree stands for provenance. So provenance of the hardware IP blocks. That's very important You don't want to use certain hardware IP blocks that don't buy to your license but you also don't want to Yeah, you don't want to use certain proprietary blocks accidentally and then some other company when they're using this This open source project get into legal trouble. So that's something that's really important Verification that's what I've been talking about a lot But we need to make sure that CI is open source or accessible to everybody and And the dashboards as I mentioned Then documentation and training all of that is open source so you can go to open Titan org find everything there We have clear governance making sure that we have clear processes For anybody to make a change so we have this kind of formal request for change policy where anybody any partner or any person participating in the project can ask the steering committee or the working group to do something and The last one here is focus So we want to be focused and not too over ambitious because it's such a big task to do open silicon We decided to take this very specific use case of creating a route of trust And that's what we we did and that's what open Titan is trying to achieve So after an amazing verification effort Open Titan hit frozen milestone, which is a very big milestone for open silicon So once we have this frozen milestone We can actually do a tape out so actually manufacture our design and we are expecting to receive test chips back Based on this freeze very soon And hopefully add that little block that I said in the beginning where you have the FBJs in the silicon and the simulation So we're really excited about that And then finally Here's a URL So you can see the slides, but also this has all the notes so notes and links So it's not just the slides. It's a complete handout and also Feel free to send me an email about anything if you're if you're interested Yeah, and thank you very much and I'm happy to take any questions now as well So thank you Good So there was a question here about what kind of caches the Ibex core has and whether it has any protections against side channel attacks, right? so the Ibex core Because our open the open Titan ship has lots of different blocks to do For all the expensive operations like if you want to do RSA or ECDSA or AES any kind of cryptographic Optimization and there's a separate hardware IP block. So it doesn't need to be very high performance We don't actually have a data cache. So we we We just interact directly with memory We do have an instruction cache And that that does exist in the Ibex Does that answer your question? Yeah, great and You can also build Ibex without the eye cache by the way, but yeah Yes, so we have we have this is also open source. There's a whole open Titan side channel analysis repository So there's there's multiple types of side channel attacks. You have to protect against For example timing attacks power analysis Yeah It's yeah, it's all open source. So you can you can find that one of the things that we do for example We have a big number block which does the asymmetric cryptography and that one does masking so there was there was one person who had looked at Analyzing the program to make sure that these two different key parts never met So that's that's something that we do and make sure that the code that we run on these hardware Accelerators are also secure great any other questions. I know there's some a fun night in the In the stadium waiting awaiting us great Well, thank you very much for all your attention and please do send me an email if you think of anything else or Contact low risk in any of the way. So thank you very much