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.
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.
HTH,
-Jon
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 :)
>
> --
> best regards,
> - Benjamin
> Block
> --
> BOFH Excuse #71:
> The file system is full of it
>
------------------------------------------------------------------------------
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
