Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1591441
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place |
| Date | 2017-03-02 21:20 +0100 |
| Message-ID | <tgFmG-7nY-11@gated-at.bofh.it> (permalink) |
| References | <tbyvy-1iO-79@gated-at.bofh.it> <tggxY-6ns-19@gated-at.bofh.it> <tggxY-6ns-17@gated-at.bofh.it> <tgFmG-7nY-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Mar 02, 2017 at 12:30:31PM -0600, Tom Lendacky wrote:
> The "* 2" here and above is that a PUD and a PMD is needed for both
> the encrypted and decrypted mappings. I'll add a comment to clarify
> that.
Ah, makes sense. Definitely needs a comment.
> Yup, I can do that here too (but need PGDIR_SIZE).
Right, I did test and wanted to write PGDIR_SIZE but then ... I guess
something distracted me :-)
> So next_page is the first free page within the workarea in which a
> pagetable entry (PGD, PUD or PMD) can be created when we are populating
> the new mappings or adding the workarea to the current mapping. Any
> new pagetable structures that are created will use this value.
Ok, so I guess this needs an overview comment with maybe some ascii
showing how workarea, exec_size, full_size and all those other things
play together.
> Ok, I'll work on the comment. Something along the line of:
>
> /*
> * The encrypted mapping of the kernel will use identity mapped
> * virtual addresses. A different PGD index/entry must be used to
> * get different pagetable entries for the decrypted mapping.
> * Choose the next PGD index and convert it to a virtual address
> * to be used as the base of the mapping.
Better.
> Except the workarea size includes both the encryption execution
> size and the pagetable structure size. I'll work on this to try
> and clarify it better.
That's a useful piece of info, yap, the big picture could use some more
explanation.
> Most definitely. I appreciate the feedback since I'm very close to
> the code and have an understanding of what I'm doing. I'd like to be
> sure that everyone can easily understand what is happening.
Nice!
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place Borislav Petkov <bp@alien8.de> - 2017-03-01 18:50 +0100 Re: [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place Borislav Petkov <bp@alien8.de> - 2017-03-02 21:20 +0100
csiph-web