[00:00.000 --> 00:02.000]  You
[00:30.000 --> 00:32.000]  You
[01:00.000 --> 01:02.000]  You
[01:30.000 --> 01:32.000]  You
[02:00.000 --> 02:02.000]  You
[02:30.000 --> 02:32.000]  You
[03:00.000 --> 03:02.000]  You
[03:30.600 --> 03:32.600]  You
[03:48.360 --> 03:50.360]  Know better, okay
[03:52.000 --> 03:58.480]  Yeah, perfect and then let's say the newer generations they move to this VM based
[03:58.480 --> 04:05.120]  A scheme where you have an entire VM isolated from the from you use we cut at the hypervisor you create
[04:05.680 --> 04:13.160]  And I completely isolated VM and everything that's inside like the firmware the bios the kernel and so forth is everything is part of that
[04:13.840 --> 04:15.200]  confidential context
[04:15.200 --> 04:20.080]  That means of course more code that needs to be trusted that's running in the same kind of privilege layer
[04:20.080 --> 04:27.800]  But you don't have the problem of this restricted system interface. So you can directly access do any kind of syscalls
[04:28.440 --> 04:32.960]  pretty much behave like any other application inside any other operating system and
[04:33.640 --> 04:39.680]  those are these these two worlds and both could be an option for protecting variety be at runtime
[04:42.480 --> 04:44.480]  As I said we will interface
[04:44.480 --> 04:49.480]  In in case of the confidential VMs and
[04:50.360 --> 04:52.800]  There's nothing really we have to change and in case of
[04:53.560 --> 04:55.960]  The the into sgx the process-based world
[04:56.840 --> 04:58.840]  We have this weird thing
[04:58.840 --> 05:04.120]  where we need to forward those syscalls to to the host and I
[05:04.640 --> 05:09.280]  Guess it's it's fair to say that the the right side is probably a lot faster
[05:09.280 --> 05:16.680]  But you have this bit more of a stack that you need to trust that has that's running inside the same same context
[05:19.880 --> 05:23.960]  Yeah, so so sgx and process-based limitations
[05:25.000 --> 05:31.240]  It's currently I think it's fair to say it's an interl only solution. You're pretty much locked in with Intel at that point
[05:32.200 --> 05:36.120]  Any kind of context which is expensive that means I always is expensive
[05:36.120 --> 05:39.560]  any other interrupt is expensive and
[05:42.360 --> 05:46.520]  InnoDB I have to say I'm not a marioDB expert whatsoever, but
[05:48.560 --> 05:53.520]  For some reason I know that innoDB is a problem people use different kinds of
[05:56.400 --> 05:59.040]  Storage backends like rocks DB for example
[06:00.160 --> 06:01.520]  so
[06:01.520 --> 06:06.440]  You can't just move the I guess the the off-the-shelf marioDB into an sgx archive
[06:06.440 --> 06:09.520]  There's some some things you have need to fiddle with and then you can make it work
[06:10.680 --> 06:12.680]  The upside is you have a very small
[06:13.680 --> 06:19.280]  Trusted computing base a very small amount of code that you need to trust that runs inside this this context
[06:20.400 --> 06:25.640]  On the other hand SCV confidential VM larger TCB, but that
[06:26.360 --> 06:28.360]  that means you are more
[06:28.760 --> 06:30.760]  it's more lift and shift and
[06:30.760 --> 06:37.640]  Yeah, Intel is currently not an it doesn't really have an a solution out there that you can use
[06:37.880 --> 06:41.560]  But there's into TDX coming. That's more or less the same as as AMD SCV
[06:41.840 --> 06:45.440]  There's other stuff coming from arm and and risk V and so forth
[06:45.960 --> 06:52.200]  Huge attack surface just means yeah, you have the kernel you have the firmware the boot load everything inside that and that inside that
[06:52.200 --> 07:02.040]  Context so if you have any kind of vulnerabilities there, you could be potentially attacked even though you're isolated right?
[07:03.600 --> 07:05.600]  Apart from memory encryption
[07:05.600 --> 07:12.200]  I think an important aspect of confidential computing is is attestation that means remote attestation just means you get an
[07:12.520 --> 07:18.240]  Statement from the chip from the CPU about what's running what code was loaded inside your enclave
[07:18.840 --> 07:19.960]  your
[07:19.960 --> 07:24.800]  for your confidential VM and that you that's that's signed with a key
[07:25.280 --> 07:30.120]  From the CPU and this key has a certificate chain back to the hardware vendor so that
[07:30.640 --> 07:34.480]  You can send such an statement about for example
[07:34.480 --> 07:40.120]  This is a Mara Mara to be enclave a mara to be container that was loaded inside this enclave you can send it to a
[07:41.320 --> 07:45.200]  To remote party and establish a secure channel for example exchanging a key
[07:45.200 --> 07:51.440]  Bootstrapping a t-last connection, and then you have a secure channel through that through the database you can exchange data
[07:52.480 --> 07:54.600]  to your select statements and so forth and
[07:55.880 --> 08:01.360]  With SGX this needs for example you can do that by by having like a small
[08:03.200 --> 08:08.240]  Small step that runs before your before your actual code or next your actual code
[08:08.240 --> 08:15.440]  That does that interaction with the CPU and provides you with a attestation statement, and then you can use that
[08:15.960 --> 08:20.840]  Felix gave a talk last year Felix used that the Mara DB deff room about
[08:21.360 --> 08:23.360]  etch list to be that's essentially a
[08:25.160 --> 08:28.560]  That builds up on Mara to be and tries to
[08:28.560 --> 08:37.280]  Bring that confidential computing concept even even even closer or even more into the the the use case
[08:38.240 --> 08:40.740]  After slides from Felix, let me quickly
[08:48.120 --> 08:50.720]  Because what we've seen so far is essentially just
[08:51.520 --> 08:53.520]  lift and shift of Mara DB
[08:53.520 --> 08:58.600]  On top of SGX or top of AMD SCV what actuals DB does
[09:01.440 --> 09:08.840]  Essentially it uses rocks DB for the reasons mentioned and also for it has some neat features about the encryption
[09:09.280 --> 09:11.280]  so
[09:11.440 --> 09:13.560]  The way it writes blocks
[09:13.560 --> 09:22.320]  Makes it very good for the for the confidential computer attack a model. You can switch things around you can't do any any modifications and
[09:23.880 --> 09:26.680]  The interesting part is why I'm showing this if they
[09:27.280 --> 09:30.000]  added a confidential computing front end that means
[09:30.680 --> 09:36.240]  You not only have attestation that your Mara DB runs inside confidential computing environment. They also give you an attestation
[09:37.160 --> 09:40.240]  About what the database is and who has access to it essentially
[09:40.240 --> 09:44.040]  When you when you set it up you define a small manifest
[09:44.040 --> 09:50.680]  It just gives the initial database layout like the users the initial tables who can modify what who has access to what tables
[09:51.240 --> 09:53.240]  and they add that to the
[09:54.960 --> 09:59.160]  To the attestation statements, so then you can give to a remote attestation and you know
[09:59.160 --> 10:04.600]  This is this is not only Mara DB running there, but this is Mara DB with those user credentials those tables
[10:04.960 --> 10:06.960]  I think that's
[10:06.960 --> 10:10.400]  Integrating this concept of confidentiality more with the
[10:11.400 --> 10:15.360]  The concept of a confidential database if you will so interesting
[10:16.240 --> 10:22.080]  SSTV is also open source as you can check it out. But if that's that's interesting for you, but it's SGX specific
[10:23.400 --> 10:25.400]  You go back to our which lights
[10:25.400 --> 10:40.920]  Yeah, it's his lights his emojis take responsibility, but yeah, the problem with SCV and and confidential VMs currently is that you can
[10:41.880 --> 10:46.120]  You can just lift and shift Mara DB inside it will work the problem with the current way
[10:47.120 --> 10:49.120]  hypervisors and another club providers
[10:49.120 --> 10:56.960]  Offer confidential VMs is that they don't give you full access to the entire stack that runs inside the confidential VM
[10:57.240 --> 10:59.480]  That means they have a firmware shim
[10:59.760 --> 11:07.040]  You don't know you can't really verify that loads your bootloader US and then Mara DB that breaks the chain of verification from
[11:07.240 --> 11:11.000]  the hardware essentially that's what the slide tries to tell you and
[11:11.000 --> 11:18.600]  What we like to have is having the full chain inside this in this VM
[11:19.560 --> 11:24.840]  Verifiable from the from the firmware like from the hyperstatement to the firmware and up to Mara DB itself
[11:25.840 --> 11:31.440]  So yeah, this is a practical problem right now, but hopefully going to be solved soon
[11:31.440 --> 11:33.440]  You
[11:40.640 --> 11:44.800]  Currently you you can for example on Azure you can start on a
[11:45.480 --> 11:49.440]  MDSCV machine on hyper V. They they set the firmer
[11:50.280 --> 11:54.440]  But there's a preview where you can define your own firmer
[11:54.440 --> 12:00.520]  You can either use direct Linux boot or you define your own ua ua fi base firmer
[12:02.120 --> 12:07.480]  Yeah, and then you beat you boot the image the image that starts Mara to be and then you go from there
[12:09.120 --> 12:11.400]  Yeah, if you want to try that
[12:12.880 --> 12:15.920]  Yeah, of course, there's the AMD documentation and stuff
[12:15.920 --> 12:23.880]  of its company cloud cloud offers confidential VMs based on a CV
[12:25.840 --> 12:32.160]  Apparently there's some some solution to try it out, and yeah, actually TV is open source. You can also try that. I
[12:33.240 --> 12:38.200]  Think that's the last light. So I'm not sure if I hit those 20 minutes, but yeah
[12:39.720 --> 12:41.720]  Any any questions
[12:41.720 --> 12:43.720]  The yeah
[12:47.520 --> 12:53.760]  Mostly people that currently want to process sensitive regulated data in the cloud like healthcare
[12:55.440 --> 12:57.520]  Telecommunication this kind of stuff they store
[12:58.560 --> 13:05.440]  They do that on-prem with with with the database they want to move that to the cloud, but then they can't because
[13:05.440 --> 13:14.480]  It's not enough the data is protected at at rest and in transit. They also need to protect data at runtime or as the HSDB case makes it
[13:15.120 --> 13:17.380]  Give guarantees on who has access to the data
[13:19.840 --> 13:21.840]  Yeah
[13:21.840 --> 13:36.240]  To be honest, I am not the best person to answer the question, but I think
[13:37.200 --> 13:39.840]  it's part of the sis calls that
[13:40.560 --> 13:43.480]  That that happened when when you use in ODB
[13:43.480 --> 13:47.320]  I'm not sure what what sis calls aren't the problem and then you have this context switches
[13:47.320 --> 13:52.520]  And you have a lot more context switches than when you use rocks to be that makes it super slow. That's at least one problem
[14:05.880 --> 14:11.720]  Yeah, yeah, I think that's there was something on Felix lights along those lines
[14:12.640 --> 14:14.640]  Yeah, by the way if you I
[14:14.640 --> 14:18.800]  Think this is from last year. I think there's a recording and Felix speaks about
[14:19.760 --> 14:25.240]  Why rocks to be as more as a better performance than then dd in ODB, yeah
[14:25.240 --> 14:50.160]  I don't I don't know this will be a great question for for avid here something right
[14:51.120 --> 14:52.560]  Yeah
[14:52.560 --> 14:57.960]  Yeah, I'm not sure if avid is in the chat or if there's a chat, but maybe he can answer that question
[14:57.960 --> 15:25.080]  Yeah, okay, so this is specific for how AMD implements that essentially they add a
[15:25.080 --> 15:28.920]  A chip the secure processor
[15:32.440 --> 15:39.960]  Yeah, yeah, and this this basically holds the keys holds the information and then you communicate as the guest you communicate encrypt
[15:39.960 --> 15:46.640]  You can establish a secure connection to that go through the hypervisor to DSP and obtain an attestation statement for example
[15:47.320 --> 15:50.480]  So this is implicitly explicitly trusted, right?
[15:50.480 --> 15:56.320]  So the SP as a firmware if the firmware has a buck you could potentially exploit it and so forth
[15:58.360 --> 16:00.360]  Okay, okay
[16:10.000 --> 16:13.200]  So so yeah in in the case of a confidential VM
[16:14.600 --> 16:18.200]  Depending on the hardware you essentially can verify
[16:18.200 --> 16:23.880]  You you create measurements of the entire boot chain
[16:24.600 --> 16:26.880]  So it's similar to a TPM case
[16:28.520 --> 16:35.800]  Like a measured boot where you have a statement of the initial memory layout the firmware and then a statement of all the other
[16:35.800 --> 16:40.240]  Components in the boot chain and the statement just says this was was this is an isolated
[16:40.240 --> 16:47.880]  VM this was the boot chain and this is signed by AMD and this is what you get
[16:47.880 --> 16:54.000]  So the VM is okay, but what about process runtime?
[16:59.520 --> 17:01.520]  Yeah
[17:05.840 --> 17:09.080]  Yeah, so from process space exactly so the
[17:10.560 --> 17:12.560]  Your your untrusted host
[17:12.560 --> 17:18.240]  Creates the creates the process loads the memory pages and then says okay. I'm done
[17:19.280 --> 17:21.120]  and then
[17:21.120 --> 17:25.960]  secure processor that's part of the CPU will create a hash over those pages and
[17:28.800 --> 17:34.440]  Compare that to the to the expected measurement that's signed by you as the author of the of the enclave
[17:34.440 --> 17:38.400]  so you sign your crew you when you build an enclave you
[17:38.400 --> 17:47.040]  essentially build the the expected memory layout you sign that and part of the attestation statement is always this measurement of the
[17:47.040 --> 17:50.080]  of the initial memory layout plus your signature
[17:50.080 --> 18:18.720]  Yeah, I mean yeah, that's part of why you why you why you can say this is a more
[18:18.720 --> 18:24.440]  This is a bit more fuzzy in terms of what the attestation attestation statement says right
[18:28.080 --> 18:32.880]  Potentially you can anything that happens after this boot and modifying the memory layout
[18:33.440 --> 18:37.200]  Modifying what's what's running there? You can only derive from the initial statement
[18:37.760 --> 18:41.440]  So what people do is they'd use a read-only file system a
[18:42.040 --> 18:44.920]  Mutable image this kind of stuff to make it more locked down
[18:44.920 --> 18:51.360]  For example, if you just want Mariah to be you could bring this to a microkernel that just is able to run a
[18:52.440 --> 18:54.440]  Mariah to be container for example
[18:54.440 --> 19:24.160]  Still there's a lot of things that can happen at runtime, but trying to to minimize the TCP or the truss duty base. Yeah, yeah, I mean
[19:25.440 --> 19:30.600]  If you can derive all the states you will end up in from the from the initial state you would have perfect
[19:31.720 --> 19:33.720]  Verification, but this is not feasible of course
[19:42.040 --> 19:46.920]  The main memory if you if you're referring to caches, I'm not sure which cache
[19:50.160 --> 19:52.160]  Yes
[19:52.160 --> 20:00.160]  So in the confidential VM case anything of that VM right from the from the firmware layer upwards anything
[20:00.160 --> 20:05.480]  That's above the hypervisor for for the process space anything. That's part of the process
[20:07.320 --> 20:09.320]  Yeah for process based
[20:09.880 --> 20:13.480]  With the latest generation, I think it's like around like 10%
[20:14.200 --> 20:18.840]  Something like that the bigger problem in other contexts, which is by far for the right-hand side
[20:19.520 --> 20:20.800]  AMD
[20:20.800 --> 20:26.000]  That the measurements and I think they are but around worst case like four to eight percent
[20:26.000 --> 20:28.000]  What
[20:28.000 --> 20:37.880]  Well, what kind of instructions do you use to switch the context to use the ring zero what exactly
[20:38.440 --> 20:40.440]  What are the
[20:41.000 --> 20:43.000]  instructions that you actually need
[20:43.000 --> 21:12.640]  Yeah, so on a process base what will just happen if let's say you do a right syscall the
[21:13.120 --> 21:18.600]  You will the process of a little trap you will have an interrupt and it will automatically
[21:21.440 --> 21:26.400]  Save your your your registers your state encrypted and then clear those registers
[21:26.400 --> 21:32.760]  There were some problems in the past but clear the rules registers and go to to to to a kernel space
[21:33.480 --> 21:35.880]  And yeah for the for the VM
[21:35.880 --> 21:44.440]  There are some they both have additional instructions for doing those confidential computing specifics like getting a remote attestation statement or
[21:44.440 --> 22:05.600]  For the confidential VM connecting through the secure processor, there's an instruction set addition
[22:14.440 --> 22:17.440]  You