Hello, and welcome back to SuperCloud 4. This is our in-studio live event covering generative AI. This is our fourth episode of our quarterly digital series where we unpack the next generation cloud technologies, how that's going to impact customers, the industry, and developers building those next generation apps. Generative AI is all the buzz and hype, as well as matching with reality. This is the first time in history I've seen in my career where hype and reality are coming together at such amazing speeds. And here is Brett and Sahab, VP of AI and ML services at AWS, who couldn't make it in the studio, so we're bringing them in remote. Brought in great to see you, and thanks for coming on our SuperCloud to do one of the key nails. I really appreciate your time. Thank you, John. Nice to be here. Thank you for having me. So we're kicking off kind of what this all means for the next gen cloud with AI. Obviously, I was talking to Swami when he announced the expanded relationship with Huggingface back in the day, a couple of months ago, feels like two years ago. You key noted our Amazon startup showcase which featured Cohere, Stability AI and a handful of other startups in the area. That was in February, okay? So much has happened since then and coming up on reinvent in a few months, we're going to see probably an explosion of even more ecosystem activity. The customers here are enterprises and the startups that are emerging. The private companies as well, two sets of customers, very interested in leveraging cloud for generative AI. Give us the update since February in the past couple of months when the tsunami of announcement saw Bedrock when GA, give us the quick update, high level, what's changed in just in the past few months from an AWS perspective around generative AI and your customers? Yeah. So, you know, Bedrock and GA just sometime back and we've added more models to Bedrock. We have since the announcement earlier this year, we also added Cohere. And, you know, we are really excited at how customers are starting to use them, use the models in Bedrock. And then in addition, code whisperer that I think we talked about earlier in the year and I talked about before, that really launched the customization capability. So, that allows customers to, you know, kind of customize it for their own code bases, their own styles of coding and so on. We are also very excited by what customers can do with Trainiam and Inferentia. And, you know, the performance improvements and the performance per dollar improvements that they get from those. And a lot of customers are continuing to build generative AI models on top of SageMaker. So, you know, all in all, going in from Bedrock being the easiest way to build generative AI apps with its, you know, gen AI capabilities and its foundation models to code whisperer to the infrastructure. We have the hardware infrastructure which is purpose built for generative AI so that it gives you the best cost and performance. And then, you know, providing the ML infrastructure, the software infrastructure for customers to build their own FMs, their own foundation models. Bedrock, Bedrock's the curated set of models you guys are putting out there. And then you have SageMaker as everything else. You've got open source models, people can play in there. And that's kind of the interface for your customers. Is that right? Yes. And, you know, Bedrock provides state of the art models. So, you know, it's, as you said, John, curated state of the art models, but then there are a lot of other models that are available on SageMaker. Jumpstart in open source models and others. And we think that a single model isn't going to work necessarily for all use cases. Customers want this choice. And that is why we are excited about it. And we actually see the industry moving in this direction. If you look at the way it's going, there's one other application that, you know, we can talk about later on, and that is HealthScribe. You know, we actually released a GNAI-based product, HealthScribe, that helps with patient-physician interaction. So we can go into that as well later on. Yeah, this is, again, the teasing out, again, what I think has changed since our last conversation. You had, I thought, said some pretty brilliant things. In our last meeting, I thought was, you know, basic, but from an industry standpoint, but it kind of was genius in the sense it was right. You said three things with AI. And I just tweeted this, actually. Changing the way you interact with the information, generating software number two, and three, other areas like heavy lifting, undifferentiated documentation. Okay, great, get that baseline. Now you're seeing the products, apps come out as chatbots, some sort of co-pilot like human assistance, and then predictive, kind of like the, that seems to be the state-of-the-art apps today. Now they're going to another level, okay? And we're starting to see models that need to move into production. And that's the biggest conversation we're seeing going into re-invent, and here in the SuperCloud conference we're having, how do I get the production, move from experimentation demo, which you can do with the right clean data, or synthetic data, how do I move that into production, at scale, at a cost structure. And so I have to ask you, again, your perspective on that, and two, as people build their own models, I won't say proprietary, but relative to their data, which is intellectual capital and property, they will need to interact with the big three or the big four proprietary models. Through APIs, managing, compute, and horsepower. So this is kind of a multi-dimensional, multi-side coin here. What's your reaction to that? Because this seems to be where the conversation is going. Do you see it the same way? And how would you react to that? Yeah, and I think that is where, it comes back to, if you take a step back, it comes back to deploying generative AI at scale in the enterprise is a different kettle of fish than just having demos or consumer apps. Because like you said, a lot of factors come into the play. There's accuracy, there is cost, there is latency, there's performance and all of that. And so it's a multi-dimensional, multi-faceted optimization problem that you need to do. And that is where having a choice of models is so important because there are use cases where you may want to use a particular model that has been fine-tuned on your data. So getting back to your question, how do customers make it, how do we make it easier for customers to deploy to production? I think bedrock makes it really easy because we have done a lot of the heavy lifting of taking these models, training it, optimizing it and we're going to do a lot of optimizations in terms of reducing the inference cost. The second thing I'll also say is that when you think about all of these models, there is an aspect around how do you make them scale as these products are being used by a lot of consumers. And that is where I think there's a lot of heavy lifting in terms of getting the right latency, the right traffic control, the auto scaling and all of that. And all of that is taken care of behind the scenes by bedrock. Now there might also be situations where customers actually build their own proprietary models or take a model and fine tune it and then deploy it. There are two options there. One, if you go do it with bedrock, you actually get your own private copy of the model. And so when you want to fine tune the model because you're getting your own private copy of the model, your data doesn't get into the base model. But there might also be other cases where you want to take one of these open source models that actually works well for you and that is where we have a number of features that we have added in SageMaker so that we can reduce the cost by an order of magnitude. There are a couple of features that are now in private beta with customers that were hopefully launched at re-invent. And those are things that reduce cost by orders of magnitude. And so these are all the things that we're really thinking through and innovating on to reduce the cost, the latency and keep improving on the performance. Yeah, and I was talking with Octo ML, one of your partners, Louise, computer science professor, founder of, they do a lot of training, management around costs. He brought up a couple of use cases where if something can go viral, you could be in the millions of dollars. So managing costs is a big concern for customers. And so the lightweight models that you can maybe get some visibility into the unit economics of the AI is one factor. But if you zoom out, there's a couple of things going on I want to get your thoughts on. One is this notion of a context window, which is a lot around the language and all the foundational models. How much data can you bring in? The tokens that are first in, what's the throughput? Reminds me of the old PC days when you had to look at performance. There's a lot of throughput performance issues that need to be managed and there's costs associated with it. And then there's the apps that are being developed. So let's start with the apps. Then you have AI wrappers type apps where people are wrapping some AI around it with the large language models. I call that the basic website for analogy. You get the web and then the websites became an application for the web to use that analogy. We're seeing a lot of really cool AI wrappers. And I was kind of down on that, but now I'm thinking that's actually cool. And then you have AI native apps. And then you have kind of under the hood platform engineering like apps. Do you see it the same way? And what's your comment on those three app layers and how does Amazon fulfill that? Because you're seeing startups and enterprises deploying those three scenarios. Yeah, so I think the way we are seeing is kind of along the lines of what you mentioned. One is apps that kind of already exist, but you kind of accelerate or turbo charge those apps through generative models. And so you can do things that with those apps that you couldn't do before. Then there is the next set, which I think you're kind of called AI native or AI from the ground up, which is you really are coming up, rethinking the app and embedding generative AI from the get go. And the kinds of capabilities that you can see in those situations are different. So we are seeing both of those happen. And we are doing some of it ourselves, where if you think about code whisperer, it was like from the ground up, like without generative AI, that product isn't really there. So this is just built from the ground up. If you think about health scribe, again, it's built from the ground up. But then there were also other situations where you're embedding generative AI into what already exists and making it more powerful and more useful. So I think we see both of those. Talk about the throughput on one of the big areas again, and these big changes you're going to see. I see a big wave back to talking about the silicon. We've been harping on this for years. Not that it's new to the queue, but new to everybody else. But how fast can you go with the GPUs, the CPUs, compute performance at the silicon level? So you got that infrastructure layer powering this new generation of apps, whether it's context window expansion for tokens on the apps or just managing costs so that you can understand how to do policy based stuff that's familiar to cloud scale. How should customers think about that? What's the best practice from an Amazon perspective, Amazon web services perspective on how to manage the right horsepower, understanding the tuning, not just training, but this has got inference there as well. How to integrate with the APIs in a large language. What's the best practice to manage all the infrastructure? I think it's first pretty use case specific. And that is where having choice and flexibility is important. The next phase, depending on your use case, you may want to have different approaches. In some use cases, the foundation model just out of the box pretty much works well and all you're doing is prompt optimization and prompt engineering. And you can play around in the context windows to allow the model to learn more from the information that you're providing in context learning. There are also situations where you would want to have some fine tuning to get to the right accuracy level. And in those situations, you want to take your model and then tune it and then train it some more on your data to get to the right accuracy level. And what that may also let you do is actually be able to use a smaller model because that model is more specialized for the tasks that you want to get done. And when you're doing that, that brings down your cost envelope. There are also situations when you're really looking to get the highest accuracy. And in those cases, you don't necessarily and you want to restrict the answers to within a particular corpus of knowledge. And in those cases, you may want to go with a rack-based approach where, you're basically taking data sources and you are using retrieval augmentation to generate your answers from there. And then there are situations where we have seen, you may want to kind of use a little bit of a hybrid approach where some of the parts are maybe done by a non-foundation model approach and then some of the parts, more of the interactive Q&A part is done by a foundation model approach. So it's kind of pretty use case specific and that experimentation. And you have to do experimentation. And so I think from an Amazon web services perspective, you will say, look, one size doesn't fit all. One model isn't going to cut it. You need choice, you need flexibility. We agree. We see an integration of models. We think that's the API economy at the next level. I know you got a hard stop. I want to get one final question in. As you look at the use cases of the experimentation on the developer community as they get the good demos and look into production at a low cost and you guys are focused on that. A big question comes up around how to handle the data. So a lot of data modeling is coming in to figure out, you're seeing excitement around vector databases. You're seeing how people are using, you mentioned retrieval, how do you get memory, not memory on the machines, but memory in the retrieval with embeddings and whatnot. This is cutting edge stuff around this. So that changes the data modeling and hence the observability equation. How do you know what to measure? If I change my embedding pattern or change my window and context, there's going to change the results and there's new metrics coming out. Can you share your view on how people should think about instrumenting and looking at this new kind of observability? What's your perspective on this? So one of the things that we have started, and I think people will increasingly have to do this, is there's a lot of work on, okay, let's go look at the accuracy of the model. But just as you pointed out, John, it's not the accuracy of the model, it's the accuracy of the end-to-end solution. And then there are many factors that go into building it. And so you have to measure the accuracy of the end-to-end that can often be different than just the accuracy of the model. And you may actually see the parts interacting. And then you also have to ensure that you have a data architecture that actually provides you all of the basic guarantees in terms of security and privacy and all of that. Encryption at rest and transit and all of that. So I think, we ourselves do a lot of that now, where we're looking at the end-to-end, not just the model performance and ensuring that we are having the right data architecture to make sure that the data is being handled in the right way. All of the basic security privacy stuff, but also things like bias protection and toxicity and all of that needs to be eradicated. I think there's a whole app performance management aspect of this that's going to unleash new things. I think, I know Adam uses the three steps in the 10K race. We like to stick with innings, because we love baseball. It's not even the game yet, it's pre-game. So, Breton, I really appreciate you coming on and spending the time, I know you're super valuable, I know you got some reinvent. Is there anything, reinvent content, is there anything you want to share about reinvent before it comes up while we're here? You know, I think, you know, I look forward to meeting you and others at reinvent. I mean, I think it would be a great, great place. And you know, I'm sure we'll have a lot of exciting announcements. You don't want to share any here? No. We'll take you at reinvent and then, you know, hopefully we can talk more there. I know you guys just busting your chops there. I know you guys are working on it. Looking forward to it, it should be exciting. Thanks for taking the time for coming on our SuperCloud for this keynote. I know you could make it in person. Really appreciate you coming in into our remote studio. Thank you so much. Thank you, John. Really nice being here. Okay. Ratan Saha, VP of AI and Machine Learning, Sir Zated Best, breaking down what's going on is the data modeling and this new era is feeding the AI. It's about end to end, not just model training, there's inferences, there's smaller language models, large proprietary. It's a fusion. It's a collision of innovation at the infrastructure to power these apps from AI wrappers to native applications to whole new sets of integrations. So it's going to be a next gen cloud meets AI. It's the same game, performance at the hardware level and application, whether it's cloud or on premise, it's a SuperCloud either way. Genevieve AI is a hot topic and we'll be back up with the next segment after this break.


Welcome, everyone. Thank you for joining us for our session Creating a Credible and Trusted Digital Currency. In a fun and frenetic 45 minutes, we are going to walk you through the opportunities, the challenges, some of the concerns around digital currencies. Now, what you may have been observing here in Davos this week is that the conversation around stable coin digital currencies, and we'll define those terms, has shifted. It's no longer a conversation about whether this is going to happen, whether we'll see an issuance of this kind of opportunity. It's more a matter of when and how. And our panelists today, our distinguished panelists, are going to get into some of these specifics. To my immediate left, we have Senior Minister Thurman from Singapore. We then move over to Valdez Dombrovsky's from the European Commission. Benoit Coray from the Bank for International Settlements, also known as the BIS. Neha Narula from the Digital Currency Initiative at MIT. And David Marcus of Calibra and of Facebook. So, Neha, I'll turn to you to kick us off. Could you please walk us through some of the terminology? It's quite confusing in this space. Give us a sense of definitions. Are we talking about Bitcoin or what is this? Yeah, thanks, Sheila. It's definitely a bit confusing because of the cryptocurrency craze. I think what's happened is that cryptocurrencies have inspired us to rethink the way that we move and transmit value and what we can do with it. We have things like cryptocurrency, Bitcoin, and Ethereum, which is not actually what we're talking about today. We're talking more about digital currency. The idea here is that we're talking about a form of currency that's perhaps public, issued by a central bank, or perhaps private, issued by an institution, but something that corresponds to what we know more commonly as government currencies or fiat currency. In addition to that, we've seen some innovation in the cryptocurrency blockchain world and things have been created called stablecoins. The idea behind a stablecoin, some examples of these are USDC or Tether, the idea behind a stablecoin is that either someone stores government currency in a bank account one-to-one and issues a digital token representing that, or there are some really more interesting complex ideas that are based on collateral and algorithms to maintain a stable peg. In addition to that, we have digital assets more broadly. These might be a form of digital gold or real estate equities, commodities. The idea here is by wrapping these assets in software, we can enable new ways of storing and transmitting them. Thank you. Could you say a bit about blockchain technology? There's a lot of conflation, I think, with this concept of digital currency and a blockchain technology. What are the distinctions, if any? I think we were definitely inspired by blockchains and cryptocurrencies to rethink how these things could be built, but it's important to note that digital currency doesn't necessarily require a blockchain-like data structure behind it. We could implement digital currency in many different ways. In fact, many people say to me, don't we already have digital currency? We, you know, I make payments electronically, I transfer money electronically, how is this any different? I think the key idea here is that we're talking about a different interface. We're talking about something that a user or a company can hold directly, not necessarily through another institution like a bank. So, Thurman, I'll turn to you. Given this framing of digital currencies and our understanding of them, what's the opportunity? Why is this exciting? I think that's a good question, or what's the problem? And before we sort of continue this horserace of all the different initiatives, we've got to ask ourselves, what are the real use cases? Where are we going to add a value? What gaps are we trying to plug? What inefficiency are we trying to sort of get around? And I think the three big use cases are first, in cross-border payments. Most especially for people who are not making large payments. And the largest case of people who are not making large payments is the remittance business, evolving migrant workers of one form or another. That's a big business. It's currently, by and large, quite inefficient, not always reliable, and it costs too much. And if you're only making a payment of $100, that's the cost required, the fixed fee, is not a trivial sum. That's one thing. Second, financial inclusion. And here, I think what we are seeing in digital tokens, mobile wallets, et cetera, is broadly about digital inclusion. And it started off with credit schemes and the like, but now you have the opportunity for payments to be made by small enterprises, micro-enterprises, individual farmers. Everyone can actually partake in the modern economy. And it's an example of how FinTech is actually broadening excess, lowering costs, and including people in the new economy. So I think that's potentially quite a large use case. And particularly for emerging countries, I think it's really significant. Thirdly, on the defensive side, I would say there's an opportunity to reduce an impossible route out the very large volume of illicit finance that takes place globally. And digital tokens are either part of the solution or they're part of the problem. Today, by and large, they're part of the problem. It's well known that a large part of cryptocurrency usage is really for illicit finance of one form or another. But well-regulated with enough visibility, with enough public policy as part of this, governing this infrastructure, I think it can be part of the solution. Because remember, the cash economy is one that's well used for corruption and well used for all forms of money laundering. So getting around the problems of the cash economy, but not going for the very simple solutions we're seeing today, which actually are introducing more efficient ways of transmitting finance illegally, transmitting funds illegally, should be the objective. So basically cross-border payments, making it cheaper, faster and more reliable. Second, financial inclusion, particularly for smaller players, smaller enterprises and ordering individuals. And thirdly, rooting out illicit finance. So I think it's important to note that these use cases that you cite are globally relevant. I think there is a tendency to assign some of them to assume that the political poor divorces the invisible poor, for example, only exist in emerging economies. But of course, we know the significant portion of the American population, the European population, that is, in fact, comprises the invisible poor. But beyond these cases, Benoit, I'd love to hear from you. You have a recent announcement in this space, and I'd love to know, why so much activity from Europe? What is it that's so attractive about this opportunity? So, Sheila, first I wanted to thank you very much for the way you're framing the discussion that is starting from the use cases. Digital currency, and in particular, central bank digital currency, CBDC is not primarily a technical discussion. It's not primarily a technological discussion. It's about meeting needs. And then we've got to ask people, what are the needs? And then it's about setting principles. And it's about making it consistent internationally. Technology comes last, in my view. So I'm not so excited to know whether this will be a blockchain or not a blockchain and which kind of proof of work, proof of stake. This will come in due time, but it's not the primary question. And so, at the BIS, we've asked our members, we have, for the second year, we've done a survey for our members, and I'm coming to the difference between advanced economies and emerging market economies, which the senior minister started to discuss. And the numbers are quite interesting. So the report is out today, a few minutes ago, actually. 80% of central banks are engaged in CBDC work, 80%, which is up from 70% last year and 65% in 2017. There is a strong focus on retail CBDC. And when we ask different central banks about why they're doing it, the answers are different. Emerging market colleagues say that's about financial inclusion and that's about reducing the use of cash. While advanced colleagues in advanced economies tell us that's more about making sure that they will keep the link between citizens and the central bank in the face of a disappearing use of cash in some economies. So these are already different motivations. And what's also very interesting, also to set the timeline, that we are asking our members when are you going to do it? So 10% of central banks say they're likely to issue a general purpose CBDC, that is a retail CBDC, in the next three years, which is small but still twice as much as last year, up from 5%. And 20% say we're going to do it in the medium term, that is up to six years. Last year, all central banks indicating likely to implement were very small. And this year, when big central bank joined. So we now have roughly one-fifth of the global population in jurisdictions where the central bank tells us we're likely to do it within the next three years. So that gives you a sense of the shifting timeline and of the different needs. So emerging market economies are really focused on financial inclusion, focused on reducing the use of cash. And as the senior minister said, it's part of a broader discussion on payments and in particular on cross-border payments and how to make them cheaper and faster. You touched on a term that I wanna make sure we pause on, which is this concept of retail CBDC. So David, perhaps you could walk us through retail CBDC versus wholesale CBDC and explain the difference to the audience. Well, so in a construct where central banks issue or would issue digital currencies, they could distribute that digital currency in two possible ways. One is wholesale CBDC. So through existing banks and the banking system or retail going straight to consumers. And back to Tharman's question earlier on the panel, which is, you have to focus, I'm a product guy so I like to look at the problems you're trying to solve with a solution. And the big question is if you're actually targeting wholesale distribution to banks, then what problem are you solving? You could probably have some efficiency gains, but banks currently have windows with the Fed, DCB, et cetera that are quite functional. Or if you go retail, then the big question for central banks is are you equipped and prepared to serve consumers or small businesses? And what happens with the banks that actually need the leverage to extend loans and to fuel the growth of the economies that we're in? That being said, there are interesting hybrid models that have been evoked in CBDC around enabling not only banks but wallets to have access to those facilities. And those are really interesting developments that I think are worth continuing to track. But I have to say that the whole attention of the world now on digital currencies, whether it's stable coins or CBDCs or other forms is really encouraging because as far as we're concerned when we started this journey, mainly almost six months ago, the whole idea was really not around a certain way of doing things, but more around let's come together and let's try to figure out how we solve a problem that is honestly unacceptable. On 1.7 billion people who are currently unbanked, another billion underserved, and we still don't have a global network to move digital money around. And in telecommunications, we went from paying a dollar a minute for an international call to not paying anything with a very cheap Android device using over-the-top communication apps. But the same hasn't happened with money. It hasn't changed and some of the networks are 50 years old, the web is 30 years old, and we still don't have an easy, cheap, efficient way for people to have access to digital money and move it around. So personally, I'm really excited that we're having all of these conversations now. And I think everyone, all the right people are around the table to make it happen. So I hope it happens. Well, this building on that a little bit, I'd love to hear from you. What do you see as the modifications to the existing banking system? Is this a threat to commercial banks? What are the implications? Well, first of all, indeed. Also, when we look at this from the European Union perspective, how to react on developments on crypto assets, stable coins, other initiatives. First, we need to see what shortcomings those initiatives are addressing. And from that point of view, there are very different situations. In a sense, if you look at, well, crypto assets or as they were called, cryptocurrencies like Bitcoin and a number of others, well, they are not widely used for a store of value, for transactions, they are very volatile. And actually, European Commission called on European supervisory authorities to issue the warnings for investors on the highly speculative nature of these investments. At the same time, there is needs which are unaddressed, including on fast, convenient, and cheap cross-border payments. And we are partly addressing this problem within Europe. We have single euro payment area where you can transfer euros within euro area at the same cost as you transfer euros domestically. Last month, we extended this system to the whole European Union. So also countries outside Europe can transfer the money, the euros at the same cost. But it's still, for example, not fast. So currently, we are concentrating in Europe on developing pan-European instant payments system. And that's where initiatives like, for example, Libra come in because, in a sense, they seem to be offering the same solution on international scale. So we're looking, so what is there? And it's clear if European banking system, because if we talk instant payments, these other initiatives, so to say, driven by and closely linked with European banking system, if they do not address this demand themselves, somebody else will address this demand. Is it Libra or some other initiatives? Time will show. So it also shows the European banking system that they need to address the demand for those faster and cheaper payments. And that's, I would say, the main point here. Then if you look at stablecoin initiatives, especially like global stablecoin initiatives, of course, there are a number of issues which are raised. Some of them are mentioned, like on anti-money laundering. I've also mentioned tax evasion, consumer protection, personal data protection. So there's a whole range of issues which needs to be addressed. So what we did recently in European Union, we made what we call regulatory mapping of different crypto assets, including stablecoins. Looking where they fit in current EU legal system, do we need some new rules? And basically the conclusion is that yes, especially for crypto assets like stablecoins, you are likely to need new rules and we'll be preparing them in a context of our next FinTech action plan. But one thing I want to say, in a sense, we don't want to regulate financial innovation out of Europe. We want to regulate financial innovation in Europe while addressing potential risks. Thank you. So leaving aside central bank digital currency and focusing from it on stablecoin, and just as a quick reminder, central bank digital currency is essentially digital fiat currency versus stablecoin which is pegged to fiat or to an asset. What are we to make of the proliferation? I wouldn't say 1,000 flowers are blooming, but certainly 1,000 seeds seem to have been planted. Is it inevitable that we see consolidation or how can we make sense of a world in which there is a multitude of stablecoin? May I start with you? Yeah, well, I think initially we're definitely going to have competition as we try lots of different ideas out. It's, I think it's important to remember this space is still in its infancy and we are still determining what the right technology stack is exactly what the use cases are, how the platform might be used. So I expect we'll see multiple different stablecoins. They will compete. I do have to say however that I do think that ultimately a CBDC is really the answer and issuing a central bank digital currency directly, it reduces risk and it allows the central bank to provide a public option for money, which it should. So I think that stablecoins, certainly, we will have many more of them for the years to come, but if CBDC does really happen, it is a better choice. Yeah, I mean, look, as far as we're concerned, oh, we like CBDC, they'll get me wrong. It's fine. It's a different thing. So, and that's what I was going to say, which is that the way we see the world is basically that it would really be unfortunate if you had a proliferation of fragmented networks that don't interoperate and communicate with one another. The value that needs to be delivered to the very people that badly need this is that if you use a wallet or you use any other wallet that you have an interoperability layer at the core of the network that you use. And that's the way the internet works. It would be unacceptable if you would use Gmail and you couldn't send an email to someone with Yahoo Mail. But this is currently the situation. If you use a wallet app today, you cannot send a payment outside of a wallet app. I think in Europe, and I have to give credit to the European Union for that, with SEPA, if you're in a Eurozone bank, you can send money to any other banks and it works quite well. But that's not true everywhere in the world. And so for us, really what matters is to figure out what is the right network to host those stablecoins or CBDCs. Of course, we have an opinion on that. I think we bring a good technological solution to the network itself. And I want to really make that distinction between the network and the assets that are running on top of the network, which I think could be issued by many different entities, whether it's central banks or the private sector in some cases. And I think that if we were to agree on a sort of standard and a way to move digital money around in this new era of stablecoins and digital currencies, then I think people win at the end of the day. And so that, to me, is really important. Benoit. I think there is no preset course. I mean, when you try to think of the future of the, let's call it the monetary ecosystem, right? That can be quite a lot of diversity. It has to be a mix of public and private solutions as the payment world has always been. And competition will be good, because that's in the first place a discussion on technology, how technology can help improve efficiency and financial inclusion. And technological change comes from competition and it comes from the private sector. It usually doesn't come from the public sector. Sorry to say that. So we need that kind of spur, that pressure coming from innovation in the private sector. But to kind of put it very simply, the more you move towards the core of the system, the more likely that you will see central bank money, because that's what provides stability to the system. And we care about systemic stability. We care about financial stability. And we've built a system that works very well, which is based on RTGS systems, real-time gross settlement systems, which are settled in central bank money. That has worked very well through all crisis over the last 20 years. That has never failed, contrary to other parts of the financial system, which have shown many, many shortcomings. That has not failed. So we want to keep that kind of stability at the core of the system. Now, when you move towards the front end of the system, from the back end of the system towards the front end of the system, which is solutions for customers, payment solutions, then there is a room for a lot of innovation and most of it, if not all of it, will be provided by private players. And it's fine. So I think just to push back a little, when we think of those use cases, cross-border payment efficiency and costs, financial inclusion, rooting out illicit finance, it's clear that public policy will have to be involved. Regulation will have to be involved. Minimally, regulation to prevent anti, to prevent money laundering, right? And regardless of whether it's digital or the physical world, you've got to regulate. It's not obvious that the public sector also needs to be the provider of either the infrastructure or the constructs on top of the infrastructure. So either provider of the rails or the constructs that run on the rails. It's not obvious. You need regulation, certainly. Just bear in mind that we do want to have an open and interoperable system nationally and especially internationally. Central bank digital currencies are not constructed to be interoperable. They're not necessarily interoperable. They're separate national stacks. So just bear that in mind that the distinction between public and private is not a distinction between open and closed. There are actually four quadrants there. And you want to be in the quadrant which is open and interoperable, well-regulated, but also one that encourages innovation, both in the rails as well as very importantly in the constructs. Beware of unintended consequences. And think about what happens not in peacetime, but in crisis. What happens when you have a loss of confidence in one bank or a few banks? If you have a central bank digital currency, I'd be fairly sure that this, you know, on the one hand it's very, especially if it's a retail currency, right? It's highly democratic. You can have highly democratic flight out of banks into the central bank, much more than you have in a normal banking system. So just recognize that there's that risk at times of crisis, that people will take their money out of commercial banks, out of their retail deposits and put it with a central bank. Second, think about it nationally as well.  You get very easy dollarization of your economy. Some digital currencies that are not your own, a non-native digital currency can make that dollarization, I don't mean the US dollar, but the equivalent of dollarization, much easier. Just bear that in mind. So think, when you think of the solutions, the design of solutions, think not just of peacetime, but about what happens when you run into difficulty, when countries or banks run into difficulty. So I just don't want to jump to a conclusion now. I think one way or another, you're going to need public regulation of both the rails as well as the constructs of the rails. You don't want to snuff out innovation. You don't want to crowd out innovation. And to the credit of the private sector, spurred both by new technologies as well as just entrepreneurial energies, we've seen a whole range of innovations that are providing for a much more inclusive financial system. And mere provision of a currency or a token doesn't actually take us very far. But what's happening now is that the constructs on top of the rails, the products, the constructs, are actually allowing for smart contracts. For instance, insurance contracts that allow for automatic triggers when you have bad weather or in an earthquake or the speed of the wind changes. Contracts that allow for bond payments to be made automatically into a council. When a bond is maturing, you get an automatic payment into a person's account. There are all sorts of efficiencies and ways of serving the ultimate customer. And that's because the private sector and innovation is operating. So don't snuff out innovation. So I say this just by way of caution. It's not obvious that the solution is for the public sector, central banks, being the agent of the public sector, to be the providers of either the rails or the products that run on the rails. It may be the solution in some countries where you have a very inadequately developed financial sector and you have a lot of rent being captured, but I just worry about going too far into the retail space. In-law, and then we'll turn to a different topic. No, I just wanted to emphasize very much the importance of international coordination on CBDC, both for reasons of stability and of efficiency. Efficiency, because we want CBDC done in any economy to be used for cross-border payments. Whenever we have an euro, an E-sterling, an E-fran, an EEN, and so on and so forth, we want that to be used in an effective way for remittances. We want payment providers to be able to plug in and provide better solutions also in developing economies, which is a major development theme. And so that matters for the efficiency of the system and for inclusion. And it also matters for stability because as Tharman just said, we don't want either cryptocurrencies or stable coins or even CBDC done in a large economy to undermine monetary sovereignty in smaller economies. So that would be a major theme for international cooperation. The IMF would work on it. I would expect this to be a major theme in international fora for the next years. These are wise words of caution. I think it would do us all well to consider not only building to edge cases, but thinking about the unintended consequences of any of these kinds of opportunities. But I wanna shift us a little bit. We've been implicitly focusing on currency as a means of exchange. But there are other very critical, I think, and important uses of currency as a means of method of sovereignty. And I mean sovereignty in two different ways. One is sort of the ability for governments to engage with each other. And this gets crudely described as the sanctions issue. But also as a means of celebrating or preserving culture. And that's often quite literal.  But there are also just other sort of cultural aspects to that exchange of paper or coin cash that could lead to actually quite profound changes in the way that we think about interactions with each other. So I'd love to get comments from anyone on the panel about those concepts. Aldis Reff will start with you. Yeah, well, on this, of course, it's not a new discussion back in 1970s. Friedrich Hayek was speaking about denitization of money and competition among different private currencies. But I don't think we are at that stage, or at least not yet. And from that point of view, indeed, this aspect we didn't touch upon in previous discussions. But indeed, if we discuss, for example, global stablecoin projects, the question of monetary serenity and efficiency of monetary policy also comes into question. And that's where there were so many questions, say, on Libra projects, both from U.S. Federal Reserves and regulators, also from... Everyone. And European regulators. So clearly, that raises quite a number of serious questions. And there, in our approach, also in European Union, we clearly said that we differentiated between different small fintech crypto asset initiatives. They may have their own issues and some global initiatives which may quickly become systemically important. And then, of course, it requires quite a bit of more careful approach, also from the regulators and from the central bank's point of view. By the way, culture can change. It's very interesting what's happened in places like China or Kenya. We thought it'll be young people who sort of take very quickly to digital cash. It's amazing how quickly older people, the grandmothers, have taken to digital cash. And they are quick with it, maybe not as nimble with their fingers. But it's just the norm. It becomes the norm. And it's amazing how older people have taken to digital means. And it's more convenient to them. It's more secure. No one can knit your wallet. So culture changes. I think also culture changes when you fix a problem. And I think there are so many people that are strapped into cash economy today that if they have a window into the world's economy and the ability to digitize their money and have more opportunity, it changes their lives. And as a result, culture change happens really quickly when you solve a real problem for people. So let's get back to the financial inclusion point because this is often the first use case that everyone cites or the second depending I suppose on your ordering. And I want to draw the distinction again between what I called earlier the political poor or the kind of accredited poor, let's call it, that have identification, that have credentialism shift, and the invisible poor, those who seem to be beyond the reach of the system. We know that that population is still engaging primarily in cash exchange. Is it realistic to expect that the digital literacy, the kind of the infrastructural requirements that are needed to address that portion of the population, could that problems, those preconditions could be solved in a manner that would actually enable us to abandon paper or metal currency? Maybe if I may on this, of course financial exclusion is also a problem within European Union and we admit it and actually we have a, well, legislation now in place requiring basically banks to ensure that every European has access to basic banking services. So because indeed over the last years there have been lots of requirements put on banks in terms of capital requirements, in terms of anti-money laundering requirements and so on and a number of cases it led to the phenomena with which banks call the risking, but which in fact often ends as a financial exclusion. So from that point of view, what we are saying in Europe, no everyone as a physical person has right to how basic banking services to fight exactly this financial exclusion. Yeah, I think it's a complex discussion. There is no simple causality here. We've seen cases where technical change and in particular mobile payments have helped the poorest to kind of leapfrog over some of the hurdles they were facing in terms of financial inclusion, in particular bank accounts, right? And that's the case in particular in developing economies. We've seen other cases where technical change has kind of accelerated the penetration of bank accounts. That's the case in India with the Indian stack, for instance. And we might see cases where we still need cash to address part of the population, which just doesn't know how to use a smartphone. And that's okay, or is homeless and will never have a bank account, et cetera, et cetera. So we might, I think we've got to be quite flexible in terms of envisaging a future where we'll have different means of payments for different parts of the population and that will be in different ways across countries. So there is no single template for CBDC. We'll have to accept diversity because of cultural, different cultural approaches because of different financial systems, banked, unbanked, et cetera, et cetera. What we need to do is to have common principles because that's about the stability of the system and to have interoperability because we want the system to work as a system. But that said, within a country, there is a wide room for diversity. Absolutely, there's always a fitness for purpose should be paramount, Neha, yes. Yeah, I just want to echo that. There is no one size solution which is going to fit all and different countries are going to try different things and different techniques are going to work in different places. I do want to stress that it's very important to get the balance between the public sector and the private sector right. I would argue that our existing situation with very slow, expensive cross-border transactions is in part because we left a lot to the private sector that did not really get us where we need to be. So it's very important for the public sector to step up, to provide an option, to make sure that we have the right framework to consider very important issues that the private sector might not get to. For example, it's interesting to look back at what's happened with our internet today. There are a few very large companies which collect massive amounts of data on people and essentially surveil them even as they're walking around their own homes and cities. We need to make sure that something like this does not happen with financial transactions. It's very important to consider user sovereignty and user data and I'm very happy to hear that the European Commission is considering the right type of regulatory framework for financial transactions. That sounds like we've expressed some of the potential benefits. We've certainly heard some notes of caution and it sounds like we are in the beginning of a probably relatively long journey before we establish it for purpose in these different kinds of use cases in different environments. Before we open up for the audience for questions, I'll invite the panel to just give a final remark and we'll just go down the line and then I'll begin with you. So I think we, you know, I had to guess where we land up now that the public sector is focused on this issue. It'll be a hybrid system or hybrid systems. There will for sure be greater public regulation of both the infrastructure on which these payment systems are run as well as some of the constructs. Minimally to avoid money laundering but also just to ensure that you don't get too much rent capture. You will not necessarily see the public sector running the system but in some countries and if you take China there's a very unique situation where you already had two large private universes of payments and one of the reasons why the People's Bank of China has issued effectively a digital currency is really to provide a public option that doesn't avoid, that doesn't have information being lodged with third party providers and at low cost. So you'll have national circumstances like that but it seems to me that we should be thinking hard about innovation in the constructs that are made possible now by digital technologies, innovation that provides a better value for customers and it's not the public sector typically that does that. Preserving sovereignty is going to be the trickiest part of this game it seems to me. You can think of the financial stability, regulations required, anti-money laundering regulations and so on. Preserving monetary sovereignty is going to be a very important part of this. Be it with regard to private stable coins or some synthetic multi-currency stable coins or central bank digital currencies. Sovereignty of other countries is also going to be an issue. Well, just a very brief message from EU side. Well, from EU side we are open to financial innovation, financial technologies, we are willing to embrace it and we are willing to ensure that within EU it's possible to use a full scale of EU single market for FinTech for financial innovations. So later this year we'll be coming with an updated FinTech action plan to see what are the next steps in Europe as regards financial technologies but we want to embrace it while addressing the risks. So at WIS we'll keep bringing people together to make sure that whatever they do and however fast they want to do it or slowly they want to do it. They keep in mind the interest of the global system as a system and they keep in mind the consequences of what they're doing on global financial stability. And there is a risk of fragmentation and the global financial system is already fragmented enough, maybe it's getting more fragmented for various reasons. We don't want CBDC to be an additional source of fragmentation so that would be our priority. Thank you, Neha. Look, we're talking about the stability of the international monetary system and certainly applying technology as Tharman pointed out can have unintended consequences but I think it's incredibly important to have this conversation and it's wonderful to have these institutions stepping up at this level to have this conversation and to consider the possibilities. I'm very excited to see what happens next. Thank you, Neha. So look, for me, I'm an optimist otherwise I wouldn't be doing what I'm doing but I'm really encouraged by the dialogue. I feel that, you know, a year ago we weren't having the kind of conversations that I think will lead to a regulatory regime that would ensure that projects like ours and others can actually see the light of day with the proper framing of what is doable and what's not and do it in a responsible way that would actually ensure that we deliver the benefits that I think we can deliver without some of the unintended consequences that can stem from innovation. So I'm an optimist and I think that there's going to be a big change and a big revolution that will happen and that will benefit a lot of the people who are often left behind and also, you know, Tharmin, you mentioned programmable money, smart contracts. I'm actually really optimistic about the ability to really empower digital money and have a whole series and range of innovations around financial systems. Thank you. I think we have time for maybe one or two questions from the audience. I think we have a microphone we're going to run around. Yes, okay, let's go right here. Thank you. Beatrice Vader from CEPR. My question is to you, David, your optimism. The Libra project certainly has met with a lot of interest and also a lot of skepticism. So when you read the G20 report and the many, many concerns that are raised there, my question to you is, can you really keep up your optimism or more concretely, will Libra, will we have Libra in a year or two? What is your view there? So Benoit wrote the G20 report. G7, G7. The G7 reports, sorry. The G7 reports, yes. Yes, so Benoit was leading that effort and I think that all of the concerns that were raised in that report are very legitimate concerns and we have to address these concerns for a project like ours and many others to move forward and we're completely on board with that. And I think, you know, one of the things that was really misunderstood when we announced the project in June is that some people thought this is it.  We wanted to start a conversation and that we did for sure. And we received a lot of feedback but also a tremendous amount of legitimate concerns that we have to address with practical solutions. And I speak with my Libra board seat hat on and I'd say that at the association, all of the members have come together, have made decisions and are starting to address these concerns with one voice, which wasn't possible before we had a full governance established and an ability for all members to participate in that process. So yes, I'm an optimist and I believe that we will address these concerns. We will have to make changes and that eventually we'll have an opportunity to start really, because the beginning of the journey is not now. The beginning of the journey is when this network comes to life and when there's an ability for various companies to start building products to serve consumers. And my hope is that this day will happen sooner rather than later. I have a final question, Yang. Very quickly, Yan Qing from East High Media Group. My question is to Central Banker and also former Central Banker. How are you concerned that the CBDC will lead to the kind of narrow banking which is this intermediary of the whole system? Is it hurdle that the Central Bank should move slowly on that direction? So what's the phrase? Make haste slowly. I think that should be the way we approach the sole issue. We should keep an open mind. I don't think we should rush to solutions. We should start by looking at the use cases and the problems. And we should be very aware of the fact that the public sector should get involved where they are public goods. And where possible, we should regulate and incentivize the private sector. I'm convinced that this system is going to be, is going to involve a lot more regulation than a destiny. It's going to be necessary for very obvious reasons to do with illicit finance, but it's also going to be necessary to ensure interoperability, to ensure that there's a global coordination and to ensure that there isn't a loss of monetary sovereignty. So it's going to be a more regulated system than it is today, but that doesn't necessarily mean the public sector is going to be the provider of the infrastructure or the digital tokens. So we've got to think it through for all the reasons Tharman just mentioned and also because as suggested by your question, this can have very profound consequences on the structure of the system and on the road of bonds versus non-bonds and on financial stability. So we've got to think through the consequences of the different models, wholesale, retail, et cetera. And so we're not going to rush. It's a long journey which is why it's starting now. It's actually, so sooner we start the better because it's a long journey. And I'll just add that from the forum's perspective, we agreed this is a very serious undertaking and we are committed to supporting public-private cooperation in this space. To that end, we earlier this week released a CVDC policy makers toolkit which we are piloting with the central banks of Uruguay, Thailand and Bahrain that provides an analytical framework for assessing is a CVDC appropriate for a particular environment.


Hello everyone. I'm Igor Stopa. I work for Huawei at the Cyber Security Privacy Protection Lab in Helsinki, Finland. What I want to discuss today is a sort of part of a presentation I had last year at the same conference. I will try to make it so that there are not too many references to the previous one, but I will mention when there is some connection. The goal is to try to improve the protection of critical kernel data. What I want to present are, first of all, the problems that are involved in this endeavor and the solution that I came up with. At least the first part will be a high-level description and then we will see various possibilities for the back-end implementation. So why critical kernel data? Actually, I was lucky enough that some of the previous presentation have already kind of broken the ice about this. But my impression is that the kernel data is really not at the same level as code, for example, when it comes to protection. So it seems obvious that when we take away the easier part for attackers to succeed, then the attacker is forced to go down the harder part just because it's the only one which is left. The typical way to do this protection is to use the system MMU. However, that's where several problems arise. As I said, if this sounds familiar, it's because it is. Various entities have been doing this already for quite some times. Some of them are actually just in the business of doing security. Some others do it as a sort of side effect. And the Linux kernel already does implement some of this at the fairly coarse grain. And as I said, I've been hacking at it for more than one year, so you might have stumbled in some of my mails. As I said, not everyone is actually interested in getting this merged into upstream because it's their core business. And others might just not be willing to put the effort in it. Plus, some of these implementations do not work as a standalone solution related to the Linux kernel. So that is also a possible obstacle because then one has to work the solution into multiple projects. For example, KVM could be an option. And last but not least, the performance impact of some of these solutions can be really overwhelming. I suppose not everyone would be willing to buy a phone which boots in 10 or more minutes. I've been doing that. If we look at the problems, there are several classes actually, not just individual problems. If you look at how we classify data, how data is used inside the kernel, there are multiple ways or multiple angles to look at it. You can look at it whether it's going to become immutable after a certain point of time so you can consider it okay. I might have a transient, but after this transient data will not change anymore. Or it might change indefinitely, maybe not with very high frequency. But you can never consider it as constant. Plus, the way the memory is allocated is also playing an important role in this. You have usually parameters which have a size which is known at compile time. So you can, for example, put them in a read-only after-init section. That's what is happening with many kernel parameters. But in other cases, like IME measurements, they keep on coming. So you do not have a fixed allocation for that. The way also the memory is modified might make a difference in the way it needs to be protected. One example is if you load a Selenux policy DB, you just have a burst when data is loaded from file, processed, stored in memory, and that's it. After that point, you can consider it as a constant. And also the granularity at which data is allocated and treated can play a role in the classification and way of protecting it. Coming to that, as I said, the MMU is the primary mechanism for enforcing the protection. And the MMU, no matter how good it is, it has some interesting constraints. First and foremost, the fact that it works at page level. Now, we can have different page sizes, but that still doesn't change the problem that MMUs has a fairly coarse granularity. So that's something that we have to consider in our solution. Plus, not all the properties that we would like to consider, as we have seen in the previous slides, are represented by current generation of MMUs, as far as I know. And MMUs, again, as far as I know, they also have settings which are always reversible. So you can never say that you have protected something for good. If you assume that your channel is getting compromised, then the attacker gains or can gain the same level of capability that you had, and it can unprotect the memory that you were hoping to preserve. That's why, for example, there are strategies where the last stage of protection is delegated to a hypervisor instead of using the kernel. Because the hypervisor has a separate context which is not directly accessible to an attacker who has compromised the kernel. Then one more dimension of the problem is the fact that the kernel, for very good reasons, makes a large use of pre-coded data structures. And these are really pervasive. And what we would like to do is to somehow preserve the spirit of these data structures, but somehow differentiate between those which are meant for being used for protected data and those which are meant to be used for non-protected data. And as I said, there can be very interesting outcome if you don't do it right. Like you have very sensitive data which suddenly becomes too slow to be accessed in a reasonable time. Now, one problem of dealing with a real life system, like it would be a mobile phone in my case, but not necessarily just that, is that you can have different types of concurrency which can be exploited by an attacker. For example, you might think that you have a core which is performing, let's say, secure operation where it's modifying some sensitive data and somehow this core is interrupted and the context it was working with is left available to the attacker. Or another case could be that one core is performing this operation, but the context is not accessible only to that core and the attacker can take over a separate core to perform a sort of a race-based attack when it just tries to modify the interesting data as fast as he can, hoping to hit the window when the data is writable. And then we also have a special alising where the same physical memory can be accessible through different virtual addresses with different properties. Some of those are intended, fixed map and fixed map. Actually, the fixed map is really meant for doing that. So what you want to do is to be able to have some sort of filtering where you decide upfront what could be mapped differently and what not. And finally, but I will talk about it more later, there can even be attacks on the page table which really try to modify the properties of the memory being accessed. The next problem is you might be successfully protecting some data, but you are just moving the target away. So if the data cannot be altered directly, the attacker might try to modify the metadata which is tracking the data you are protecting so that suddenly it behaves differently. It's seen differently by the kernel and certain types of operations become possible. Yeah, for example, you might have thought that some memory was read-only. You have marked it as read-only. You are protected it as read-only. But if the attack can successfully re-qualify it as writable, then a class of write operations will succeed on that. Or another approach would be that the memory is forcibly freed so that there's a wealth of dangling pointers left and the attacker can try to reallocate that page and that address is to modify implicitly all the interaction from the pointers. So what I came up with so far is several different ways of declaring how memory should be treated and that depends also on the way it is allocated. On the right hand, sorry, on the left hand side, you can see what is available currently in the kernel and basically two. You can declare some data as constant or you can declare it as read-only after in it. But this is something which is allocated at link time. What is still not available is a possibility at link time to declare some data which you want to be protected to some degree but can still be modifiable. And on the right hand side, there's a completely new set of declarations which are meant to provide support for a dynamic allocation. I will go more about them later. So where is this coming from? The maybe trivial observation but I think fundamental is the fact that whenever you have some memory which is classified through some metadata, the metadata can be attacked. But if you start classifying the memory based on its address in a way which is defined in the build time, then it becomes much harder for the attack to succeed because the property of memory is intrinsic in its address. And that's how data is usually accessed through pointers. Because of the constraints I explained earlier from the MMU, there are also limitations about granularity. Data must be aligned to page size and it must be multiple of page size because that's how the MMU works. But if you satisfy those constraints, then you can exploit some interesting fast verification like what I put in the example at the bottom of the slide, where basically on the fly I can always perform a quick verification before accessing memory in a certain way. So link time allocation are easy because as long as you prepare your linker script meeting these requirements of alignment, the linkers will do all the allocation for you. What is more complex is the handling of runtime allocation because those are less codified in the way Linux manages memory. But what really would be nice to do is to be able to compare quickly one variable against the beginning and the ending of a section which contains it to see or to infer at runtime what are its properties. And this is where really the linker scripts comes to help. Now, what is difficult about runtime allocation? In some cases, like, for example, on ARM 64, you cannot just on the fly change properties of a memory page without first tearing down whatever mapping was preexisting. And there are also size constraints like you cannot use Kmalok because Kmalok has size limitations. And similarly, Vmalok is not very suitable because Vmalok does its best to optimize the way it allocates memories. And the only thing Vmalok knows is about the higher and lower range of addresses it can use. So this is the high-level solution I was talking about. If we carve out a sub region from the Vmalok address space and reserve it for performing these protected allocations, then what we can do is let regular Vmalok work on the remaining part of the address range and do ad hoc partitioning of what we have carved out. It is surprisingly fast, or it was surprisingly easy. Vmalok does not support being told directly what is the allowed address range that you can use for allocation, but I think it's called underscore underscore Vmalok node range, which supports these parameters. So the idea is exactly that to create sub areas within this portion which was carved out and encode in each of these address range properties that we want to associate to that data. Other constraints are that if we want to consider possibility of releasing this memory, we want to see what gets allocated inside each page so that, for example, a specific use case will not be interleaved with another use case. Like if you have a driver A and driver B, you do not want them to share the same page because at some point driver A would like to release this memory so it cannot be locked down by driver B still using it. One reason for not just using plain Vmalok is the fact that depending on your allocation pattern, you might have allocation of very small chunks of memory performed frequently, and Vmalok will always try to allocate a whole new page, even if you're using a few bytes of that. And the problem there is that it's likely to really trash the TLB. So you will incur to performance problems if you do not somehow compact the smaller allocation. To preemptively protect the allocation against a class of attacks which might try to trigger use after three patterns, instead of having fine-grained allocation and releases, the best strategy is to just keep the memory allocated until the whole use case is completed. So, for example, a driver, a module might start allocating memory, use it, and then release it once it's unloaded but not before so that it's even harder to exploit the user after three bugs because that memory will never be available to the rest of the system for the allocation. This leads us to having memory pools. The memory pools properties are inferred from the region where they are allocated. And this property, for example, is the data associated to a memory pool read-only, is it right rare? I call it right rare because it's something which incurs into a performance sheet so it cannot be performed very frequently. Can the memory be destroyed or will it stay allocated as long as the system is executing or what's its minimum alignment? In this case, the VMA is the basic allocation unit. It might in some cases be one page size but in other cases it might be larger. And the problem we have now created, a new problem, is the fact that this metadata is the potential new target for an attack. For example, an attacker might be tempted to turn a read-only pool into a writable one. So, it would be nice if we could use the same concept we have used so far to protect the metadata itself. And if it were once, we're not using it again. So, the next approach is we can also encode those properties for, okay, this is a pool structure. You can see that there is some property which is encoded in its address and some property which is inside the part of the structure, their fields. So, those are the ones we would like to write protect. So, the idea is pools cannot be considered as constant but they could be considered as a write rare. So, they can fit nicely in the area which we have already reserved for statically allocated write rare memory. And we can further subdivide that so that to each range you can associate some additional properties. As you can see, this is basically a replica of the previous slide I showed. The only difference is that the previous one was referring to addresses used for dynamic allocations while this one is referring to addresses used for allocating pool structures. So, one constraint is because of this design, you cannot dynamically create or delete pools. But typically, a pool is meant to support a larger use case. So, a device driver might need one, two, three pools, and it might need a variable amount of memory from each of these pools. But the number of pools it needs should be quite well defined. So, I don't think it's a big problem, especially not if you are dealing with a system which has been designed for a very specific use case. And that is, in my case, for mobile phone, it could be embedded device, but even if you think of the cloud, it's normal behavior to have different types of VMs in the cloud for specific use cases. So even those can be treated as really custom implementations. Other problem is that some memory is wasted, probably not so much. Usually the amount of data that one wants to protect is not huge. And anyway, the memory allocator is already packing data together. So, there is probably some padding left, but not much. The maybe biggest problem is the fact that now we are constraining certain type of allocation to fit within a memory address range. And for the vast majority of the use cases, this should work. But there's at least one which I have identified, which eventually will not work with it, which is IMA, because IMA is constantly allocated more and more memory for storing measurements. One possible solution there would be to set low watermark and plan a reboot of the system. In general, a system which is deployed for a real use case needs any way to survive a power cycle. So that shouldn't be a huge issue unless one requires a really high uptime. And now we have maybe the more interesting type of metadata based attack, which is the page table. So as I said at the beginning, every time you protect something, you are basically moving the target somewhere else. So if we have managed to secure the data, secure the metadata, what is left is the mechanism which is supporting the mapping of physical pages to get our addresses. And that's the page table. The simpler case is you have a physical page mapped somewhere with some properties, the attacker manages to go to the page table and change the page table entry to values which are most suitable. Mitigation there is applying the same strategy also to the page table. So right protect also the page table. That will have a certain speed impact. But if we think about protecting pages in the page table, which are used to map data which doesn't change much, it's going to be very infrequent from changes to the PTEs. So that should not be a huge impact. The last year case is when a page, physical page which was mapped at a certain address with certain properties gets remapped somewhere else with different properties. For example, you have the read only page and it gets mapped as writable as some different address. That's how the fixed map works, but nothing prevents the attacker from creating own fixed map. The problem here is that if we start to protect all the pages in the page table, because this can happen at any address. So if we start to protect in that, then we are basically adding overhead to every modification of every page table entry in the page table. And that's probably not acceptable. One mitigation for that is to apply again the same strategy which is for a system which has a specific purpose, it is possible to perform profiling and figure out roughly what's the maximum number of physical pages that will be used in the page table and allocate them from a fixed address in physical address range, which would allow for a quick verification and consistency check between the mapping in the virtual address space and the physical pages. Another option would be to keep at least most of the page table unmapped most of the time. The MMU does not need the page table to be mapped. The MMU will access it anyway. The problem is that some existing Linux code relies on properties through the page table, so not every part of the page table might be easily unmappable. But that at least would reduce the attack surface by making it harder for an attacker to just write a new address, a new mapping in some random place of the page table. And of course we could also try to perform a combination of those. Now, this is the high level thinking behind this solution. The backing can be implemented in different ways that I will try to describe. So the first one is to just use the kernel as it is on regular hardware and basically implement what I've described so far. The solution that was actually recommended to me on the mailing list was that physical pages would be mapped as read only in the primary address space and then there would be secondary address space where these pages would be mapped as writeable. And the secondary address space would be activated only when modification is needed. This is good in the sense it doesn't have additional dependencies. Once you have switched address space, you do not have to worry about modifying code because you have just changed the properties of the mapping and the code will happily run on the new mapping as long as it can write what it wants to write. But the big problem is that since all of this is just happening in kernel, and as we said, the hardware can be always reprogrammed to behave differently. All of this can be undone. So if you are pessimistic enough to assume that the attacker has gained read-write capability in data, in kernel data, and has enough time to look around and figure out where it should write, he can basically disable all of this. Another possibility would be to use better hardware, which I hope is coming soon from different vendors. For example, we could use memory tagging, which intrinsically tries to call or data based on which code can access it, so that even if an attacker manages to gain read-write capability, the moment he uses a certain piece of code to modify data which does not belong to that code, the modified data will be tagged differently. So the next time the legitimate user of that data will try to access it, that will cause an exception. But again, we are kind of moving the target, which is if the kernel has a tagging mechanism supported by hardware, the attacker will probably try to target the tagging mechanism to bypass the tagging protection. Yeah, the context can still be subverted, because everything is still happening within the kernel context. Another option, which is what we are using in Huawei, is to use a hypervisor as a back-end. So at that point, there are two contexts. I'm not claiming the solution is perfect or bulletproof, but at least it makes it harder for the attacker to modify a certain part of the context, because that part of the context is accessible only to the hypervisor, and the hypervisor is accessible only through specific calls. And when the hypervisor is invoked, it can still try to detect if the kernel is still saying or if it has been compromised. So there's a possibility to perform additional vetting. Problems related with this solution are that switching context between kernel and hypervisor is not free. There is a delay, and also the hypervisor does not have the capability of running the same code that the kernel has, and that might also include the licensing problems if your hypervisor does not have the same license as the kernel. One possible solution which is what we are aiming for is to have a hybrid hypervisor kernel mechanism where the kernel still tries to perform most of the vetting and detect attacks, and the hypervisor does a sort of double check which means that if the kernel can detect that something is wrong, for example, a user space process has somehow from its context managed to generate some illegal right, it can try to kill that user space process. The hypervisor would be left as a sort of extreme measure if the hypervisor detects some error which the kernel did not, at that point it can even reset the device. But it's something that is supposed to happen very frequently. Yes. Finally, there is a new set of interesting possibilities which are becoming more and more available in recent times, which is to start to design also custom hardware and see if we can simplify the code. In many cases we, at least I have the feeling that we are playing with bits here and there just to try to cope with the limitations that are imposed by the current generation of hardware, but if we could implement different hardware we could probably simplify the code. And this is where FPGA may be coming to the rescue. For example, as I mentioned, trying to implement irreversible protection. Yeah, the big problem is that you must be able eventually to create your own new hardware. Not everyone can do it. Yeah, final consideration is no matter how hard is your solution you might still have to come to compromises because if you have a big data center maybe you can just scale it up, replicate it. It's not going to be cheap. But if you have a battery-powered device you might not be able to just throw more hardware at it. You might have a different sort of constraints where eventually you cannot put many more cores or you cannot crank up the speed. And you also have speed constraints. So I hope I have at least if not proposed a complete solution try to explain what are the problems that are present in this field and where the direction might take us. It's really something that I think is depending on what is your use case and what are the compromises that you are willing to accept. And thank you for listening to me. We have a bit of a long time but maybe one question quick question that we can still take before moving to the next talk. If there are no questions then let's thank the speaker again.