On 09/08/2014 07:12 PM, Jonathan McCune wrote: > No, but if you are creating the MLE page tables and the MLE itself, you may > be able to help yourself out by artificially imposing a page-alignment > requirement. That is small enough to be easy for the Linux kernel > allocator and hopefully large enough to fit whatever assembly stubs you may > need inside. >
Ah yes. That is right. Just for testing purposes I'll just `memmap` some stuff at boot-time and forbid the kernel to touch that, this way I'll have continuous space in mem anyway. We'll see and test how much of a dire situation we'll have, once we lift this constraint. The way our hypervisor's architecture works, this is pretty much a given anyway. > > I agree that the call 1f/pop solution depends on unspecified behavior, and > should be avoided. At the time that code was written there was > significantly less information available about the post-SENTER CPU state, > and I wanted to have the minimum possible difference from code that would > work on AMD processors. In my experience the stack was still initialized to > point inside the SINIT module's memory region (presumably the stack that it > was using), which must also be protected from DMA, etc. > > You may be able to leverage the call 1f/pop to help yourself with > development / bring-up, so that you can then empirically determine which > portions of the spec(s) actually describes the CPU's behavior. > Thing is, if we could get a word from intel, that it is like the TXT-spec states (and that the instruction-manual is wrong on that), then the linear entry-point is contained in EBX, this solves most of the problems. You'll just have to make sure, you do identity-mappings for it in the page-table you have to hand over to the SINIT. But it is very likely that you have to setup this table from scratch anyway, so that won't be a problem. But if that doesn't happen, then I'll just do what you said. Thx. - Ben > On Mon, Sep 8, 2014 at 9:51 AM, Benjamin Block <b...@mageta.org> wrote: > >> Hej Jonathan, >> >> On 08:57 Mon 08 Sep , Jonathan McCune wrote: >>> If you consider the alignment requirements of the entry point, and layout >>> your MLE with the entry point in the first 4K, you may be able to mask >>> things such that you do not have to care about the low 12 bits. >> >> AFAIK, there are no strict rules for alignment of the MLE-entry-point, >> are there? I grep'ed through the TXT SDM and found none. But even if so, >> I don't really understand what you want to say (sry, too much >> spec-reading today). >> >> Because paging is off and CS starts at 0h I need the physical address of >> my code. The MLE-image can be placed everywhere below 4Gb, I can't know >> the exact address of it at compile-/link-time, so I need to find out at >> run-time. For that I need the EIP value. I know that flicker does that >> by doing >> >>> _pal_start: >>> call 1f >>> 1: popl %eax // put EIP into EAX >> >> , which is the idiom which I would also use. But one of the two specs >> says (the txt spec, not the instruction spec) that ESP/EBP/SS is >> undefined right after the SINIT jumped to the entry-point (`_pal_start` >> in the example above). So this code may as well fail randomly. >> >> If I miss something here, please tell me :) >>
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
