Ddiolch yn fawr, a chwybod i bwysig am gweithio cymryd Cwmonellies na fywch yn yr ystyried i'r gweithio. Felly, mae'r gweithio ei ddweud o'r ffwg oedd mewn. Felly, mae'r gweithio'n fwyaf, ac mae'r gweithio'r gweithio'r plain gyda'u cymryd cymryd. Ie bwysig o'r sgwyrdd cynsultant, ac mae'r gweithio o'r sgwyrdd cymryd ac ymddangosol i gweithio'r ac ymddangosol i'r gweithio'r awdau CTF. mae'r cyfnod i'r ffordd rhan o'r ferfodleddau clywedol. Felly wedi bod yn bwysig ar y ddweud. Rwy'n ganddo ar y dyfodol ymddi gwir y clywedol yma, a'r fawr i'n ffordd ar y cyfnod i'r cyrraeth. Fawr i'n ffawr i'r bwysig ar y ffawr o'r pryd-fawr a'r ffawr i'r bwysig ar y cyfnod i'n bwysig ar y ffordd. Mae'n bwysig ar y ddweud i'r bwysig ar y ddweud i'r bwysig ar y pryd-fawr in two separate parts and then we'll run through how we can defend against the attacks that we mentioned. So why do we care about any of this? Typically in a Kubernetes assessment, a security assessment in my experience, we'll start from the perspective of a compromised workload, a compromised pod. Maybe we assume that a developer laptop's been compromised, but there is still some attack service that is not accounted for. Let's have a look at what we can get from an unauthenticated perspective in the network using some more classical techniques. So we're going to start by having a look at open ports on our nodes. So if we use one of our favourite port mapping tools and take a typical worker node, we might expect something like this to show up. So as we're using Linux Kubernetes nodes, it's fairly typical to expect SSH to be open, but ports 10.256 and 10.250 are Kubernetes components. We can verify this just by jumping on one of the machines and verifying that kube proxy owns 10.256, and this exposes a healthy health check API, which doesn't really have too much attack surface, so we'll move on. Port 10.250 is a little bit more interesting, as this is the kubelet API. In modern versions of Kubernetes, this is authenticated, however, and so from a perspective on the network where we don't have any credentials, there's not much to see here. On that topic, however, if we did find any credentials, there's an excellent tool from Cyberock called kubelet CTL that actually documents this API. It's a little bit outside of the scope of the talk today. So if we move on to what a control plane load might look like in a self-managed cluster, we can see some familiar ports from the worker node. So we've still got those kubelet and kube proxy ports and SSH for administration. We also have ports TCP 2379 and 2380, which are used by the SCD theme and running on a control plane. If we're running in a configuration, we're actually running on our control plane nodes. By default, this uses mutual TLS, and so, again, not much we can gain here. The most interesting port here is 6443. This is the default port for the Kubernetes API server, and we can start learning some information. As the end map scan indicates, it's detected that there might be some SSL or TLS service listening on that port. So if we attempt to connect to it with open SSL, we can actually dump TLS certificate listening on that port. Although there's a lot of information in there, the most interesting thing to us at this stage is the subject alternative name field. So this can contain two types of information, the first of which is a DNS name, and the second of which is an IP address. So by default, Kubernetes will assign an IP address to each, or sorry, assign an IP address in the certificate to each IP address which the API server listens. So in this instance, we can see that it contains the IP address of the API server Kubernetes service, which is an information leak which could help us to determine the Kubernetes service network range. This will be important later. The API server also has one or two unauthenticated end points, probably the most common of which is the slash version end point. It's not a huge amount of information here, but it does at least tell us exactly the exact version of the cluster that we're running, which might be useful if we want to check for already known vulnerabilities or CVEs. So just to make this a bit easier, I've written a little end map script that'll tell us both the subject alt names and that version information. Also makes it a little bit easier if we're enumerating across several hosts. So one area that is sometimes overlooked with network scanning is UDP scanning. So sometimes it can be a bit slow, the nature of the thing is just a bit awkward. But in this scenario, we have a good idea of what we're expecting to be running on the other side, so we have a higher chance of success. So we can look for ports which run common networking and storage protocols. So, for example, here in the scan on screen, we can see that we have port 4789, which is commonly used for VXLAN overlay networking. We'll talk a little bit more about that later. So in this first section, all these issues have been informational. We wouldn't really expect them to be, or we wouldn't raise them as any kind of exploit really. But in this next section, we'll have a little bit of a look at some of the privatives of the Linux nodes that we're running and see if we can achieve something that we might call an exploit. So for those of you that have set up a QBDM cluster, or a cluster with a tool like QBDM, we'll be aware that before you're able to run the tool, the node that you're running on has to meet certain requirements. And this is based on the features of the Linux kernel on the node. So one example of this is the IPv4 forwarding feature. And what this means, if we turn it on, is that the Linux machine will root IP packets based on the rules it's configured with. So this will be its IP tables rules or NF tables rules. So in the words of Bory McEwn, Kubernetes is a router. And this has some implications that we may not expect. So if you consider for a moment, we have a architecture, something like the above, where we've tried to harden our cluster by not exposing our API server to the public internet. So we implemented a jump host. And how we've implemented it is we've got one network, one subnet with our bastion, and that's the same as the all of our Kubernetes nodes. Using the previous described routing functionality, we can actually add routes to this bastion that will allow us to talk to pods and services within the cluster. So let me show you what I mean. How are we doing? Everyone at the back see that? Grand, thank you. So to start with, we'll use that script I showed to enumerate some basic information about the cluster. And we can see that here we're able to reveal the first IP in the service network. So what we'll do now is make a small assumption that this network is a slash 24 network. We can increase it to a later stage if we need to, but for the time being, this will allow us to allow us to add a route via one of the nodes that we previously discovered, like so. What we'll now do is look for the commonly deployed Kubernetes DNS component or core DNS. We know this is going to listen on TCP 53, so we can scan this service range for all IP addresses looking for that port. Great. Looks like we found it. So we can see that core DNS is running on the service IP 10, 100, 0, 10. This is really powerful because core DNS contains a lot of information about the state of the cluster. So what we'll do in this next step is we'll use the wild card functionality of core DNS to list all other services within the cluster. And although that's slightly wrapped, hopefully you should be able to see that we have the core DNS service, the default Kubernetes service, and this other dashboard in the default namespace. So we should be able to just connect to that dashboard to see what it presents. Let's try it. And as we can see, we can connect directly to that service IP from our bastion without any authentication. We're going to take this a step further and query core DNS for all the service endpoints. So these are all the pod IPs that the service is in the cluster to talk to. And what this allows us to see is some of the pod IPs in use by the cluster. So we can see down here we have the 10.0.102 range IP addresses. And this allows us to make further educated guess as to what network range the pod network is using. And we're going to guess that it's using the <IP_ADDRESS> slash 16 range. And again, we can add this, add a route to this via one of our nodes. Following this, we can scan directly across this range. And this will allow us to detect all pods even if they weren't necessarily assigned to a service. So over here, we're just using three ports, but you could conduct a full port scan if you wanted to. And we can see that we found a pod IP address when port 8080. And again, we can curl it to check we can reach it. For this example, we're using the same dashboard, but with this time, we're using the pod IP address. We can confirm that we can reach that service from our bastion without any authentication whatsoever. And one slide. So you might think this is a little bit of a little bit dodgy functionality. Why does it exist? But in truth, it's actually used as functionality by some of the existing CNIs. So both Romana and Cributa make use of this. And it's with good reason because there are performance and complexity benefits to using this kind of routing over, say, an overlay network. But I'll leave you to decide whether it's a valid feature or it is indeed a bug. So so far, we've looked at layer two networks. But in the real world, it's likely that we'll have nodes deployed in different subnets, different regions, different availability zones, maybe. And so we might want to bridge our traffic over a layer three network. This is what overlay networks come in. Many CNIs these days will deploy with some kind of overlay network. And under the hood, these will use either VXLAN or IP in IP technology. So if you could consider for a moment the following architecture. Similar to before, we have a bastion host that we're asking users to pivot through. But this is similar to before. We have our Kubernetes nodes running in one or more other subnets that are not directly the same one as our bastion. So to give an overview of the IPIP protocol, we'll look at the layers two through four of the networking stack. IPIP encapsulation works by encapsulating a layer three IP packet with another layer three IP packet. In a standard pod-to-pod communication, the outer packet will contain the source node IP and the destination node IP. And the inner packet will use the source pod IP IP address and the destination pod IP address. However, if an attacker were to have access to a bastion, they may be able to forge or create malicious packets. So they may be able to change the content of any of these headers that we care about. So in order for an attacker to root to pods in our cluster, they would need to specify the right destination node IP in the outer IP packet and the right destination pod IP in the inner packet. However, they have some control over the source IP addresses. The inner IP packet source IP address is important as the attacker can set this to influence the return root of the IP packet. Let me explain that a bit. So because the Kubernetes node does not understand that we are sending it IP IP packets, we have a single-sided tunnel. It has no root or has no rules to be able to encapsulate for the return journey. So therefore, we need to find a way of returning data to the bastion host. If we set the inner IP packet source address to the attacker's bastion, when this packet gets un-encapsulated and then a response from whichever pod we're talking to, we'll use this source address as the destination. In this manner, we can achieve a form of asymmetric routing, which allows us to retrieve a response from the node. The outer IP packet source address is important as we can use it to bypass host firewall rules in some scenarios. So I appreciate that's a bit to take in. So let me give a little bit of context here. This is a proof of context script, which demonstrates the concept using the escapee packet manipulation library. We can see that in the outer packet, we're using the <IP_ADDRESS> IP addresses the source. So this is just any other node in our cluster. We can see that we're using the <IP_ADDRESS> IP address as our destination node IP. This is the one where the pod we're targeting is running. For the inner packet, we're using the bastion IP address as the source and the target IP address of the pod, which in this case is called DNS as the destination IP of the inner packet. We then assemble the packet using escapee, targeting the any any service cluster.local DNS address, hoping to achieve similar results to before. So we can see that this executes and that we send and receive normal DNS packets. If we look a bit deeper, we can see that the sent packet is IP and IP encapsulated, and our response is not. Thus showing we're able to achieve asymmetric routing and communicate with services inside the cluster from the bastion from an authenticated perspective. So not all overlay networks use IP in IP. We also have VXLAN networks. Again, looking at the structure of layers two through four, we can see that this time it's much more complicated. In VXLAN, a layer two Ethernet frame and a VXLAN header is encapsulated in a layer four UDP datagram. The header fields that we care about in the outer IP packet are again the source node IP and destination, which in the normal flow is the node IP. In the inner IP packet, the pod IP will be the source pod IP and the destination IP address will be the destination pod IP. However, in VXLAN, we have some additional headers. So in the VXLAN header, we have the VNI ID. Whilst used in other VXLAN implementations in all the Kubernetes CNIs I've seen, it's hardcoded to one. We also have this concept of VTEP, which is the VXLAN tunnel endpoint. Unfortunately for us, this is a randomly generated hardware address. And so to attack against VXLAN in a reasonable time frame, we need to leak this in the cluster. This is annotated on a node resource object, so the permissions we would need would be get nodes. So thinking back to our network architecture where we have that bastion in a separate subnet and we have our nodes in adjacent subnets, let's have a look at which headers an attacker would want to modify. So in order to route to the right node and right pod, the destination IP addresses in both of the IP packets will need to be set correctly as before. And as before, we can set the source IP address in the inner IP packet to achieve asymmetric routing. We can also set the source IP address in the outer IP packet to that of another node to try and bypass any host firewall rules that prevent us from sending packets to that node. An attacker can fairly safely just hard code the VNI to one, although if they know that they're targeting a CNI that uses something different, they can potentially modify it. And as previously mentioned, they would need to leak the VTEP address from the cluster via another method. So let's have a little bit of a look at how that looks in a proof of concept script. So in the script, we set the outer source IP address to 101230.10, which is the IP address of another node. And we set the outer destination IP address 2.20, which is the target node. We set the VXLAN port to 4789, which is well known, and we enumerated during our n-map script earlier. And we set the VNI to one. We include the VTEP address that we leaked from the cluster, and we set the source IP address of the inner packet to our bastion. And similarly to before, we are going to be targeting the core DNS service and use the service address of that pod. We then construct the packet using scapey and send to our cluster. We can see we're able to certainly do so, and that we are able to send a request in the right format and receive a response in the right format. If we look a little bit deeper, we can see our request is VXLAN encapsulated as expected, and our response is not. It's just a standard DNS response. So showing this shows that if we have knowledge of the VTEP address of a node, we can communicate with pods and services inside our cluster from an adjacent subnet. So the eagle eye amongst you will have noticed that in the proof of concept scripts, they're run as the root user. Although we use it for the proof of concept, we could use the bash dev TCP and dev UDP sudo devices to achieve similar results. So we don't necessarily need the root user to achieve this attack. In order to mitigate some of the level two attacks discussed in the first section, I would strongly recommend that you isolate any bastion hosts or any untrusted workloads in different subnets to that of your nodes. If we do that, it also means that we're able to write firewall rules, strict firewall rules, to prevent any kind of other traffic traversing between these machines. So, for example, in the second half, in my lab environment, there were no rules between these two subnets to prevent that traffic, which is one of the reasons why we're able to do it. In terms of Kubernetes native things we can do, network policies also help us here. We can implement policies between workloads in our cluster, so between individual pods, and this will prevent us being able to communicate with pods from outside the cluster, so we wouldn't have been able to curl that unauthenticated dashboard. Additionally, we can also add network policies around Kube system if we wanted to prevent access to privileged components. So if we added a network policy to prevent we can add a network policy to prevent access to core DNS from outside the cluster, and it's probably a good idea in terms of general hardening. I mentioned a couple of times that we could set the source IP address of the outer IP packet to avoid host firewall limitations. This is more commonly known as IP spoofing, and routers often have protection against this, but it's not always turned on. So in my research some CNIs needed this, some didn't, and so you may want to investigate turning this protection on to prevent these kind of attacks. The Linux kernel actually has a feature to prevent some of the asymmetric routing that I mentioned earlier called reverse path filtering. Most distributions don't actually enable this by default, so it's either off or in a permissive mode. You could experiment with setting this to a strict mode so that these kind of attacks are not possible, although it's unclear whether this will affect any of the Kubernetes functionality, so you should test this well. So I've released the Nmap Kubernetes Info script on GitHub and the Kubernetes, the other proof of concept scripts that you welcome to use and contribute to, and that's my Twitter handle if you want to follow me, but thanks for listening. I think we've got time for questions if anyone has any. Yes, down at the front, I think we've got a mic. So the question was, could I use an internal IP address to bypass network policy? Good question. I don't think so because I think that in order to bypass network policy, you would need to be able to set the IP address of the inner packet. I guess it would be kind of almost like a CSRF situation. If you had a workload where, because you'd probably also not be able to make a connection, so you'd need something that accepted UDP packets that you could make a permanent request, it would be quite convoluted, I'm not sure. If that's it, thanks very much.


So I'll start by reminding you where we left off last time. So we're considering a stratum of a Boolean differentials. So the stratum is some set of a Boolean differentials x omega, which we can draw as some collection of polygons with edge identifications. And we have local coordinates that we've written in terms of their real and imaginary parts. And we're thinking about the dynamics of gt, which is e to the t 0, 0, e to the minus t, which acts linearly on these polygonal pictures. And so we have some sort of guess was that omega and x prime, omega prime, the same x j, so real parts of coordinates, the gt orbits converge to each other. So these get close, exponentially fast, as t goes to infinity. We may be assuming something about the gt orbit, like it doesn't just go off to infinity, but something that would be generic. And this guess came from thinking about this picture where we wrote the coordinates as a matrix like this. And locally, the action was very simple. You're just acting by this 2 by 2 matrix on each coordinates, just the action of gl2 are on R2. And so you see that this contracts the imaginary parts. So somehow it doesn't really matter what the imaginary parts that all get sucked in together exponentially fast. Except there's a change of coordinate matrix if you come around and come back to where you started. And this was a matrix in gl and z that's called the consavage storage co-cycle. And it's sort of the non-trivial part of the dynamics, because this is evidently very easy to understand. And it's the linearization of the cut and paste. And you can also think of it as follows. So you have your stratum, and then you have this gt orbit. So you say maybe it starts off here, and then it comes back close by. And you think about parallel translation of some homology class. So here I'll fix some gamma in h1 of the surface. And as I act by gt, I'm changing the metric, but the topology isn't changing. So in other words, I can just sort of take this homology class along for a ride. And in fact, I could take a whole basis of homology classes. And I can transport them all along here and sort of see what basis I get. And I get this change of basis matrix, which is exactly what this consavage storage co-cycle is. So it's a monodromy matrix. Longness, you can think of closing up the path. And then it's literally a monodromy matrix, if you're used to thinking about monodromy. OK, so we want to show that the consavage storage co-cycle somehow loses out to this very strong exponential term here. It's powerful, but not as powerful as these exponentials. And to do that, we're going to focus on just not the whole matrix, but just one homology class. So we're going to take one homology class, and we're going to parallel transport it around, and we're going to see how fast it grows. And although the asymptotics of this doesn't depend on the metric, our study of this problem will depend on picking a nice metric with good sort of analytic properties. And that metric is called the hodge norm. And versions of this are used whenever you have a family of Riemann surfaces or a family of algebraic varieties. You're studying variations of hodge structure. So it's a pretty important thing in general. So the background maybe is we can start. So let's take x with each one of xc. So first, homology with complex coefficients. And I can write this as h10 plus h01. So this is the hodge decomposition, valid for all scalar manifolds. Also, this is the space of a Boolean differentials. And this is its complex conjugate. So the holomorphic one forms and the anti-holomorphic one forms. And I can think about the sort of usual cup product or intersection pairing, which just says I have two homology classes, 801 and 802. And I calculate their pairing by omega 1, which omega 2. So this is something topological. This doesn't depend. You can do this for a topological surface. It doesn't need a complex structure. So just a new surface without a complex structure you can do this for. Well, perfect question. So you can define it on the whole thing. And it's just some topological thing there, right? It's just something you can do this even for differential forms. I don't know if we holomorphic. But we can think about what this looks like on 1, 0. So for example, I'll claim that if eta is in h1, 0, x, then eta, eta is greater than or equal to 0, with equality if and only if eta is equal to 0. And actually, you can be more precise, eta is what we've been calling the area. So if you represent the appealing differentials in terms of polygons, this is just the area. And the reason why, so if locally, we pick some coordinate where eta is dz, and I write z is x plus iy, then i over 2 eta wedge eta bar is dx. So similarly, you can show that this pairing is negative definite here. So overall, it's some Hermitian pairing of signature gg on this whole vector space. And it's important to realize that as I change the Riemann surface, for example, by moving along a gt orbit, this of course doesn't change, because this is just apology. The surface is not changing topologically. But these do change, because it depends on the complex structure. So you have what's called a very, this is the Hodge decomposition, then you have what's called a variation of Hodge structure. So you have these two spaces whose direct sum is the whole thing and they're sort of moving around. And so that means even if you picked a class here, when you change the Riemann surface, it would sort of move. So you somehow don't really have a, you do have a real positive definite inner product here, but it doesn't immediately help you. But there's a pretty easy way to make this help you. So there is an isomorphism from h10 x to h1 xR that sends eta to the real part of eta. Sometimes this is called the Hodge representation theorem. So for example, the fact that this is onto says for any real homology class, you can find a holomorphic one form with that real part. Or if you think about it the other way that this is injective, it says that if the real part of a holomorphic one form is 0, then the one form must be 0, which is pretty intuitive. And so we can define the Hodge norm h1 xR via this isomorphism. So maybe I'll give this a name, I don't know, h. So in other words, if I want the Hodge inner product of two real homology classes, then what I should do is I should look at the abelian differentials that give rise to them and then do this to them. Question so far? So this gives a family of norms and it varies. It changes, but it changes nicely as you move the Riemann surface. And there's also a version on complex homology. What you're doing up to a factor of two that I'll never remember is you're just changing the sign here. So you have an inner product here and the negative of an inner product here and they're orthogonal, so you just change the sign and then you get an actual inner product. But it depends on the Riemann surface structure. So now I want to start thinking about how Hodge norm varies along here. Oh, and I should say, of course, there's a dual norm on h lower one. I'm actually sort of in the motivation I was thinking in terms of homology because that's more intuitive, but then you actually work in terms of co-homology. And it's sort of no big deal. So I want to think about how Hodge norm varies as you move along here and there are two special homology classes or co-homology classes that we'll start off by considering, namely the real part of omega and the imaginary part of omega. So I want to consider how their Hodge norm varies. And this will be the one thing that's really easy and transparent to do with Hodge norm. So it's a good warm up. So I'm going to consider the Hodge norm of, let's say, the real part of omega varies along gt x omega. And actually, I'll calculate it exactly. And just to fix the convention, let's say, the area of omega is 1. So let's say gt of x omega is x prime omega prime. To start off, I want to think about what co-homology class is omega prime. And this is actually really straightforward because remember, we're just sort of acting on the real and imaginary parts. So for example, you could think, what are the periods of omega prime? Well, the periods of omega prime are the periods of omega, except you've made the real parts bigger by e to the t and the imaginary parts bigger, I mean, smaller by e to the minus t. So in other words, you've just scaled the real part of omega by e to the t and the imaginary part by e to the minus t. So in other words, sort of the class of, well, maybe I should say t instead of prime. The class of omega t is e to the t times the class of omega plus e to the minus t times the co-homology class of the imaginary part. These are the periods of that. So this, you could think this is gamma i. And then this sort of xj plus iyj is the integral over gamma j of omega. Yep, yeah. Like if you take a differential form and you multiply it by 2, it's integral over whatever you're integrating it over increases by 2. Well, so what I'm saying is, so we start off not knowing what this is. Oh, that's going to be easy to figure out. And we say, OK, I don't know exactly what this is, but this is some differential form and I know it's periods. It's some co-homology class and I know it's periods. So which co-homology class has the right periods? Well, it's the co-homology class of omega except I've scaled the real and imaginary parts because that is a co-homology class and it has the right periods. I guess maybe a missing piece of this discussion is that h1, say xc, is h1 xc dual. So a co-homology class is determined by its periods. OK, so now this is going to be easy. So I want to know the hodge norm of the real part of omega. So oh yeah, this should be an i. Yeah, thanks, Dore. Anybody else found any other horrible typos? OK, so I want to compute the hodge norm. So what am I supposed to do? Where is it? It's like right here. Here it is. So I'm supposed to figure out what the abelian differential is representing that homology class and then just take its area. That's what this is saying. So the abelian differential, xt with real part, the real part of omega, is, well, so here I have an abelian differential and it has this real part. So I just have to scale this. So it's, I guess, e to the minus t omega t. Now area is preserved by the gt action. So omega t is the area of omega.  And this hodge norm, we said, is just computing area. So in other words, the hodge norm of real part of omega t omega on xt is e to the minus t. No, it should be e to the minus t. You're supposed to wedge with the conjugate but then actually have to take a square root somewhere. Norm is inner product with itself and then you take a square root. OK. And so similarly, if I use the imaginary part of omega and I ask for its hodge norm, hodge norm is e to the t. So we do have some cohomology classes whose size grows very, very quickly. But somehow, they're the expected ones. We completely understand what's going on with the real part of omega and the imaginary part of omega. That's always the part where we have a precise on the nose sort of trivial understanding. And really, the goal will be if I take some other cohomology class that's not one of those, can I understand how its hodge norm is changing? So I'm going to denote hodge norm on xt by norm sub t. And we have the following theorem of Forney that says, let c in h1 x are, OK. So c's going to be, instead of using cohomology, I'm using cohomology. And I just want to parallel translate this and see how it grows in hodge norm. And I'm going to let alpha t in h10 xt such that the real part of alpha t is c. We're not surprised to see this play a role because this is sort of what shows up when you, in the definition of the hodge norm. Then d over dt of ct squared is minus 2 times the real part of some form called the b form, where the b form, so sometimes it's called b sub omega for alpha theta is i over 2 times the integral of alpha wedge theta omega bar over omega. The derivative of the norm of c, yeah. So c is not changing. I put the subscript in the wrong place, thank you. But the norm is changing. So it's sort of interesting, right? Alpha t is expected to tell us the norm of c, but it's actually also telling us the derivative of the norm. I don't think b stands for anything. So this is certainly a Beltrami differential. And Teichmuller theorists will recognize this as the formula for the derivative of the period matrix. And the proof is identical to the proof of the formula for the derivative of the period matrix. So in some sense, they must be totally equivalent, but it's actually easier just to derive this than it is to sort of first derive the proof for the period matrix and then try to come up with sign. I'm not even sure anybody's written down an exact way to get one from the other, although they must be totally equivalent. OK, so by the way, you should at least type check this. This is type dz, dz, dz bar, dz. So two dz's cancel, and this is type dz, dz bar. So this does integrate. So OK, this is some formula in terms of differentials. And I thought about proving it for you, but I decided I'd spare you. The proof is not so hard. I could do it in 10 minutes. This is just a question of, at the end of the class, you might not remember anything other than I have computations that seem sort of unfamiliar to you. It's the sort of proof that I think even if you know Taikman theory, you've got to go and sit down with for an hour to try to imprive it to get in the actual meaning from. Oh, could I re-derive those formulas? Yeah? OK, so here I was able to exactly give a formula for how the hodge and arm is changing. In general, you can't do that. The variation of hodge structure is considered a very mysterious thing. Somehow, it's always enough to understand the variation of hodge structure. It encodes everything about how the Riemann surface is changing. But in a very mysterious way, the periods of all abelian differentials or another way of putting it is how this hodge decomposition varies. If you know the periods of all holomorphic one forms, then you know the Riemann surface. That's the Tarelli theorem. Yeah, this tells you to first order. There is no GT. There is GT. XT is defined to be the Riemann surface you get from GT. So I'm keeping this convention here, that GT x omega. So this is when C is some very special homology class. So these are two special choices for C, the homology class. I want to understand how it's changing. And then what's going on here is now I'm going to pick some other C. It's not the real part of omega. It's not the imaginary part of omega. It's not some linear combination of them. It's just some random co-homology class. It's not. It's just an arbitrary co-homology class. Yeah, so let me redraw the picture. But then C is co-homology. Yeah, it's independent of the complex structure. The hodge norm depends on the complex structure. There's a T here. So the definition of this hodge norm is you take the holomorphic one form whose real part is C. And then with respect to XT, with respect to the complex structure at time T, and then you compute the area. Question? No question? OK. OK. Other questions? Um, yeah, but somehow it doesn't help to think of it that because it's very hard to compute this guy. Like, this is a very analytic formula. I don't really know what alpha T is, but it's something. I mean, this is not unfamiliar to an analyst, right? There's some quantity you don't know, but you can understand its derivative in terms of what that quantity is. So now you're going to be able to, if you understand what it starts, and you understand its derivative in terms of where it is, you'll get some estimate on growth rate. Yeah, yeah, and it'll be a super easy one that doesn't even bear writing down because we're not going to use very much about the growth rate. So it's a good one to use because we can compute a derivative. And maybe I'll write down one more thing and then we'll continue this discussion because then it'll be clear why this is so good. So let me write a corollary for this. So rather than compute the derivative, it's more helpful to compute the derivative of the log if we're going to be studying exponential growth rates. And this is minus the real part of this guy here of CEC. So I have some formula for the log. And I'm not going to do these computations because I don't think it would help you to see it, but it's very easy to see that this is less than or equal to 1. There's some Cauchy-Schwarz argument. And with a quality, or let me just say with strict equality, quality if with strict equality with less than. So you don't have equal to except in the with strict inequality if C is not proportional. So C is not in R times the real part. So we have that one homology class which grows at rate e to the t, which is enough to compete with the e to the t in that matrix e to the t 0, 0 minus e to the t. And in fact, if you think about it, it had to be that way because it sort of balances out with that. But other than that, the derivative of the log grows strictly less than 1. And that's enough to tell you you get a smaller order exponential growth rate. So maybe we'll just recap the discussion. Yeah. I mean, it's obvious that I didn't do the computation. But it's essentially when does equality hold in Cauchy-Schwarz? OK, the actual way it ends up happening is that alpha t is not proportional to omega t. That's the way it ends up showing up in Cauchy-Schwarz. So this condition is very nice because it's independent of t. Yeah, yeah, this condition is independent of t. So if you start off with this condition, you keep this condition. This condition, which we already know because if you start off with c being a multiple of the real part of this, then that'll continue. I mean, that doesn't change. Yeah, there's an identification provided by this parallel transport. So remember, the picture we have is something like this. So I start here, and then I wait until I come back. And as I change the complex structure on x t, the homology isn't changing. So a homology class or a co-homology class can somehow come along for the ride and be parallel transported. Technically, there's something called the Gauss-Mannon connection. It's a flat connection that allows you to parallel translate. But it's really easy. That makes it sound more complicated than it is. You parallel translate along the loop. And then when you come back close by, you also have a comparison. On the one hand, you parallel translate. And on the other hand, the bundle's locally trivial. And your goal is to sort of compare those. And what we're doing is, actually, that's a really hard problem. And it's not easy to know what to do. So we're doing something sophisticated by saying, oh, we're going to pick the right norm. And we'll instead understand just infinitesimally how the norm grows. No, no. There are other ways of sort of doing this sort of thing, like using Teichmeler theory. But everything uses something a bit sophisticated. I mean, essentially, we're understanding this matrix as the linearization of cut and paste. And there's no, except in very, very special cases, there's no obvious, it's not super obvious how to do. OK, so yeah, the recap is we show that if you take some homology class and you parallel translator, it doesn't grow very big. So we had this picture that looks like e to the t, 0, 0, e to the minus t times x1, xn, y1. And then this can save a short co-cycle. And this is given by just parallel translating. What? Parallel translating is just the homology class comes along for the ride. So let me draw a picture. It's a trivial bundle. It's a trivial bundle. So here I have sort of x0. And here I have, I don't know, x1 half or something. And I got this just by sort of continuously deforming the metric. Well, the homology of the surface hasn't changed. So what's the parallel translate of this curve gamma? It's the same curve. You've changed the metric. The complex structure is changing. Yeah, OK. So the metric and the complex structure are changing, but the topology isn't changing. But we don't know how to do that. No. I mean, I'd be happy if it was more elementary also, but this is somehow a subtle point. And actually, often I don't do this when I teach mini-courses. And then I've been getting complaints that say, you make everything seem really easy. And then I try to read papers. And it's a really hard subject. I can't read any of these papers. So I'm trying to show you a little bit of the actual meat because I don't know how. I mean, I could with the computer, I could approximate it. I don't think it's going to save you anything because to write down that, to find the basis, especially with the real imaginary parts, you're going to need the period matrix because that basis depends on the period matrix because that's the complex structure. So then you're going to have formula with period matrix. And then you're going to have to either show the growth rate of the period matrix along the cycle, which we don't know how to do, or you're going to take the derivative of the period matrix, which is, in fact, how to explain that's what's going on. Or we see the formula. This is the period, the derivative period matrix. In that formula for alpha t, you're trying to solve for alpha t because of dr, t, alpha t. First term is going to be easy. That's how you get the derivative. That's why you're restricting yourself to the first term because finding the other terms can become a very global problem. OK. So essentially, we've shown that this matrix, except for part of it relating to the real part and the imaginary part, which is sort of obvious, when we had this guess about two things getting close, we had some restriction that they had the same real part. So this is somehow not too big. It's pretty big. It can be exponentially big. But except for the sort of obvious part of this coming from the imaginary part of omega, this is somehow a smaller exponential order than this. As long as your geodesic recurs, because somehow if your geodesic went straight out, you'd always have strict inequality, but this sort of might tend to 1. But if your geodesic spends a lot of time in a compact set, then there's some bound in the compact set, and then you get this actual contraction. So what you get from this, so what the profit is from this analysis, so the way a dynamicist would say this is GT is non-uniformly hyperbolic, which is sort of saying there are these stable manifolds with the same real parts. And when you apply the flow, they get close together. And the non-uniform refers exactly to the fact that if you just go out the cusp, you don't know what the contraction is, because you just have the strict equality. And I mean that could go to 1 as you go out the cusp. And you should compare. So the easiest hyperbolic system to compare to, if you're not a dynamicist, is the action of 2111 acting on R2 mod z2, which is just the torus. So here you have a contracting eigendirection and an expanding eigendirection. So at every point, you sort of have some expanding directions and some contracting directions. Similarly, this is like having the same real parts. Everything gets sucked in together.  I'm putting a few things under the rug. But say if there's, no, no, it does follow. It does follow. Direction is omega and the other directions are contracting. No, no, no. The expanding directions are all of the directions where you change the real parts, because they get hit with the e to the t and they can save at church. Coast cycle isn't as strong as the e to the t. The contracting directions are the imaginary parts, because they get hit by e to the minus t and they can save at church. Coast cycle isn't as strong as e to the minus t. So anyways, the main point I want to make is these are very chaotic dynamical systems, ones that are hyperbolic. So in particular, you get that GT acting on the unit area locus in some stratum. So the locus where all of the surfaces have the same area. So I said before, this has some measure, which is finite. So this is actually ergodic. And roughly, that follows from hyperbolicity from what's called the Hopp argument, which is a standard way to prove hyperbolicity in this context. OK, so these estimates are due to Forney. They're relatively recent. Ergodicity goes back way before that due to Mazur and Beech independently. And I've actually never read Beech's proof, but Mazur at least used Teichmeler theory. As I said, these aren't really such easy problems. It's helpful to have some technology to use. It's related to a Nassav. Yeah, you do have a decomposition of the tangent bundle. A Nassav generally refers to something stronger like this, where you have uniform sort of hyperbolicity in a very nice way. This is sort of a weaker form of hyperbolicity. Other questions? OK, so that concludes the section of the mini course on the dynamics of GT, which, as I said before, is sometimes called the Teichmeler geodesic flow. The details won't be important for the rest of this course. I'm not going to talk about Hodge-Norm again. That was just to sort of give you a flavor of some of the meat that goes into understanding the dynamics. Now I want to talk about, rather than GT, all of GL2R. And I think maybe I'll get right to the point with the recent big theorem, due to Eskin Mirzikani-Mohammadi, which says GL2R orbit closures are manifolds. Yeah, the fact that orbits are manifolds is trivial, because they're just modeled on GL2R. Thank you. GL2R orbit closures are manifolds. So you look at the GL2R orbit. The GL2R orbit contains the GT orbit. This is very chaotic thing. So usually, GT orbits on their own are dense. So in particular, usually, GL2R orbits are dense. But they're not always dense. Last time we talked about, very occasionally, they might be closed. And then the surface satisfies the beach dichotomy as very special properties. So this says the orbit is always, it might be dense, in which case the orbit closure is everything. That's a manifold. It might be closed. That's a manifold. It might be something in between, but it'll be a manifold. And this is something you should pause to appreciate, especially if you're not in dynamics. On the scale of real analysis to complex analysis, where in real analysis, everything is false that you wanted to be true. Functions are not differentiable at any point, et cetera, et cetera. And in complex analysis, everything that's miraculously true is true once differentiable implies infinitely differentiable. Dynamics falls extremely far in the real analysis side. People don't prove theorems like this. This is on that spectrum. This is a complex analysis style sort of statement. People don't prove things like this in dynamics very often. They show that orbit closures can be fractals of arbitrary house dwarf dimension. That's a typical statement in dynamics that you've sort of not along to. You see this one, and you're like, what is going on here? And so I'll tell you a little bit about what's going on here. First of all, though, I just want to finish this statement, because it's actually even stronger than this. So there are manifolds cut out in local coordinates by linear equations. Yeah, so you have these local coordinates given by edges of the polygons. So you're cut out by, so you're even locally a linear. This is a really hard theorem. This was one of the big things for which Mirza-Khani was a word of the field metal. So this is a 200-page paper plus 100-page paper building on a decade of very active work in two different fields. So I'll give you examples in a minute, but first of all, what inspired them to try to prove this? So yeah, the fact that we said the stabilizers are discrete. Yeah, we talked about that. It's essentially coming from period coordinates. The fact that period coordinates are coordinates will tell you an orbit locally looks like GL2R. Well, so for example, you could think about, would this be true for the GT action? Like, what if I just look at GT orbit closures? And there, the answer is no. GT orbit closures can have any host or dimension in the fractals. The comparison is that you look at geodesic flow on a hyperbolic surface, on the unit tangent bundle to a hyperbolic surface. And there, it's a theorem that the closure of a geodesic can have a host or dimension anything between 1 and 3. It's a theorem due to, I don't remember who it's due to, maybe somebody like Carolyn Syracuse. I don't know. Anyways, it's been known for decades, I think. So really, dynamics is very complicated, right? You build, essentially the reason that you expect this in dynamics is chaos or sensitivity on initial conditions. So you expect if you change the initial conditions, the tiniest bit, that won't change the first chunk of your orbit, but it might change the rest arbitrarily much. So you sort of expect, sometimes at least, for example, when you have a system like this, that you can sort of very closely prescribe exactly what you want an orbit to do. Not exactly, exactly. Each point has to be the image of the previous point. But in the large, you can really prescribe what things do. Sometimes. I'm going to defer that question to the end. The question is about period coordinates and how big are the domains? But we don't actually have a very good understanding. And I think trying to answer would confuse the issue. So it's a good question. And I just don't have anything helpful, I can say, in one minute about that. So I want to talk about the inspiration for this work. I'll help you put this in context. So this is part of a general theory due to Ratner. I'm going to present a special case due to Danny and Margulis. So I'm going to look at SL3R mod SL3C. This is a great space that you should be familiar with. It's the space of unit volume tori of dimension 3. And SL3R acts on this by multiplication on the opposite side that you monitor it by. And I want to think of a particular one parameter subgroup, so a particular r action on this via matrices. And just to pick one, I'm going to pick 1, 1, 1, t, t, t squared over 2. So hopefully I wrote that right so that this is a one parameter subgroup. So I'm going to look at the action. So this acts gives an r action on this space. And then the statement is every orbit closure is a manifold. And more than that, it's actually a sub-homogeneous space. This is what's called a homogeneous space. By the way, technicality is technically this is an orbifold, not a manifold. And so this isn't a manifold, it's an orbifold. And similarly, stradar orbifolds. So you're not going to get a manifold in an orbifold. And to be really technically correct, I should say it's an immersed orbifold. It can cross itself. Legal jargon has now been completed. So this is a really important statement. What's special about this? So I can't replace this with anything. If I put some e to the t's in the diagonal, this would sort of display the chaotic behavior of geodesic flows. And it would be a total loss cause. It would be quantifiably extremely super false. So what's special about this is it's unipotent. Unipotent means the eigenvalues are 1. And in particular, that means that there's polynomial growth. And you're sort of what polynomials you're staring at, t squared is a polynomial, contrasted with an e to the t, which would be exponential. OK, so in general, Ratner's theorem says that if you look at any unipotent 1-parameter flow on a homogeneous space, then all of the orbifolds are nice. And this is a super important theorem. People use it everywhere. They use it a ton in number theory, physics, algebraic geometry, literally everywhere because it's applicable whenever you have some sort of symmetry group which is a Lie group. A Lie group show up everywhere because the symmetry group of anything is typically a Lie group. And then you can try to understand your object up to symmetries. OK, so that was proven decades ago. What Eskender's Akane-Mohammadi did isn't the exact analog of that. The exact analog of that would be 1t01 orbit closures. That's the unipotent subgroup. And that's the real holy grail. That would allow you to clean up all sorts of old problems. People would love to do that. They can't. I mean, there are good math petitions who've spent 15 years trying to solve that problem. So they needed a little bit more than just that. And correspondingly, actually, their proof is nothing whatsoever like ratners. Because ratners is all about unipotent orbits. And we still understand almost nothing about orbits of 1t01. Not at the level needed for a ratner. I shouldn't say almost nothing. We understand some useful things, but not nearly at the level needed for a ratner. And I think the feeling now is that the 1t0 version is probably false. OK. So I want to just briefly tell you about another development that took place that was sort of one of the more proximal motivations to the most recent attack of Eskender's Akane-Mohammadi. And that was work of Benoit Kein, who in the simplest case were thinking about the SL2Z action on the torus R2M on Z2. And what they were thinking, I'm just going to say this very briefly. I'm not going to write it because this is pretty far from the main topic, is they said, let's think of a random walk on SL2Z. So say pick your two favorite matrices.  And give them each probability a half. So toss a coin over and over again and pick one of the other. And then track the orbit of a point on this torus. What can you say about it? So they show that typically this equidistributes by studying what are called stationary measures here. And so this was a really big breakthrough because it's some sort of rigidity statement non-involving unipotence. And that actually played a role in this portfolio. Somehow they couldn't use that in the main part of the proof. This proof, the 200-page paper consists of 100-plus pages reducing it to a situation where they can apply a more complicated version of the Ben-Locke argument. So just to give you a flavor, somehow what you end up studying is invariant measures. So you don't consider sets, you consider measures. Measures are nicer than sets. This is called measure rigidity. And it's extremely abstract. Nowhere will you find a picture of any polygons. All they use about modulite space is some results of Forney very similar to what we just did about growth rates as you move along typology physics. And so in particular, we still don't know what the orbit closures are. They're manifold, they're linear manifolds, great. But how many are they? We don't really have a good understanding of that yet. So I have just enough time to give you the easiest example. So the easiest example is maybe I'll take this squared-held surface, which is a 4 to 1 cover of a torus. And I'll act on this by GL2R. So maybe I'll shear it a little bit, and then I'll get something like just a sheared copy. So this no longer covers the same torus, but it covers a different torus, the sheared version. So I can act by the same matrix on everything, on both the thing I'm covering and the thing that's covering. And so the orbit consists of 4 to 1 covers of a torus. And so you can use that to see that the orbit is closed, because the space of 4 to 1 covers of a torus branched over 1 point is closed. So this is a closed orbit, so in particular, it's an orbit closure. So supposedly it's defined by linear equations. So at least in this example, I should describe the linear equations. So first of all, let's say v1, v2, v3, v4, v5. So these are local coordinates given by these. You can express any other edges or linear combination of these edges. So what are the equations? Well, so this edge and this edge, they map to these two edges, which are the same. So this is going to be a torus cover. I better have v1 is v5. And similarly, I'd better have v2 is v3 is v4. So this is the orbit. It's defined by these equations. You can see that if you wiggle this picture, keeping those equations, you're still a cover of the torus. So next time, I'll talk about some more examples and also how we study these things. So next time, we'll be a little bit more like a survey of what we know now. I'll be sort of doing less proofs, but I want to give you a flavor of what's going on, like what the cutting edge is. Any questions? Mike? Maybe we can talk about it later. Any other questions? No, that's the input. And the output is ergodicity, which says something that averages of a test function of some observable over orbits should just be the average of that function. And the HOP argument says, well, the averages should be the same along stable manifolds. That sort of gets sucked into at the same point because the orbits sort of behave very similarly. And you also show it should be sort of a reverse argument shows it should be stable under the unstable manifolds by considering sort of negative time. And then it's like saying, oh, I have a function on R2. And it's constant along horizontal lines and it's constant along vertical lines. So probably the best place to learn about this is you should try to Google for a proof that geodesic flow on a hyperbolic surface is ergodic. That's the situation in which most, well, at least in which I learned it. You could also try looking for this. These are called toral endomorphisms. Yes, sir, I meant constant negative, like a hyperbolic surface, an acyl to our mod gamma. Yep? No, the hydrogen arm is gone now from the lecture series. That was when into understanding something about the dynamics of GT. It does play a role in here. Not directly, they don't talk about hydrogen arm a lot, but they use theorems of Forney, which are based 100% on hydrogen arm. That's the only input specific to the situation, other than that it's 100% abstract ergodic theory.


Hi, my name is Lynn Griesmer and I'd like to share with you some of what I've learned as I've campaigned to represent District 2 on Amherst New Town Council. I began with a few central ideas I wanted to try out. First, let the transition to our new form of government call on the best in us to listen, find common ground, and move our community forward. It's a unique moment and we only have one chance for a good start. Second, that we need a more coherent approach to development, the quality of our neighborhoods, and the residential tax burden. I think most of us recognize that residential property taxes can't continue to bear so much of the burden for excellent schools and services. But broadening the tax base through economic development must serve our values and respect our small-time character. Third, that sound stewardship is essential. Generations of taxpayers have been vested in school, municipal, and library facilities consistent with our values. But many of these facilities are beyond their useful lives and we must protect and or replace them to pass on a strong foundation for the future, not a growing list of unresolved problems. These ideas have struck a chord with many people and have led to some very rich conversations. So as we head toward the final election, I want to give you a better sense of what you can expect from me if you choose me for town council. My optimism about a positive transition has grown steadily. We sometimes hear that Amherst is a town divided, but my sense is that we are far less apart than we sometimes seem. The idea of a different kind of government has hung over us with some understandable uncertainty and contention. But now that the question of what our government will look like has been settled, I have found tremendous interest in engaging the big issues that will determine the success of our community. The critical first job for the council is making the conversation positive and productive, and my unwavering commitment is to promote open, informed, forthright, and respectful dialogue. On the question of economic development and broadening the tax base, the ideas are flying fast and thick. Concerns I've heard range from aesthetics to neighborhood fit to parking. To me, the common thread is the sense that development is currently occurring outside an effective framework that represents us. Zoning is confusing and often outdated, with consequences that seem unintended or out of sync. The connection with our master plan, which is supposed to reflect our values and expectations, seems broken. A new charter requires for the first time that the governing body adopt a master plan on behalf of the town and consider all zoning and development proposals in that context. So a second critical job for the council in partnership with the planning board is to engage the entire community, assess what works so far, and imagine how to overcome obstacles that remain. I will be a relentless advocate for hearing all voices, forging common vision that can earn broad support, and connecting the dots between our values and our zoning for projects, large and small. Finally, I found broad agreement that we need to attend to our public buildings, but also confusion about the trade-offs, timing, and sometimes a sense that the right conversations aren't happening. I've been working for years on these issues, and there is certainly no easy answer, but I believe we can find a way forward that brings the community together. The good news is that we have some savings for this purpose, but we will absolutely need to maximize possible state and private funding so that we can minimize the impact on local taxes. I will be a forceful advocate for financially and environmentally responsible capital planning that balances our priorities, and I will insist on transparent discussion of the choices we face and the connection among different projects. It would be a tremendous honor to serve on Amherst Newtown Council as one of two representatives from District 2. I am excited about continuing the conversation the campaign has started. I invite you to learn more about me on my website at linfordistrict2.org. And thank you Amherst Media and for all of you for being part of this important transition. Please vote on November 6th, and I hope you'll give me one of your votes for District 2. Thank you.


Hello everyone, my name is Bering Zhang and I'm a cloud computing architect working in SIPA. The other two speakers are Wen Ping Song and Shao He Feng. Wen Ping Song is a cloud computing senior research and development engineer who is also working in SIPA. And the other is Feng Shao He. Next, we'll share the topic of enhancement and optimization of new heterogeneous accelerators based on SIPA. We'll introduce the SIPA from the following four aspects, changing of heterogeneous computing, functions and optimization, managing management and planning to do, prospect for several. In recent years, heterogeneous computing has become a relative hot topic. It has gradually emerged in 5G, cloud computing, energy computing, and other fields. But heterogeneous computing faces great challenges in terms of software adaptation, savings, diversity, distributed system collaboration and data migration. For example, how to manage a large number of heterogeneous computing units with unified management? How to cross architecture, high performance, unified programming? And how to combine service to maximize hardware performance? And how to achieve finish switching hardware adaptation, finish decoupling, memory consistency, synchronization, storage compatibility and system compatibility issues in the case of a large amount of business and hardware devices dependency. Saivogar is a project management manager by hardware accelerators and it can solve the above problems effectively. Let's introduce Saivogar's contribution to heterogeneous computing. Next, we'll introduce our new features and our project management in Saivogar. Since Saivogar is still in infancy, there are some problems in it, such as poor case of failure in consistent data, single functions and failed types of accelerator support. We have made improvements to these issues and we were adding accelerator devices on an unbound spot. We have achieved data consistency and synchronization between saivogar and placement through data aggregation with the filter and the transfection processing method. We also realized the GPO virtualization management to improve GPO device utilization and introduced NVMe SSD, PURT, FPGA, DBDK and other types of drivers to improve the cloud platform spot and adaptation capabilities for accelerator hardware devices. We also support a big, great service with accelerators to make accelerator devices convenient. Saivogar is an accelerator resources management project and use macro service architecture to support distributing deployment, which contains Saivogar API, Saivogar conductor and Saivogar agent service. Firstly, we need to set a driver configure, such as the GPO driver and the FPGA driver. Secondly, Saivogar agent collects accelerator resources and information and reports it to the Saivogar conductor. Thirdly, the Saivogar conductor stores accelerator resources and information in the database and reports to the measurement resource management service. The measurement stores resources and information and provides valuable resources for NOAA scheduling when the server is created. The Saivogar API service provides interface to request accelerator resources information. Currently, we have completed NOAA and Saivogar interaction and support PGPU, WGPU and FPGA accelerator devices. And in the regulatory release, we have introduced NISBRA, FPGA and InterQAT accelerator device services. In one of the release, we plan to introduce NVME SSD driver. And in the future, we will support managing Spanlinq card. We have submitted the Spanlinq design specification to the NOAA team and going to discuss with NOAA team on this victory PDG. In user release, we have completed NOAA and Saivogar interaction features to support funding accelerator devices when creating a server. The diagram is abstract process and below is the main steps. We need to create an accelerator device profile which can be a pair of accelerator resources or combination of multiple accelerator resources such as control, GPU and FPGA. Secondly, we should select the device profile to create a server. Thirdly, getting available hosts that specify the resource reports through NOAA's conductor then to create a server with accelerators in device profile. Fourthly, NOAA scheduler get a location candidate from placement and filter and available hosts. Now computers find the server with accelerators. Finally, several API maintenance relations between server and accelerators. So about steps, we can put a server with accelerator devices profile through NOAA. If you want to test this feature that you can define your story release, I think it will be a pleasant experience. Next, Wimping Song will introduce Saivogar's implementation and optimization of acceleration devices. My name is Wimping Song and let me introduce the implementation of the optimization for Saivogar. This diagram will introduce the implementation logic of finding and unbounding acceleration devices for an active server or a stopped server. The bound and unbound are very synodical, you can see as low. Firstly, NOAA API send bound and unbounded accelerators request to NOAA computer then NOAA computer call placement to allocate accelerators resources. Next, liberal attach or detach the device and will add or remove the accelerator info from the server's XML cloud. Lastly, several API maintenance server and accelerator relations relating or adding mapping relations. VGV is necessary in current business since this diagram shows the VGV management architecture. VGV can be vitalized to many VGVs. In the future, we can use several devices table to record the VGV info. They play for the table to record the VGV info and the attributes table record the VGV trade under resources classes. Today we can only find one VGV to the server as a name that doesn't support creating multiple media devices by NOAA. With VGV management by several we need to understand the NOAA computer configure about the VGV fast on the VGV type. Several can also collect the VGV info and stored into the VGV. By GPU visualization, we can increase the GPU usage and improve its ease of use. Use find the management GPUs. We plan to introduce this feature in one by release, please pay attention. If you have better suggestions, you can contact us via IRC or email. We also support creating server with VGP like other accelerators. This diagram is the main steps. Firstly, we need to create a device profile of VGP such as NVIDA 180, NVIDA 180, and NVIDA 181. Then we use the device profile to create a server, which is same as NOAA stable interactive action. Through NOAA state schedulers like the available host that satisfies the request VGP resources. Next, NOAA computers for server with VGP and request the server to find accelerators request. Server will send accelerators bounding event to notify NOAA computer. The bounding results will NOAA computer receive the declarator bounding event. NOAA computer gets bounding info and generator configuration and write to server's external file. This diagram shows the optimization of data synchronization between stable worker and the placement. Nowadays, several collect accelerators device is info and report to placement. When placement service is gone, the report will file and data inconsistent is generated between server and placement. In largest scale scenarios, server will also report the big data to placement, even though the placement is gone, which cause a great waste of network-fund-wide resource. So, in response to the problems, we will optimize the method of accelerator resources synchronization. Further, instead of server for data to placement, we will change the way of data transformation by placement for data from server. Even though server service is gone, we needn't worry the bound-wide resource waste. Secondly, for this transform in large scenarios, we will define a future accelerator resource method, which traditionally can get the accelerator resource from server, and has data with features like NOAA. The waste metrics are device usage, device type, device aggregate, device product, device host usage, and so on. The future method will return accelerator device list with no usage rate through device type, product type, product ID, and no usage host, which has devices. Suddenly, when placement gets the future data, we will use the clean method to filter the valid data, and the correct time is earlier than after the time, and clean the device in use status. Then use transactions to save data in resource classes, resource providers, traits, inventories, tables. So, the measures above the data inconsistencies for nominence requires greatly. So, with accelerators, we will block the lots of operations such as migration, start and resume, save and un-save. To enhance the accelerator management, we have completed several events and evacuated and reviewed the blueprint. To support evacuating and rebuilding operations for server with accelerators, in the factorial release, we have submit save and un-save operations supporting patch, which is ready to go, and we will complete it in worldwide release. In addition, we will support certain resume and migration operations. This is our in-cloud, open-spread, planned form architecture. We have supported GPU virtualization, IPGA program, and NVMe SSD acceleration featured by server. We have made a lot of operations of team magicians in function and performance as follows. The physical performance of team magicians based on a signal resistance IO and multiple queen. Improved GPU performance and reduced GPU loss. Optimized resource data signal resistance machine medium. This is all my work style. Next, welcome Shao He. Introduce smart link management and planning to do a step over. Thank you. Hello, everyone. This is Shao He from Intel cloud team. Now, I will introduce SmartNIC management and planning in OpenStack. At present, we have supported SmartNIC N3000 in OpenStack. The picture shows the detailed card information. And we can see there is a 10-fg chip for OVS or other computing off-load. Yes, there is also a Mekton FPG as BMC. We have supported OVS off-load in our SmartNIC and by virtual function pass-through to VM and as network interface. This picture shows the general whole software stack for N3000. The kernel space supports FPG, PCI, physical function and virtual function by VFL. Intel supports OPS DK to manage FPG in user space. Also, there is a DPDK device driver in user space to support image function on the programmed FPG. This picture shows more details of the stack for OVS off-load. It is a similar stack as a general. We can see the software stack also from VFL OPS DPDK to application. Now, this picture shows the new feature we have supported. Now, we have supported each single program API when Edmund posted a program request to Thabaga. Thabaga will check whether the FPG is in use. If no FPG resource is consumed by any VM, then it will download an image from the ground. And the Thabaga SmartNIC driver will start program. After the program finish, the driver will rediscover and refresh the resource information in database dynamically. Also, it will refresh the resource information in placement. We also support a new API for program status and process query during the FPG program. This picture shows a new improvement in OpenStack for SmartNIC with OVS off-load. It shows the details of how we smartNIC watch function to VM as a network interface. Firstly, Edmund should create a device profile for the accelerator resource decryption. Then, the tenant can create a port with this device profile. At last, he can create a VM with this port. When NOVA receives a VM creation request, it will query the port information and get the device profile. Then, it will choose a host candidate to satisfy the device profile and post accelerator request ARQ to Thabaga. Thabaga will choose an accelerator for the VM and send it. Even to NOVA to notify that the accelerator is ready. At last, NOVA will call Libware to start a VM with this accelerator as its network interface. Of course, all these new features and improvements will be upstream and new powerful smartNIC will come out. At last, let's press back for Thabaga. We will support batch create VM with accelerator, batch bound and unbound accelerator. Of course, smartNIC's integration support level migration for SR, AOV, VM, NVME, SSD management. Optimization and more. Okay, that's all for our topic. Thank you. Thank you, everyone.


What's going on everyone? Sam here with late in sports car driven 22 tops 5 star baseball 8 box case break number 36 random team style. Here's a look again at your random results. As always you can find these on the website under the results tab as well as link in chat. So good luck. Hey what's up card kids? What's up Patrick? I got your, I got the Nauta. Thank you man. PC for life right there. Patrick sold me a Halody Nauta BGS 95 like your patch auto or just auto? He's like, he played on the Eagles actually. He's like the big, he played on the Ravens most of his career. He's like the big Hawaiian guy. Defensive tackle. I was thinking. So sick. Halody Nauta. Yeah he was on the, I don't know, I don't think he was there for the Eagles Super Bowl but I know he played on the Eagles for a bit for the end of his career. Right first pack. We've got Laz Newt back. Going to the Cardinals. Great start man. How about a one of one Pudge Rodriguez. Boom. Going to the Marlins. That is NAMQ L on the combo spot picking up the one of one Pudge. There you go. Congrats NAMQ. Heck of a card buddy. Big time Pudge.  So sick. All a famer. What a way to start this break.   Starting up we've got a Ryan Ballade 46 out of 50 purple color match rookie auto for the Rockies. Nice one there. Going to Steve C. And base auto Mark Tashara. Nice one there. Going to the Rangers. Nice techs. Dylan S with the techs. No recap on this later. So no recap on this one guys. Just everything's a hit so and it's a quick break. We've got a Luke Williams rookie auto going to the Phillies. Base. Nice one there. And blue silver signatures. Peter Lanzo. Six of 20. Nice one there for the Mets. Rats on that Mets. Very nice. That's going to Romars. There you go Romars. Nice polar bear. Yeah triple patch auto out of 10. Yes that's exactly what it was. My first auto auto too which is good. I have like a list of Ravens players I need to knock off autos for and he was one of them. We've got a redemption in this one guys. Can I see a, oh no I got one. Never mind. You're off the hook Donnie. I wasn't going to give you one anyway. You weren't going to give me one anyway. Josiah Gray rookie auto for the Nationals. Understandable. Base auto. Nice one there. Let's see what we got on this redemption. Five star pentamorous penmanship. That's the case hit right there of Carl Yastremski going to the Red Sox. There you go Sho A. Nice. Yeah it's going to the Red Sox. Very cool. Congrats on that. Take that. Take a nice Hall of Fame. Former triple crown winner. What's triple crown? When you have the most home runs RBI's and the highest batting average of our league. Yeah. Miguel Cabrera the guy we pulled. He's like the most recent one to do it. Got a Cal Raleigh. Nice big dumper going to the Mariners. Congrats Matthew K. On-card rookie auto that is. And golden graphs. That's 14 out of 40. Fred Lynn going to the Red Sox again. Sho doing well here now. Congrats Sho. Xbox. The nicks are terrible dude. I like it. Got a Jackson Kaur rookie auto going to the Royals. On-card base. And nice one here. We've got 54 out of 75. Nomar Garcia Para. Again going to show with the Red Sox. Nice. Nomar. Nomar. So aggressive. Yeah. That's how all the Boston people would say it when he played there. It's quite annoying. Got very old. Very fast. Yeah. Great C1. It's Tori Hunter. Golden graphs 12 out of 30. Going to the Angels. There you go LA. That is Edward P. Nice Tori. Angels Tori Hunter. It's a little bit of a ship from what we had. And a Matt Chapman. Nice one there. Human Randall A. Nice one there for the Blue Jays. Congrats Toronto. That was Gerald P. Last box of five stone. Good luck everybody. Starting off we've got a Jose Berrios. 27 out of 75. Green auto for the Blue Jays again. Congrats Gerald P. And finish it off. Going to the Brewers. On the combo spot that is Francis M. Robin Younts. Count on Yount. Nice one there for the Brew Crew. There you go. Congrats again on that one Francis. That will do it for the break guys. Thanks again for the fill. Next up we've got triple