Now, let's take a look at what Secureboot loader does step by step. The first thing to understand is a very simple boot loader. This boot loader will just do a jumping to the target application. It's not yet a Secureboot loader at this moment. The first thing to achieve for a boot loader is to have a separate code from the target application. The Secureboot is always the first application to run. It is usually located at the beginning of the flash address. And this is a code always running after reset. And it is a standalone kind of application. This part of the code does not need to be compiled or linked with a target user application. And for such kind of purpose, we need to define a flash mapping and reserve certain kbytes of flash space for the boot loader itself. And then the rest of the memory can be allocated to application of its configuration data, etc. In terms of RAM, the boot loader will also have some data in RAM during its execution. But those part of the RAM can be then amputed and released before jumping to the application. This will avoid leaving any useful and wanted data to be available when application starts to run. This diagram illustrates how the boot loader launches an application. Assuming that we reserve 20 kbytes for the boot loader, then the boot loader starts from the base address of the internal user flash. And the application starts at the address of the base address plus an offset of 20 kbytes. At the beginning of the boot loader, the first word is the step pointer of the boot loader. Then the second word will be the reset handler PC. Then the following will be the vector table and then vector code, then the main code of the boot loader. The application is actually having the similar kind of structure. So at the start address of the application area, the first word will also be the step pointer and then the application reset handler address. So after reset, the CPU will get the step pointer and also start execution of the reset handler code of the boot loader. Then usually in the boot loader, the last piece of code is a jumper. This jumper will get the application step pointer. We also get the application reset handler address. And then it will set the main step pointer to the application step pointer address and then jump to the address of the application reset handler. Now it's time to have a hands-on for the simple boot loader. The goal of this hands-on is to show the different steps to create application and a simple boot loader, define a flash map for both application and boot loader and have the jumper code in the boot loader to launch the application. Thank you for watching.


I'm not the only one who's here early. How are you? How's it going? Good. How are you? I bet. So just from logistics, there's typically five minutes spent on housekeeping. See if there is updates on action items from prior meetings. Or anything like anyone wants to share or announce. I don't think there'll be anything major for today. So it shouldn't take more than that before getting started. I'll drop off from the other zoom I was on. Apparently I'm still logged in. We've been doing what's called the books print. Are you familiar with that? So think. Yeah. Think about how. Yeah. Screen writers and like people who write movies and TV shows, get together in a room and like crank out all the ideas. So producing from like zero to published and three to five days. And those used to be done in person. Now that it's gone virtual. It's two weeks. It's 10 days and we're like in the middle of week two. We're just writing about production identity. But it's like pair programming times 10. It's pretty intense. You're writing a book or a white paper. We're writing a book. We're right about 45,000 words. That's a good number of words. Yeah. Depending on, on how you edit the book. Looking at like 200 pages at this point. Emily's been on it. It's been fun. Hey, thanks for jumping in last night and. Getting that chapter four. Going. It was interesting to have last week sandwiched in between the two things. Like I thought it'd be like. So productive, but like everything I didn't get to like this two weeks, I had to cram in there. And I'm actually glad, glad to be back at just the single task. Just go, go, go. So you're, you're officiating. This is your first meeting is.  And person co chair last one. I was still technically co chair, but I was out. So. And then to the agenda and share it. The regulars know the drill, but whoever's new here, please add your name to the attendee list. security certification alpha testing. It was fine. I had more feedback that I expected that I would have. But it's turning out to be a good test, I think. Awesome. Yeah, I seem to have missed the call out. But well, I'm glad to have been able to participate in the authoring early on. That was fun. Yeah. Well, welcome everyone to today's six security call. If you're new here, please add yourself to the meeting notes and agenda. You will find under today's date. The attendee and like. List and action items. If you have an update to share, if you don't have an update to share, say no update, otherwise we can, we can do roll call. And I'll pass it to either Emily or Brandon. If you want to just like kick off and do like. First, before we get into talking with Eva, who's our guest joining us today to talk about confidential computing. So quick update on security day, we had over 30 talks submissions and a lot of them are actually really, really good. So it'll be very hard to select just a couple of them for a security day. So that team is working is when we have our meeting to go through and discuss everything. So we're, we're on schedule and we're doing really well. As far as the white paper goes. So we've started our narrative voice review where we're going to go through and talk about adding some consistency in the language that's used and make sure that the content of the document is easily readable that some of the thoughts. The thoughts are more cohesive throughout the doc. So if you had an outstanding comment in the document, we're going through and we're trying to resolve as many of them as we can. All right, I guess my update next. So we, we kicked off the security assessment improvement. And so we're trying out something new. I know some, some folks on this call may have experience with it. We are attempting to use mural to kind of brainstorm and kind of get ideas together for what we want for the security assessment improvements. If you're not already part of the site channel and want to participate, I'm going to paste in the link to the issue. You can comment on it. There's a list of things that we are currently working on. So if you're interested, just feel free to jump in. That's it for me. And in addition to the issue, there's also a Slack channel and there's going to be an ongoing call, right? Yeah, yeah, that's absolutely right. And all of it should be, should be in that issue comment right there. Also paste it in the agenda. Fantastic. I don't see any other updates coming from the attendance list. Okay. So Santiago, you want to tell us about the end total proposal? I saw that open up. You want to do a call out for folks to chime in. Sure. So in total is gearing for incubation and. Part of the diligence process is to have approval by the state. And. Yeah. So we discussed earlier on, it's been like an ongoing process. But we're finally starting to ask the state to input their. Self assessment conclusion, which the self assessment is probably. I would say number zero. It was the first one that happened. So there's a couple of things we need to revisit, but from discussions with the Sarah. And then on the other hand, it seems that since originally it was a recommendation for incubation, then it kind of, it makes sense to move forward with the original recommendation. Then again, I think. Being transparent and letting people chime in with anything new that. That may raise concerns. It's valuable. So we posted the. Google doc. In the, in the Slack channel and also Brandon send it in the GitHub PR. So if you want to take a look in the. And discuss or input some feedback and assume that eventually the state will come to a decision on what's the recommendation for incubation. I don't know if Emily or. Brandon or. I forgot what I was running it. I don't know if that's an input and how the process is. To both to go. If I recall correctly, at least what we did with over half. Really it was kind of copying over the outline recommendations. And I think with like over what, what then did at the time, let's just say, okay. We did a secure assessment. Here's how we recommended to date. The project has taken steps to fix. These issues and stuff like that. And I think it's just a short paragraph. I think the last one was filled up with. By. Justin and Dan and. I'm guessing we can do something similar. Okay. The last one was a grad was graduation. The last one we did, I think, which is not necessarily the same. Because the incubation one is supposed to be the most detailed review. Which was a lot. Did we do another? It was harbor and open. I think. I think both were for graduation. So. Yeah, so. Yeah, so we might need a bit more. Detail for incubation. Do you know anything specific that. That we should add in is that kind of. A template that we have to fill up. Is there a template. I don't have to check because I can't remember a friend of us. I remember the opal and harbor one being really loose which is like. Sick recommendations and then it's just kind of free form text. And that's why we paste it in. The security assessment results. Yeah. I should be able to dig up the original slide. That's a recommendation. From the top of my head it was mostly it seems that the project has done. I think it's a good idea. I think that's really one of the best steps to like. Have a reasonable security. Design principles and development practices and vulnerability. Disclosure and management. And I even remember there was another blurb saying. We recommend the CNCF to develop some budget for. UX UI designers to help with the. Front end or like the user interaction with a total. like if that's something that we can start working with. Yeah I think that would be a good starting point. Great sounds like there's a course of action there. Awesome. Any any other updates before we get into our guest talk? Anyone who wants to raise their hand? Without further ado today with us we have Eva Black. Eva you understand you work at Microsoft and you're also part of the outreach community for the Confidential Computing Consortium. You're involved in Open NCLAF. You've been doing a lot of work around TEs and the motivation for being here today is really about increasing awareness, comparing notes between similar efforts within the CNCF, seeing what people are coming across, and hopefully finding how to best collaborate where there's an intersection of TE enabling projects. Is that fair? Pretty close yeah. Shall I start with a little intro to what Confidential Computing is? Is everyone already familiar with the the concept? I think you should probably try it. I think it's not everyone especially not everyone on the recording. Great so the idea Confidential Computing is to extend protections around privacy, data confidentiality, and data integrity from when data is in transit SSL TLS data at rest now to do those same functions for data in use. So encrypted memory while applications are in use. There's different approaches to this. Folks have been building over the past several years, homomorphic encryption, differential privacy, both of those are software based. This one is hardware based and so each of the CPU vendors Intel ARM AMD and potentially more as well I think the power series risk series also have some enable encryption of memory pages and keep the entire application encrypted the decryption key is either in hardware or not even on that machine that they could be delegated temporarily to enable this workload to be run and then attested to where exactly it's running I'm not going to jump into the the how and also the how varies from architecture to architecture and cloud platform to cloud platform. I put a link in the meeting agenda doc and I'll drop it in the zoom chat as well. The CCC outreach committee produced a white paper that's its high level designed just for general education for folks new to the concept it's a great starting point. Our technical advisory committee is working on a much more technical paper right now while still being neutral and high level because each of the member companies and projects do do this differently in my context as Andre pointed out for me joining the call today is I've had a couple conversations with folks in different cncf projects saying yeah we'd like to use this these chipsets this hard breakability to do things like mutually attested TLS or containers which are fully encrypted or container image format that is encrypted and can only be decrypted in specific locations using attestation with third-party verified ability and I'm kind of throwing word soup a little bit here because right now it does feel a little bit like word soup different projects are using or overloading terms and the even within the member companies in the CCC I'm seeing a little bit of overuse of terms and I don't know what's happening in the cncf landscape yet other than folks are like hey mutually attested TLS using SGX we should do that okay well hang on let's all get together and try to make sure first we're using common terminology and then if possible that we're not duplicating work too much in our open source projects because we do have two foundations both under the LF working in somewhat overlapping spaces we've got now I think nine open source projects in the CCC that all do stuff around using hardware enclaves are there common ways we can surface up those open source projects into cncf projects that want to use those capabilities and so my questioning began just with kubernetes steering committee and sick security like hey does it fit here they said well this looks like a cncf level discussion should happen and I ended up routed to all of you and so that is the context and I would love to just sort of have a free form discussion for a bit my my goal being figure out how best to address the these challenges common terminology and common use of open source projects across multiple foundations you mentioned I think you said seven or nine projects under ccc could you list what some of those are we make sure open enclave sdk nrx from red hat graphene and research projects um gosh you're challenging my memory not all of them have have gone through the full legal process yet some of them are still like a good sample the tack has approved but legal hasn't been done so the website isn't updated yet um yeah cool yeah there there are a few like related projects uh at least from from my vantage point and then let others chime in but certainly spiffy inspire get roped in with the desire to attest based off hardware would have crossed properties and how can we do tpm at the station and then t at the station so there is there's some nascent work there there are uh emerging projects well they're actually on a bit far down a good road like parsec i know justin cormac is involved in in that project which is a platform to provide a identity-based crypto operations at the edge providing segmentation well edge is one of the use cases but it has many different applications and it's an api for that abstracts hard words root of trusted that can abstract nature sam or a tpm and it provides you this wire protocol that has been an attested channel to do this descriptive operations but there's several certainly many others um you know i'll open it up to whoever has like comments or feedback on on what you've said thus far um on the double by head uh i can think of two projects one of them is definitely in total part of a feature work that we want to do is to use uh hardware roots of trust to authenticate functionaries within the chain uh that's been something we're we've been trying to make happen for a while but i don't think we have the building blocks uh software layer that's that's why when we're looking at the open enclave sdk and hopefully the ccc can come make like all the tpm stack a little bit more manageable uh i would really love that another one that i was thinking about for the same purpose and that's now sandbox in the ccf is key lime which i i wonder if you had a chance to talk with them uh key lime uses uh tpm and the the limits kernel ima capability to essentially authenticate states of hosts that are operating it uses mr boot and like a bunch of little building blocks and to make sure that everything is within a consistent state uh i wonder if there's like a possibility to collaborate and uh like between the ccg and the key lime project so i just pulled it up it looks like key lime is focused on measured boot or trusted boot rather than um what we would call confidential computing right so yeah i'd like to kind of ask a question also that that's kind of like a conflation of features with that right because i i think there is some common ground with confidential computing and um every other thing that builds on top of uh some kind of hardware with a trust of some hardware models um and kind of i think the main block usually relates to attestation um may i briefly share my screen i think it may help yep this is how we're modeling the conflation of terminology or overlapping domains and that what the consortium is focused on is the smallest circle in the bottom left which is programmable okay so this is like library or a technique like graphene yes that is a type of example of of the resultant software that fits in this domain we're trying not to address the whole space and there's a lot more above that in the privacy preserving computation that we're not addressing at all and there's a pretty strong overlap with tpms and trusted boot and measured boot through the use of hardware te is that is non overlapping with what the ccc is focused on in our work as a foundation so i have a question regarding that uh i assume that to make a this little circle in the bottom left you are also working a lot on having the building blocks that are necessary and i wonder if in that sense uh there's a way for the for security in cmcf to understand what things that are not like immediately interesting for you uh but may benefit both communities if we tackle it together i'm thinking for example the open enclave as k kind of feel like it falls on a broader circle or at least it can pour into other elements for example how so well uh the open enclave sdk allows you to build a arbitrary trusted execution environment which i feel was is was the bigger circle on the open enclave sdk allows you to utilize a hardware te to build an application right i could be wrong again i don't want to put words in your mouth but uh my understanding is what it was an abstraction layer that allows you to use multiple vendor specific technologies to build anklets it is a hard it is an abstraction layer that allows you to use multiple vendors hardware te is to build applications and that the terminology like i said is overloaded but the open enclave sdk does not let you build a trusted execution environment so it's you build an application that leverages a trusted execution environment to perform some work okay i i'm having a little bit of issue seeing the distinction but i i i that's probably um i could say uh graphene or alkaline or alkaline's an interesting example because it's rust based there's some parts in there that you build an application you run that application somewhere that application runs through a hardware te inside encrypted memory pages and then you do need functions like attestation key signing key release policy management that at this time the open source projects don't have a lot of the orchestration around that but some like fortanix edp or and junna both commercial products edgeless also has one that integrates with kubernetes to do key management and orchestration to do the key release policies so that when your application want it is being run by kubernetes in a hardware enclave to actually launch it you have to release decrypted and something has to coordinate where that decryption happens if it's allowed to be decrypted and run on this machine or not that yes there's certainly shareable libraries i think that could emerge from this of like how do we do the key release and the key management so i'm aware of several projects that are kind of dip the toes a little bit in this but not really go as far into it just because um there isn't really quite a established way to do things today um i know you know this is something that kata container so i think sick runtime would also be a good place to talk about this um i think the parts for example with enox especially um there's a lot of talk about web assembly going around in sick runtime that could be a interesting place i know container the um recently provided ways to manage a snapshot separately within a different environment not necessarily tied to the the the host operating system um so there's this discussion in kata containers where we're talking about um so recently we developed encrypted containers um you know how do we run the vm such that everything we did the vm would be um confidential so this is if it's using for example amd scv mgt me and stuff like that um and the the whole part of the discussion was okay now um if we wanted to be truly confidential we had to handle the distribution as well within um the enclave or the encrypted memory and so we had to kind of take parts of the ecosystem and also put that within the enclaves which i think was the difficult part of it um so i'm kind of trying to think about from a community standpoint what we can do the first thing that comes to mind is you know just getting in touch with the the groups of people that would be interested in it um i think that's uh that would be something um we could see where the sick runtime has also interesting uh any any channels that would be interested there um in terms of education i think there is a level of something that we can do about it and i think that you know it it may be a good um maybe project for security if there's interest that's built around it um and last thing i can think of is i haven't taken a look at the list of projects but um you know if cncf if these are projects which may benefit from being in cncf but then that's kind of question about you know what's the gain of being pilot cncf versus ccc yeah i don't want to get into a competing linux foundation projects with each other right but rather collaborating so i don't really want to um certainly not projects that have already applied to join the ccc and are accepted there i'd rather look at how do we communicate across these foundations and support projects in each of their homes um i would love to better understand which cncf projects want to use uh hardware-based tees whether it's for key signing or um you know running the container in an enclave what however they want to leverage this type of hardware i think if we can um sort of surface up what scenarios or paradigms emerge that'll help both help shape the projects that are still in their early phases coming out of research and entering into being productized and help shape the answer to your question brand and of which which foundation is the right home for which projects yep and i actually i think that i'm not sure that emily whether the white paper section landscape would be you know once that's i know it's like almost completed but once that's done we can kind of have this discussion around that as well sounds okay i think there's definitely room and the white paper in the landscape to touch on a little bit of that for sure uh and its current state probably a bit late for updates but once post-cube on the break though certainly add an update cool i also have the question on my mind of is uh cncf 6 security the best place for that work to happen where's this like as i read your charter it seems close to but not necessarily within the current sig charter and i'm new here so i don't know and i wanted to ask the question my take on the set we are we here to foster the collaboration um i don't think we are looking to do um technical projects that come up bit um more like we can help form the groups from the discussions i know um there are already several several people on this call i know they are already interested in this um so i don't think we would be doing the technical work but we can help you know get the right people to get there and kind of also communicate um some of these discussions as well it's i would say it's the starting point uh sorry i'm gonna go ahead but i'll just want to we're happy to avail ourselves to facilitate connections to the respective projects of interest and the right groups go ahead emily you were gonna say i was just going to say that for sure we can definitely help facilitate making sure that you get the right points of contact and maybe help like move that forward we also have the mailing list which has a ton of folks on it so you're more than welcome to write something often send it out to the mailing list to help facilitate some more attention on the on this particular topic thank you yeah i would also create an issue as well this is a good channel um kind of create a suggestion and then usually we have a couple people just chime in on it so you had talked about one set of example applications i wonder if and that might have turned the light bulb for some i wonder if you can talk about other use cases you're encountering or perhaps water some unsolved challenges for some of the nascent projects in ccc that may be areas of interest for folks to jump in and contribute what is stuff of mine what is like desirable but like not necessarily near term and you're like looking to well we could really foster rally people collaborate be it like just problems within the boundary with tea or like across te boundaries one of the areas and i'm looking at this not i'm interpreting your question not as what challenges are the ccc projects trying to solve but where are they running into things that relate to the cncf and orchestration at scale of key release is one of them another is image formats um just and this might be a little bit directed towards you i think around projects that launch containers in enclaves taking novel approaches to how they encrypt and sign those container images and i think oci just did a um specification on how to do took a position on how one should do encrypted container images and i'd love to help facilitate that collaboration so that people aren't reinventing the wheel yeah no definitely i think that um yeah i see i i see i as a good place and obviously both me and brandon are involved there yeah interest is working on that i think that um um there's i mean there's a lot of work kind of planned i'd say at the stage when the for oci format change i think there's a lot of use cases that are not encompassed by the current formats and there's a lot of um discussion as to what things we need going forward yeah and i i think we can also bring uh a couple other folks um from oci as well on this right just then maybe phil uh alexia someone oh vinson i'm curious on uh has there been any benchmark study done as far as the what's the computing cost for this uh confidential computing especially when the processing side of it when you're doing the encrypted data and trying to process that and decrypt it and and process it and then encrypt it back and so forth what are the typical penalties or what are the typical computing costs it yes some benchmarks have been done um the results vary wildly by a cpu vendor by um software architecture and by use case so an example of where the cost can vary hugely is um sgx does not support fork internally and so some projects implement fork by jumping out to the host and starting up a new sgx process and the page swapping for that entering and exiting the enclave can be very very costly depending on how you implement it or less costly depending on how you implement it and so the benchmarks end up being well on this chipset these two projects in this scenario have a 10 times different performance profile isn't that wild 10 times uh some of the some of the use cases we see there's a 10 percent overhead and some of the scenarios we see have a hundred uh uh thousand percent overhead there again i can do my math considering whatever you have seen in terms of the fastest hardware or most uh most intensive hardware implementation of this confidential computing would you put that into the category of the 10 percent overhead the low that's the low end right penalty i would also say that all of the cpu vendors are rapidly advancing this and coming out with new capabilities i would expect those to have far less overhead than the previous generation i'm kind of curious on that is there any uh work towards standardization of the interfaces there at the cpu layer yeah at least like what um how should you communicate to on-clays what is expected out of the interfaces i know sgx has uh all the implementations are different they do key management in different ways some of the do key management hardware some of them do it outside so then can do interrupts on that kind so yeah um what i see across the cpu or the chip vendor space is sgx is kind of a novelty everybody else has taken a different approach they're working mostly at the hypervisor interface layer when i look at amd sev or sev smp when i look at uh intel tdx not released yet but announced in the plans and when i look at um ibm's uh pef and they all take a similar those three take a very similar approach trust zone and opti is a bit different and then sgx is completely by itself in in its interface and so what i'm anticipating is uh over time we'll see the layer above all of these where the common abstraction forms right it's not going to happen in hard work because the real hardware is going to be different it might happen at the um at the the sdk level of like a c sdk interact with the hardware it will probably also happen at the orchestration layer how do you launch a process or a vm into an enclave and that's where i think the real work happens between the ccc and the cncf like people whether they're launching vm's or they're launching containers or they're launching function as a service like however they're launching it they're going to need to perform actions like attestation encryption signing and that should be consistent across projects and across cloud service providers in my opinion i think yeah so i think you mentioned an interesting point there on the sdk so i'm curious because uh different workloads require different types of securities right so you should be able to selectively choose where you really want the most rigorous uh confidential computing workload versus this so if you consider for example different microservices um and some of the microservices might be running in very high confidential computing um environment as opposed to the others which might not require that so this does this sdk provide that kind of flexibility to orchestrate your workloads to be clear i was not speaking of any specific existing project i was making general statements about what i think things will do in the future okay but this is well taken that yes but this is part of the consideration i suppose in those okay exactly i i do believe that um i completely agree with your point that different workloads will have different security requirements some will want a very small tcb and very fine-grain very careful nuanced control over the code running in it and how it is launched and some uh consumers may want to just take a whole vm take their existing you know um erp app and run it in a confidential vm i might not want to but somebody probably will okay i want to chime in with a couple of those i think that the idea of uh thinking or looking on all this communication uh problems through use cases would definitely be helpful so i can say that we are looking into this from an integration perspective and bringing hardware root of trust to and do basically building with sph inspire the identities that's good like unified identities that could be used to cross all the system and bringing hardware root of trust to it right so uh there are different layers for it and like you can look into sph inspire from one attestation perspective but we are looking into it from another attestation perspective how we do an attestation of a hardware and making sure that's uh agents where they run in can have another uh another key and and basically using another infrastructure that we can use for another layer of attestation so uh i i kind of feel that understanding of for their possible or main use case in it and identifying projects in the sector system would be definitely helpful because it's it's all unstructured knowledge at this point that that would definitely help to understand who is working on what and how we all collaborate more and better completely agree i've uh been thinking of this within the ccc as trying to define the on ramps how would a developer engage with this layer of securing their application and defining the use cases from that perspective there are other perspectives as well but that is i think the next step that we all need to do is define those use cases and how people are approaching it eva's part of that on ramp event well for for the folks on like behind projects in the call today as well as like end users like elie beyond the the white paper like starting that what would be like the next steps you would point folks towards i don't know if there is a yeah i don't have a specific next step part of my goal in asking and coming here today was to determine whether cncf uh sick security is the right place to continue these discussions um or or not and i that question just came from talking to folks who're like yep that's a great conversation i'm not sure where it should happen so my question is to all of you um should this become a working group or something within the SIG or a regular part of your meetings or should we create a separate thing to have these conversations and work on these use cases within the cncf scope because i'm also having the same kind of conversations more broadly in the ccc which also includes non-cloud native scenarios so i hear from what you're saying there's there's no defined space for people to get together within the realm of that's so there's no question you don't want to have like ad hoc hey come to me after if you want to jump in or contribute like brandon i'll pass it on to you yeah i i just um i think that creating an issue would be a good first step um at least you'll see that it seems like there are there is interest for individuals from chat that can see so um if there is enough of a group that wants to go around this and there is a defined um effort that can come out of this like for example you know so like in the use cases like like i mentioned then um we could have it as a project proposal and one of if a co-chair signs up offer that it could be something like um you know what Santiago did with the supply chain documentation kind of just like it's a it's a primer on what is confidential computing a couple projects and here to some of the use cases so we do have that um by the way i dropped a couple links i should have asked everyone to go read them the outreach committee created a white paper that does outline the use cases for confidential computing it's just not specific to the cnca right okay so i think definitely creating the issue first it should be the the very immediate thing that happens and then probably uh drafting a notification to be able to existing security mailing list with the link to the issue to help solicit some some interest in the area and then depending on what the activity on the issue is and then the next steps that come come out of it we can certainly look at doing a working group and adding something more concrete to the refill the very least to help provide some more documentation specifically about confidential computing for cognitive architectures and workloads we should probably cross-pace to seek runtime at ACI as well as they're the probably the strongest other groups that would be interested yeah that's a good idea i will will tag the the the various people in the issue once it's created Justin you said sick runtime and what other sick well i see i which is another alaf organization but got it a possible outcome of this would be that you know the conversations between oci and cncf could end up in a working group under the ccc as well yeah i feel there are like so many uh different pieces in different groups so there might be a need to like have six ccc or something like this like uh we definitely have some projects in here that's been mentioned like spiff is prior ran in total like a couple of them for sure and and maybe others but they're definitely bigger scope and landscapes for for integration with the hyper risers and functions and a bunch of other stuff for sure so yeah i guess feature creep happens at the cncf level i think and in total in a sense for example of course beyond cloud native but it's if i'm suffering at home here mostly because the community is very welcoming and there's a lot of interested innovation and the solving problem solving so i wouldn't be surprised that people are also willing to hear about the use cases that go beyond containers and orchestration i suppose regardless of where this happens i believe it might be useful to think of of utilizing some sort of an api type based optional capability from the cncf project to whatever being developed in the uh confidential computing so it can be optionally used for different workloads or different purposes so standard api is maybe a very useful thing for depending on the use case and depending on the application because it's a application i think goes beyond the just the cloud it definitely goes into the edge environment as well so yeah there's a lot of 5g conversations around around confidential and trusted computing exactly so for next steps how about i continue to come to this meeting since it seems like we're going to create an issue and we can track the work there for now um and i'm having a conversation you know very much related to this in the ccc tack which meets every two weeks mostly at the moment that is between myself and uh mike bercel is my my um here on the nrx project and i'm on the open on cliff project and so the two of us are trying to sort this out as the two most mature projects in the ccc right now um folks are welcome to join yeah i'm happy to help these use cases a few folks will plan to uh work on this at least on a high level and might be per project sort of things we have been uh touching uh with or playing ways to see how it fit into the whole infrastructure the whole idea okay seems this is a good step in the in the right direction just to break walls and create a communications channel and use a liaison between the two groups for people to know what's being developed and worked by the different projects and the different foundations and we can as you said not duplicate effort and work towards common goals and through that just enrich the ecosystem there's certainly like desire to for you find consumers of open on clave and clearly we've we've identified a few that we can like help like expand the footprint but also take advantage of the benefits it provides uh and i'm sure others will arise but yet near-term like certainly in toto spire for using while solving the distribution of keys there's certainly also a consumption aspect we can surface back throughout the station i wonder if projects like opa well initially that were intended to be able to enforce rules and regulations that a layer of the stack if it's something that that could be done there i see we have ash on the call um maybe an area to explore andre i think you've given me something else to think about could we create a sort of a list of cncf projects that are surfacing up this kind of functionality i think that having that list would be helpful to track and organize interest in conversations around it for sure i'm happy to take that action item and provide that list to start out at least the initial ones that have arised and i'll open it up to others to add in cool cool i don't know if anything else anyone wants to share jay jay sorry i joined uh i joined a little late nothing much from me i know aradhana was supposed to present i don't know if it happened otherwise i think depending on her time maybe we should see if we can have have her presentation scheduled for next week or week after yeah next week next week we'll be better that yeah let me talk to the next week we have a key line presentation let me ask him how long that he needs for it which is also relevant to what we talked about today yeah for that decision portion so let me have a chat with him see how long he needs aradhana how long do you need for your your thought i can adjust time um i mean whatever time you can give me um it's just for you know sharing and bi i um i can send a link to the paper and you guys can read the draft not a problem thank you okay random you've become a great fan of mirror boards i wonder if we should start a mirror board for this we should we should start a second just from your robots i didn't know nothing from me no update from me cool uh steven cameron anyone else no no hope for me um i think you guys i think it's i think this is really positive really like the the work together concept here from the ccc i think that's just absolutely awesome yeah 100 percent agreed well uh iva thank you very very much uh looking forward to seeing you and upcoming calls and working together i will yield my time back to the chairs emily i think that's everything for today anything else nope i think we're good thank you thanks everyone thank you okay thank you there's there's the zoom option to download the comment history right yeah you can you can save it i saved it the last one i can let's say i don't want to catch it when we get idea to dump that in the meeting notes yeah i we're we're working on something too so this is downloadable if you log into the cncf um account but we still don't have a way to to do that efficiently yet yeah hey santiago while i see you here there's been a lot of interest and demand to see a upstream integration between and toto inspire be it for protecting the toto machinery and at the same time well for the supply chain log to be used as at the station criteria for like binaries of known provenance to be issued identities i i wrote to justin about it that would have been meaning to reach out to you still on our list but probably be setting up the time so we can riff a little bit over that yeah it sounds very interesting i'd be interested in knowing because i know there's at least it makes me think of a supply chain transparency uh in a sense and i think that's something that's coming up soon in other communities as well so i wonder if we can make something happen uh the new feature the the request originated from the dod from their chief software officer directly said like hey like there's there's interest far and wide within the dod with what we're doing with cncf for both projects but this is like the most desirable integration what we'd really like to see come together i i think i've got your contact or i'll just get it from from slack did you end up moving to tucson no i i'm now in lafayette in indiana i ended up at british university oh congrats thank you that's yeah it was a tough decision between the diversity of our zone and british university but but i'm i'm happy with the decision i made let's see how it turns out either way you would have made the right call right can't go wrong yeah but both uh that's an issue you have to make a call if i could split myself and in both places i think that would have been out of all of it it is what it is curiole food has a little bit more flavor than southwestern which is also very tasty but well this is in indiana it's uh midwest oh not like i yet uh louisiana but indiana oh gotcha okay yeah so well yeah the food is not as great as southwestern but uh well um yeah i'll find charm in the in the indiana i think so far i've been liking it a lot it's uh not so different from new york in some respect so so that's that um but yeah awesome yeah santiago you got to send us a picture of your guitar i see the the case oh i can probably it is open it's a prsc 24 uh the the 2008 model uh the i think it's a dragon two pickups i forgot oh pretty cool i really like it awesome well uh nice to catch up and i'll see you guys next week yeah good to see you chat soon yes bye bye take care


I'm here to produce the speaker, Amy-Marie, and she's doing a presentation on Firefox OS and its uses for Linux. Okay, I have a small disclaimer to put, and I'm really sorry Dietrich and the Firefox guys, because I've got a capital F in Firefox and there shouldn't be, but oh well. So just to let you guys know that. Thank you all for coming. Basically, what I want to just give a little bit of chat about is the architecture in Firefox OS and looking at its use of the kernel and how packets, et cetera, get passed up through it and back down. And a little bit on where our code base lives and how you can contribute and stuff, but a little bit less on that. To give you a quick introduction, my name is Amy-Marie Forstrum. I've been using, I used Slackware when I was a kid, but I really think my first use of Linux was probably with Debian Potato. I've contributed to various OSS web projects. A lot of things that I do is mentor children with Python and Scratch. And I've contributed to Mego and QT, which led me to the Firefox OS trail. And recently I was doing some stuff with Mozilla on the Firefox OS support team. So now this is going to be interesting because I've got two, sorry. So what is Firefox OS? Well, by now you've probably heard about Firefox OS. All right, I'll just leave that there. By now you've probably heard about Firefox OS. It's been out in the wild for just probably about over a year and a half coming into two years. First started life as the B2G project, aka B2Gecko. It's still referred to B2G in GitHub. It's Mozilla's attempt at entering the mobile platform area. It is aimed at lower-end smartphones. But this is not a limiting factor. It doesn't mean that you can't roll it onto your Nexus 5 or Nexus 4 or put it in higher-end phones. It is built with web standards. And a big thing, open web standards, and a huge difference about the Firefox OS approach is that there is a marketplace, but you don't have to put your apps on the marketplace. You can host your apps on your own GitHub. You can host them on your own website, and people can download them and use it from that. So you're not restricted into the marketplace model that Apple and the Microsoft restrict you into. So let's just jump into the actual... Layers, this is going to be a bit tricky because I'm kind of losing my pointer. Okay, sorry. All right, so basically what we're looking at here is what I like to call the 3Gs. And then under those layers we have the actual mobile device itself. So at the top you've got Gaia, Gecko, and then GONK. GONK is your Linux kernel. Gecko is Gecko. And Gaia is where your applications are sitting and running. From a security perspective, each layer, each application runs in its own sandboxed environment within Gaia, but we will actually go through and have a look at that deeper. What's that? Yeah, I'm on two different screens. Sorry. My speaker knows it's got to be corrupted. So basically Gaia is your interface application for Firefox OS. It comes with the standard stack of applications, phone caller, messaging apps, contacts, calendar, etc. When you roll your own Firefox Gaia, we'll include the basic stack of common applications in it as well. So you'll have your basic marketplace and etc. And Gaia communicates to GONK through the Gecko layer. So what is Gecko? Hey, sorry, all right, I'm going to work this out in a second now, I've got it, cool. So at the top we have, Gecko holds basically all out where our web APIs are running from. So Gecko is the application runtime of Firefox OS and implements the standards for HTML, CSS, and JS. Gecko is considered the middleware code, which is comprised among others of a networking stack, your graphic stack, the layout engine, and the virtual machine for running the JavaScript code. So GONK is a Linux kernel. It holds the device drivers. It holds a howl. It's isolated from Gaia, communicates through Gecko and BTG, and you could kind of call it, in a sense, a magic black box. It's isolated from the higher levels and it's all communicating through web APIs. So it's a core component that is adapted for differing chipsets as well, and we'll go into this a little bit more. So each device that you're going to have is going to really pretty much have its own version of GONK rolled onto it. So let's take a little bit of a deeper dive into it. So we're looking at some of the components in the GONK layer. What we can see is we've got the radio interface layer, the RIL, which interacts with the modem hardware in the phone. This consists of two components. So you've got the daemon and then you've also got the proxy. The proxy message is between the daemon and the BTG process. There is a media server in there which controls audio and video playback. Gecko communicates to the media server through the Android RPC mechanism and also a NetD process, aka the networking daemon, which then talks to the networking stack. Bluetooth and other service-level daemons providing access to the hardware capabilities. These are pretty much your common modules, but obviously there's going to be a lot more in there. The Linux kernel distro also utilizes libraries from Android, the GPS camera and some other open-source projects. LibUSB, BlueZ, et cetera, to name some through. And then we have the firmware and drivers at the lowest level. Now, how GONK handles a request? I think, cool. So as we discussed, Gaia speaks to Gecko. A single request from Gecko can trigger a complex series of operations initiated and managed by GONK and the device. In this example, what we're seeing here is a radio interface layer in GONK responsible for controlling the modem hardware that will dial through the requested number onto the radio interface daemon itself. The B2G process then communicates the dial request through the proxy, which forwards this onto the service-level daemon. The daemon controls the actual modem hardware and via the Linux kernel and any associated modem firmware, drivers and devices. The RLD sets up the modem and causes it to dial the number and any changes in the modem state, aka ringing, dialing, stopping the call, canceling, hanging up and then reported through the B2G process through the stack. So if we take a little bit more of a look into how they actually communicate. All right, so here we're actually looking at the full stack of layers. So as mentioned, Gaia is where the application will live. The app communicates to Gecko through the execution environment which in turn talks to the permissions manager, who is only able to access the web APIs to the underlying hardware. So it checks through the ACL, so you've got your access control list. It checks that you actually have the permissions of what credentials you're running, pass it through the web API, to the IR hardware, to the B2Gecko and then down into the GONK. GONK communicates to device. Now, the reason that you're looking at these all separate is because they really are separate layers in the sense that you're not going to ever get GONK going straight into Gaia. It does have to go through this full process. All right, so let's look at the how. So within GONK, it's a hardware abstraction layer. Now, this is one of the, called the porting layers of Gecko. It's C++ API. This hardware abstraction layer is not exposed directly to JavaScript, code into the Gecko for obvious security reasons. The sandbox implementation simply poxies requests by content process them and then forwards them onto the Gecko server process. The proxy requests are sent using the IPDL, which we will discuss later. So if we jump into having a look at our in-it process. So in-it process is basically stock Android. So the in-it RC is basically stock Android with patches to include things that are required to kickstart the Firefox OS. So they're very specific to Firefox OS. Therefore, device to device is going to really depend on the needs of the actual device. After the in-it process is running in GONK, handles... Sorry. Handles mounting required file, systems and spawn system services. After in-it is ran, a user space in-it process is launched. Once the in-it process is launched, the kernel handler system calls from the user space and interrupts from the hardware. After that, it stays around to serve as a process manager, which is very similar to other Unix-like operating systems in that sense. So the in-it D that you're seeing there So we have a look a little bit into the bootstrap. So execution always begins with the primary bootloader. From there, a succession of increasingly high-level bootloaders are called. The general system boot-up flow goes from the bootloaders in the kernel space to the in-it in-it native code to the B2G. It then spawns the system window manager and then executes the home screen. All your applications then run within the home screen as well there. So they're isolated there. When that runs, this process goes through, home screen is called, and that's the process that your apps are executed on top of. So I mentioned before, IPDL, and if you're not if you haven't kind of developed with iFox any on Mozilla, you might not be fully aware of it. It's the inter-process communication protocol definition language. It was developed by Mozilla and C++ code, and it's basically a way to pass secure processes and threads in a secure way. So app all apps communicate with the service-level daemons via the IPC. So now if we jump in and have a look into the IPC architecture. So in iFox OS, we have a multi-process architecture. As it means that each app is actually run in its own process. As you can see, there's a single parent process called B2G. The parent process spawns newer, which is the child, and newer then spawns the apps. As I mentioned, the default child process run with the most minimal set of privileges. So B2G parent has the higher privileges, it executes newer, newer then runs down to the apps, and that's where you're having those levels of permissions. When higher privileges are needed, you're going back up through to the B2G process and then back down to see if those are allowed to behave. Hopefully some of this is making a bit of sense. I'll pull it together in a minute. So IPC parent child relationships. So if you're familiar with using Unix sockets, then this system will not seem unfamiliar to you. iFox OS uses Unix sockets created with the socket pair system to call and send messages. The system calls send message and receive message each time. Each process has its own dedicated thread and handles that socket operations. This is called an IO loop. Each IO loop thread has a sound outgoing message queue. As you can see from there, all IPDL messages are sent between the parent and child endpoints, aka actors. An IPDL protocol declares how the app does communicate, and it declares the possible messages that may be sent in a state machine describing what messages are allowed to be sent back. So as we said before, the apps really only access via web APIs. Gecko is a sole gateway to the mobile device. So there's no native API, no backdoors, and the apps all run as we saw before in a sandbox mode. So this means that Gecko really does provide that sole gateway. So this kind of jumps us into looking into some sandboxing and the security. So we can see from this diagram that sandboxes use IPC to trust as a trust boundary for communications to the parent process. Each app, aka a child process, communicates to the parent process using the trust boundary. Fly Fox OS. And this is similar, so this parent process and how this trust boundary is happening with the IPDL, IPC and the sandboxing is similar, exactly the same as how Fly Fox OS runs on Linux. Sorry, Fly Fox desktop browser runs on Linux. Alright, so now we've kind of had our heads down to the bunch of things. Let's jump back into our layers again. So as we can see, the Gecko parent-child relationship is started at the higher levels. And note the communication to the lower levels need to go through the permissions manager to gain access to the lower levels in the Gecko layer. Like, hopefully not boring everybody. So what parts of the kernel? So, and I've got ace up wrong there, sorry. So basically it's pretty much an Android kernel. So it's got the users, as we said before, it's using Android libraries, it's got the GPS, it's using camera, etc. But it's also got an extra bunch of components in it. These changes are not upstreamed to the Android project, they're unique to the Fly Fox OS project. It is a very basic Linux kernel and it's, as I said, it's not the full Android, so it's done so as well to really provide a smaller memory footprint. Which is really important when you're running low-end devices, $25, $35 devices. So what is GONK in a sense, it's basically what we call our porting layer of GECO. GECO is full control over GONK, difference in the exposures of the interfaces. And that in saying that that there is a port of GECO to GONK just like there is a port of GECO to OSX as there is a port of GECO to Windows in the Firefox browser code. Since the Firefox OS project has full control over GONK, we expose interfaces to GONK to GECO that cannot be exposed on other systems and an example of this is the telephony stack. Obviously if you're running Firefox browser you don't need access to a telephony stack so where is in a mobile phone you do. So it's slightly different in that sense as to how the browser executes it. So GONK is covering under the Mozilla public license. Being mobile devices it also contains proprietary drivers as well. Vendors can modify the kernel. They can upstream if they choose. OEMs will also create as we said device drivers firmware and etc which will not be upstreamed they will be specific to the telecom provider, the device manufacturer. So implementing changes in GONK. So as we discussed certain aspects of the Firefox OS architecture and also certain components of GONK we could take a look at the process when people and companies need to make changes to GONK. When specific functionalities are required in GONK it needs to be added by the OEM the company, the human akaU. This means that GONK will need to be extended and the how files modified to expose new functionality to access device specific requirements. An important part of this process is what we went through before which is the IPC, the IPDL because that will need to be designed for when you're actually adding new changes in there. Integrating it into GECO. It shows how to have functionality not currently accessible via web APIs in GECO. So there's a particular thing that you want to get into there. So first you expose the functionality in GONK that's when you modify the GECO source to extend the web APIs. So you're adding those drivers sets and what you need into GONK itself but then you actually have to extend GECO to have those web APIs to be able to talk up through GAIA. Now I'm not really going to talk too much about licensing issues because it's not really a licensing talk but as we said there's proprietary code in there. OEMs must sign licensing agreements with the component suppliers. There's proprietary code in it which is unfortunately something you can't get away from when you're dealing with mobile phones but who is actually responsible for the GONK? So Mozilla is responsible for the GONK due to this Mozilla maintains the source repositories and any needed support files. It is maintained under as we said before the public license. Therefore you can fork it, you can clone it and you can do what you like to it. The upstream process is not as straightforward as one would like it to be though and this is due to the fact that there are also a lot of third party components and etc that cannot be included in the Mozilla repos. As with Android it is at the discretion of Mozilla if they wish to take up your code so it's not that you can't upstream things back to them. You can contact release managers and you can speak to them but it's not the simplest upstream process. So as we said it's pretty tricky to navigate the land of mobiles because of chipsets. So third parties in GONK you know really it's ensuring that, you've got to be really ensuring that seamless communication between GONK and the Gaia levels which is where you're looking at the IPDL and the IPC. So really in a sense falls to third parties to maintain their own stack. Brings us into the question of blockers. So your upstream process is not guaranteed there is proprietary drivers that will never see the light of the upstream which means that fragmentation starts to occur. Each LEM device or in a person can maintain their own fork or Firefox OS. So and fragmentation is a huge problem. It's a huge problem in the Android world. It's also becoming a really big problem in the Firefox OS world. So you're looking at probably about 60% of devices out there. At the last time I checked which was about four months ago that is still running 1.1 Mozilla itself is working on three. So to give you an idea 1.1 doesn't have copy and paste. So unfortunately it starts to become a bit of a thing where yes okay I've got my CT MoviStar device but MoviStar is only pushing 1.1 and it will be the discretion of MoviStar if they actually want to push down three. Mozilla is working with the Telcoms guys to get around that process and to look at ways of kind of alleviating a little bit of that. It's not the simplest thing. So which is what we said always limitations. The interesting thing about the Mozilla project is so if you're looking at Firefox OS if you look at Android I'm just taking a stab here but I'm going to say there's probably a good couple of hundred people probably thousands working on the support of that device. We had a team of six of us that were providing support and we had an army of volunteers. So it can be hard to provide support. It's really hard when you've got 60% of the people out there on a 1.1 and the problems that they're talking about have already been fixed in the newer versions there's not really too much you can do for them at that level. So it's frustrating. It's really frustrating because if you think of the end user who isn't necessarily technical they've got their phone, they're running 1.3 their friends got their device, they're running 3 their friend can copy and paste they can't they've got a better type interface than their friends I guess that's kind of where the frustration comes it but in saying that that's no difference to what happens in the Android marketplace as well. One thing and a really cool thing that you can do is you can make it what you want to, right? So it actually isn't too hard to flash a device. There is a lot of support and a lot of information out there that would tell you how to flash your own device. So if you do have 1.1 you can get onto the repose and upgrade that and flash that so as you said it's based on the Android kernel which is hopefully going to make it easier to support to existing device drivers firmware, service teams and other components supported device list can be found in the repo the B2G slash config.sh it's pretty much where all the list of devices there and if yours isn't there you can go in and add it yourself and you can add the drivers and etc you need. A great example of that is the APC project and I'll show you a little APC soon. How to contribute so everything is kept in Github so you can go into Github, you can fork it you can download it, you can contribute into it if you go into gong-misk it's pretty much the best place to go if you want to look specifically at gongfars cool toys and future projects so Mozilla is very heavily invested into Firefox OS so recently last year they said it partnership with Panasonic so Panasonic Smart TVs will be running Firefox OS there's an APC device that I've got there APC itself comes with a version of Firefox OS I've been using that at home as my main media centre there is some bugs and issues with that there's a repo for the APC if you can get on and you squash a bug they will send you an APC device which is pretty cool so more mobile platforms well choice is good being a monopoly is bad for everybody Linux was made from better devices so you know do we need there's always a question do we need another mobile platform yes we do need another mobile platform I'd like to see another 30 mobile platforms I don't see why choice is a bad thing I don't see why we need to have one, two or three if you really are into playing with embedded devices and wanting to have a go I would also tell you to check out the yokto project you can roll your own embedded Linux and you can start to kind of get around and play with the architecture set there Tizen this time I can actually get to say Tizen is going to be releasing Samsung is going to be releasing a Tizen device soon and straight away you're going to be able to run Android apps on the Tizen platform which kind of gets away the need of having a full Tizen marketplace there the other thing about the apps in Firefox OS as well as you can run them on your Android device so you can actually you've got an Android device you can go to the Firefox marketplace and you can run it on there what you will notice when you do that is because of how you're running it and because you're running it in a HTML5 space you're actually not accessing a lot of the permissions so you're bypassing that so your application then doesn't have access to the full stack in your Android phone so if you use Twitter from the Firefox OS marketplace you're not going to be giving it access to that full layer stack that you've got on Android but if you use the Android Twitter app you are so now I've really reached through that a bit quickly and I probably haven't made all the best sense so I'm going to kind of put out for questions I'm going to ask if people want me to explain a little bit more of the architecture go into the IPC a bit more or very very quickly sorry an off topic you mentioned scratch I'm really interested in that where can I catch up with you about that today where if you see me walking come and grab me and ask me would you be around yeah I'll be around but yeah so I want to keep the question to the Firefox OS and in regard to the problem of updating the device and the vendors don't you know update the devices Google has been getting around that by sort of fixing the sort of lower layers and then pushing all of the sort of user visible functionality into packages that they push out and control maybe that would be useful for Firefox OS as I said Mozilla is in I don't like as I said I was doing Firefox OS support and Mozilla the high levels of Mozilla are in communications and working out these things with the telecoms it's really only been around in the world for about a year or so so it's really kind of just picking up speed now and getting greater adoption so I think as you see that greater adoption and as it becomes a more important mobile player as well then you'll probably see the telecoms and that working a lot closer when I think of Mozilla I think about its commitment to work to control user control and such here you've described a platform that's very much based on proprietary drivers and proprietary code and facilitating that kind of setup and that leaves all kinds of pathologies a number of which you listed yourself and we've gotten around these sorts of issues in other markets when vendors insisted on free drivers for the hardware they were supporting why is Mozilla not doing that for Firefox OS and what is being done to get us away from this problem of binary blobs in our free systems? Same problem exists in the Android world right? Same problem exists in the Android world because it comes down to the device manufacturers themselves so there is really now I haven't looked at the full Tizen stack yet but I'm going to guarantee that there's proprietary code in that Tizen stack as well and it's just currently a big problem within the mobile world and a lot of it does come down to those device manufacturers and telecoms so it's a lot more I guess fragmented in that sense I can't speak for what Mozilla is doing personally to get around that because I'm really here to just talk to you and present the architecture it's yeah it's there's really not much I can say about that sorry Getting back to the architecture I hope it's not too an important question just in terms of the gecko and gong layers like gong keeps a lot of Android user space and in gecko things like the permission manager and other kind of abstractions seem very similar to the Android framework so I was wondering like how much of a win was it especially if you're already shipping and maintaining fennec and not able to make large reuse of the work you're doing with fennec and Firefox OS because you're not working to the Android layer like you're not using the functionality of the Android framework for things like IPC which you'd get for free if you kept at least part of the Android framework so I was wondering like how I'm trying to get I'm trying to see the question you're asking so I'm just wondering like how much I guess work goes into maintaining all the extra bits in the gecko layer and then I'm going to go back to Firefox OS which you don't need on other OS's that say fennec doesn't need because Android's framework provides all that so you're basically doubling up what the OS is on your desktop and Android framework only provides in the sense that there's a gecko port for Firefox OS there's a gecko port for your windows browser for your OSS for Linux etc so I'm not sure I'm kind of totally getting out of the mission manager. No and that's where it's different because it needs to be different because on an operating system level and etc you don't want to be accessing those lower level threads you don't need to be accessing that and you want to keep that everything fully away from that so that is where it is different in that sense of yeah it does and can get into the lower levels of that kernel which it's not doing on your operating system because it doesn't need to how hard is it to maintain or how much work goes into it the same way as porting the same way as you know there's a gecko port for windows there's a gecko port for like it's just yeah I think I don't know I didn't design the architecture so from an application developers perspective your code is all running in the JavaScript engine in the browser and so if I was to bundle up an app what's the contents of the app and like other tools in order to assist in building them like what does an application look like to be distributed either via the market or linked to from my web page okay so you're basically when you're writing the app there it's pretty much a html5 javascript css application so it is in a sense you're using full open web stand it's there so it's not like okay I'm developing for android I need to learn andro's codebase iOS I need to learn iOS's codebase et cetera so it's done in the way to lower the entry barriers as well so now all of a sudden all I need to do is equip you with html css and you can write an application that's going to sit on top of that and because you don't have to go through that marketplace as well it means that if I want to make my own to do app I can just quickly write an html5 to do app and push it onto my device so if you're providing a server yes you can exactly so you can run it on your desktop you can run it on a windows surface which actually has html5 so yeah it's not just restricting you to the Firefox OS so as I said right now you can get on your android get into the marketplace and start downloading applications and running them there and you will find the biggest difference you will find is that is the permissions that it's actually accessing in your phone and the other lovely thing that a lot of people love about it is there is an actual option in the operating system to say do not track I don't think any other mobile operating system has another question leading on from this it seems to me that this has the potential to be the perfect universal app platform for any phone like if you write an android app it only works on android you write a firefox OS app it can run on any phone that has firefox the only problem being like you said you lack access to those various APIs like location or I don't know whatever APIs on the phone so my question is are you going to develop firefox for android and for iOS and implement access to all of the phone APIs so that a firefox OS app has sort of equal status running on firefox OS or on android or on iOS so this could become a universal app platform with full access to all of those phone APIs. The awesome and lovely thing about Mozilla and firefox OS is that it's using open web standards so if Apple decides to implement HTML5 then you could run your app on that it's not that I think it's that you've misunderstood it a little bit in the sense that when you said you can't access location and GPS and etc you can and you are you're just accessing it through the gecko layer so it's a little bit different in the sense of and as we said because as I said before if you're wanting to add new things into it that's when you're going into gong you're going into the c++ that howl and you're going into those lower levels of additional things that you need there then you go into gecko and you expose those additional web API calls there so you do have that but as I said it is their HTML5 apps so you can run it across you mentioned for example that the twitter app the firefox OS twitter app running on android would not have the same access to APIs as the native android so what I mean by that is when you're running how does my twitter application need to have access to 25 different areas of my phone if you download a lot of these applications don't need the level of permissions when we're doing mobile app development we've come into this state of ask for every skill permission by default so a lot of android applications will ask you for everything by default not that they need it and it's also a problem when you're in the mobile app development world you're running that by default so it's not that you're not able to talk to the level you don't need to be accessing that you're running it's the same way as if you're in twitter on a web browser it doesn't need to go down and communicate with level levels of your kernel it's running in that user space that's where it needs to run so the user experience running native android twitter versus firefox OS twitter on android is the same user experience is the same you're not lacking anything no any other questions couple down there I'm sort of all new to this a number of questions pop up actually so let's say you're a web app trying to access something in the bluetooth stack has the api to that been standardised across the world like seeing what bluetooth mac addresses are out there that you can talk to what do you mean by that has the api be standardised across the world well okay our location api what position am I at now the web app wants to know that is that the same on all platforms I presume it's a javascript call is the parameter the same you're asking me to tell you if that's the same across all platforms it's not something that I could do because I haven't played with it across all mobile platforms well it's the same across all platforms but it's using the api so all the as we all know Mozilla is very strong in the web standards the other great thing is because Mozilla are Mozilla when they want to when they need some new stuff so there's been a lot of pushes that they've been pushing through with html5 etc to help and support the firefox os project as well and to help that standardisation so in that sense it's open standard code yes and your location and for example in the implementation of firefox os gps location etc at the lower gong is the same as android I guess that's why I chose something that wasn't location the first question is because I knew that was standardised it is I just wanted to make half comment and half answer question is that there are some api so for instance you might want access to the usb port to get an android you can't get it at the moment like there's a bug tracking that for web usb I think people started making a start on trying to define that as part of html5 but that's something like I think that's what you were talking about when you say if you want to add access to lower level things you can add it to gong and I guess do you need to define a web ideal for a new interface as well yes so you're designing so if we go back into so you do need to design that ipdl communication path yeah so you go as we said go into gong you're adding that into gong but you also do need to add and expose those web apis within gecko itself yes so you need to it's part of the parcel but that's also where if you interested in looking into it if you look into the ipdl and if you google up that on mazilla that'll kind of go through and explain it in a little bit more detail as well like how papers and everything are about that but that is the same way that's what firefox browser utilizes as well hopefully this is a bit more on topic it's more how it works the web apps I presume some of them have local data stores like if you're a contact app you store a whole list of them I'm not here to talk about web app development which is clearly what I put on the front of the talk is like this is not a talk about I'm not going to ask you about this is a talk about going to the architecture so yeah what I'm going to ask you about is how does permissions between getting that information go through your stack and permission manager so I've created a private data store I have another app that wants to access that private data how do you manage permissions how do I say app A is allowed to read my contacts which is managed by app B okay so if we're looking at it so as we said you're actually going to the permission manager in gecko and that's where the IPDL process comes into it as well and where we're talking about the newest spawns parent child spawns oops wrong one I've got to put it on here no so you beat everything the apps the way it's done is for the app to run with the minimal set of permissions that it needs so any request like that if it was going to want to do that then it would have to go back up to the B2G process and the permission staff would have to then come down through there and through the new R process as well so in a sense if that's not there in the B2G you're not going to get that access going across to it so the apps really do everything's really quite sandboxed and run with a very small set of permissions okay I think that's probably about all time we have for questions sadly but Amy you'll be around I'm sure people can track you down with hopefully it was a little bit worthwhile and sorry for being a little bit rushed on it all but yeah thank you


PPPs in infrastructure development in our countries are simply practical wisdom. Governments evidently lack the resources to solely finance, build and manage public infrastructure. So the way out is PPPs. And our infrastructure concession and regulatory commission has since its inauguration taken over about 55 PPP projects all over the country, including the Muritala-Muhammad Airport, Garuki Hospital here in Apuja, the Kainji, Jeba, Shiroro hydroelectric power projects, and about 25 terminals concessions to private operators. So we must commend the global infrastructure hub for developing these tools, the PPP risk allocation and PPP contract management tools. It is clear that the use of these contract management and risk assessment tools will further strengthen transparency and accountability in the Nigerian PPP environment.


and welcome to the session. This is Professor Farhad and this session we're going to be looking at stock dividend, whether it's small or large, as well as stock split. This topic is covered in a financial accounting course and it's also covered on the CPA FAR exam section. As always, I would like to remind you, my viewers, to connect with me on a professional as well as a personal level. Please, if you have a LinkedIn account, connect with me on LinkedIn. If you don't have a LinkedIn account, I strongly suggest you do start a LinkedIn account. Facebook, if you are a Facebook user, please like my Facebook page and you want to make sure you subscribe to my YouTube. This is where I house all my lectures. Please like them, share them, put them in playlists, let the world know about them. If they're beneficial to you, they might be beneficial for others. I also have a Instagram account and a website. So what is the reason for stock dividend? Well, company generally satisfy shareholders by giving them cash. So that's because cash shareholders can do anything with cash. So they like this. Sometimes the company needs to preserve the cash. But nevertheless, they want to reward the shareholders. So what they do, they will give them additional stocks. Rather than giving them cash, they will give them additional stocks of the company. And that stock is distributed on a pro-rata basis. What does it mean? It means if you own 5% of the company and the company is issuing 100,000 new shares, you will get 5,000 shares because you own 5%. Reasons why the company issue stock dividend. The first reason is what some of the reasons is to satisfy stockholders dividend expectation. The stockholders wants to receive dividend. That's why you invest in the company. At the same time, the company wants to preserve their cash. They don't want to spend the cash. Therefore, they'll give you dividend and stock dividend instead. Another reason it increased the marketability of the corporation stocks. What happened when you distribute new shares, the price of the stock goes down. And you will see how and why because you have new shares, new shares supposed to drive the stock price down because it's supplying in demand. Therefore, it makes the stock more marketable. Emphasize a portion of stockholders equity has been permanently reinvested in the business. So basically what's going to happen when you do a stock dividend, basically you're going to take the dividend out of retained earning and put it into common stock. What does that mean? It's going to show that the company is reinvesting in its owner in itself. So we have two types of stock dividend that you need to be aware of. We have small stock dividend, which is less than 20 to 25 percent of the corporation issued stock recorded at fair value. And we have large stock dividend, which is greater than 20 to 25 percent. What does that mean? Let's assume the company currently have one million shares outstanding. If the company issue 50,000 new shares, 50,000 is 5 percent of a million. We consider this a small stock dividend. Let's assume the company decided to issue 400,000 new shares. Well, that's going to be a large. Why? Because 400,000 out of a million, they're adding 40 percent. 40 percent is here. Now, what do you need to know about small and large? When we issue a small stock dividend, so here's the key that you need to know. When we issue a small stock dividend, we record the issue at fair market value. And what's the assumption? Accounting based on the assumption that small stock dividend would have little effect on the market price of the outstanding shares. Okay? When we issue large stock dividend, which we'll see an example of both, we're going to record the issuance at par value. What does that mean? Wait until we have a number. Just remember, small stock dividend issue at market value, large stock dividend issued at par value. The best way to illustrate this is to work an example. Assuming Midland Corporation declares a 10 percent stock dividend. 10 percent is small. It means we're going to be using the fair market value of the stock on its 50,000 shares. So they have 50,000 shares and they're going to issue 10 percent. It means they're going to be issuing 5,000 new shares. The current fair market price is $15. Well, the fair market value of each share is $15 and that's relevant for us because it's a 10 percent. So what do we debit? We debit stock dividend. Now, in some textbook, you're going to see they debit, you're going to see that they debit retained earnings. That's okay, too. Okay? Because stock dividend is close and to retained earnings. And how much do we debit stock dividend? We debit it 50,000 times 10 percent, which is 5,000 times the market price, which comes up to 75,000. Then we credit an account called common dividend stock distributable, which is an equity account of 50,000. And we credit this account number of shares times the par value. This sounds like we are issuing common stock. Indeed, this common stock dividend distributable, it's going to be closed to common stock. Okay? And anything left is paid in capital. Anything left is paid in capital. So notice we have common stock now in our paid in capital section. We have common stock dividend distributable. As I told you, it's an equity account and we have paid in capital. That's fine. Now, when we actually issue the stock, when we actually issue the stock, we debit this account and we turn it into common stock. So simply put, as I told you, this 50,000, it's going to be eventually becomes common stock. So when we issue the stock, when we issue the stock to the shareholders, we give it to the, we give it to the, we give it to the owners. So the same thing happens. The same thing, I mean, the stock is actually issued. Now, let's take a look at the, at everything before and after. Before the dividend, we have 50,000 of common stock, total paid in capital, 50,000 retained earning is 300,000. Before dividend, we have total equity of 800,000, outstanding shares of 50,000 in the fair market value was $10. Let's assume we issued the stock dividend. So we issued 50,000 in additional 5%, I'm sorry, 10%, this is 10%. Okay. So we're going to be issuing, let's see, 75, actually 75,000 right here. Yes, that's 10%. We're going to be issuing an additional $75,000 and paid in capital, 50,000 went to common stock, 25,000 went to, went to paid in capital. So we're going to increase this equity, then we're going to be reducing retained earning because dividend comes out of retained earning. So we increase equity by 75, reduce retained earning by 75, the effect is zero. Now the outstanding shares went up by 5,000, we have more shares, but the effect is zero. Notice we have common stock after the dividend 550, paid in capital 25, total of 575, retained earning went down to 225. So before and after total equity is the same. The number of shares went up, but total equity is the same. Okay. Now there's an error here. The market value is $15, not 10. It was given S15. So we'll stick with it S15. Okay. Which of the following is true statement about small stock dividend? A debit to stock dividend for the par value of the shares issued, issued, should be made. The par value, now this is for large stock dividend. Small stock dividend decreased total equity. No, it doesn't decrease total equity. It just showed you equity is the same before and after. Market value per share should be assigned to the dividend share. And the answer is yes. Remember, if we're small, a small stock dividend ordinary will have no effect on par value. We'll have an effect on par value. It has no effect on par value. C is the answer. Okay. Let's take a look at this question now. In a stockholders' equity section, common stock dividend distributed is reported as what? So this account, common stock dividend distributable. Is it a deduction from total paid in capital and retained earning? Is it contra equity? Is it deduction? No. Is it a current liability? No, it's not. It's in the equity section. It cannot be a current liability. Deduction from retained earnings. No, it's not a deduction from retained earning addition to capital stock. Yes, it's basically, it's an equity account. It's an equity account. It's an equity account. Now, let's assume, let's assume for the sake of illustration, this was a, just for the sake of illustration, this was a large, let's assume this was a large stock dividend. So simply put, let's assume we issued, let's make it 40%. Let's assume we issued 40% stock dividend on our 50,000 shares, $10 par value common stock. Actually, I just made the mistake. The par value is $10. I read this as market value. The par value is 10. The par value is 10. The par value is 10. Sorry about that. I read it as market. Okay. So let's go back and change this example and assume we're going to be issuing 40%. 40%. So let's go ahead and start the computation. So we have 50,000 shares times 40%. We're going to be issuing 20,000 new shares, 20,000 times. Now, because this is a large stock dividend, we're going to multiply it by the par value, which is $10. So we're going to have $200,000. Therefore, we debit stock dividend, 200,000. We don't have paid in capital because we issued it exactly at par and we have common stock dividend distributable, 200,000. Then when we issue the stock, we debit common stock dividend distributable, then we credit common stock. So notice a large stock dividend will not have paid in capital. So large stock dividend, remember what I said earlier, a large stock dividend is recorded at par value. And this is what I meant recorded at par value. If you have any questions, any comments about this recording, please email me. If you happen to visit my website for additional lectures, please consider donating. Good luck.