Skip to main content


noted is used primarily in our shims. And what noted does is there's a feature in elf binaries called notes. And basically what this means is that you can define a note. And a note contains some data type, usually, you know, a combination of integers of different sizes, and they have names. And it allows you to record information in the elf binary that can be used by tools that process that binary. So it's basically just metadata. And we originally tried to do this by using standard tools to add notes to binaries after the build. But what we realized pretty quickly was that cargo does not really allow any way to modify a binary after the build. And so we needed to come up with another way to do this. And so this is what we came up with, is this crate called noded. And inside of this noded macro, you have to define what section you want those notes to be in. And the reason you have to define it is because it's incredibly common to use custom sections. So even though we could have theoretically come up with a default, it's far more common to use a custom section. So we just said, you know, let's just be explicit about it rather than implicit. And you have to specify that. But then once you specify the section where you want the notes to be defined, then you define notes using this syntax. And basically, you're defining this variable foo. And you know, it's going to have a name, which is a bunch of x's. And it's a one, which means, that's the number of the notes. So notes have names and numbers. And then we define the type of that note, and then the value of that note, and basically, this macro just generates a bunch of code, and then the specified notes end up in the binary, and then that can be parsed. And I'll actually show you where this is used. So we're now in the main Enarx repo, and I'm going into the SGX shim. And if you look in the main section, at the top of the main section, there are a bunch of notes that we've defined here. And basically these notes communicate to... the shim is loaded into an enclave by the Enarx run command. The Enarx run command looks at the binary, and reads all the notes. And it defines things like what's the size of the enclave? We can define how many SSA areas we want. We talked about that yesterday, how you can enter an enclave sort of recursively and you can have multiple SSAs. So you can define here how many of those you want. The important thing is that we need to be able to access these variables inside of the enclave as compiler constants, essentially, but they also need to be communicated to the loader to know how many to load. And if the loader chooses not to respect these options, we will get a different measurement of the code during attestation. So we can't detect at runtime, but we can detect at attestation time whether or not those defaults have been correctly followed or not. So it ends up being safe in the end. It's basically a kind of key value store as metadata in the binary where you can communicate to tools that are processing the binary and various ways.