On Tue, Feb 28, 2017 at 05:28:48PM -0600, Tom Lendacky wrote:
> That's a good idea, I'll expand on that. I probably won't be that
> direct in my comment though :)
You either haven't dealt with firmware long enough or you're much better
person than me. :-)))
--
Regards/Gruss,
Boris.
Good ma
On Tue, Feb 28, 2017 at 05:19:51PM -0600, Tom Lendacky wrote:
> Device drivers don't supply set_dma_mask() since that is part of the
> dma_map_ops structure. The fm10k_pf.c file function is unrelated to this
> (it's part of an internal driver structure). The dma_map_ops structure
> is setup by the
On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
>
> Support is needed to allocate pages for kexec without encryption. This
> is needed in order to be able to reboot in the kernel in the same manner
>
On Thu, Feb 16, 2017 at 09:46:47AM -0600, Tom Lendacky wrote:
> Add support to check if memory encryption is active in the kernel and that
> it has been enabled on the AP. If memory encryption is active in the kernel
> but has not been enabled on the AP, then set the SYS_CFG MSR bit to enable
> mem
On Thu, Feb 16, 2017 at 09:46:19AM -0600, Tom Lendacky wrote:
> Add warnings to let the user know when bounce buffers are being used for
> DMA when SME is active. Since the bounce buffers are not in encrypted
> memory, these notifications are to allow the user to determine some
> appropriate actio
On Thu, Feb 16, 2017 at 09:46:04AM -0600, Tom Lendacky wrote:
> Since DMA addresses will effectively look like 48-bit addresses when the
> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
> device performing the DMA does not support 48-bits. SWIOTLB will be
> initialized to c
On Thu, Feb 16, 2017 at 09:43:07AM -0600, Tom Lendacky wrote:
> Add support for Secure Memory Encryption (SME). This initial support
> provides a Kconfig entry to build the SME support into the kernel and
> defines the memory encryption mask that will be used in subsequent
> patches to mark pages a
On Fri, Feb 24, 2017 at 09:04:21AM -0600, Tom Lendacky wrote:
> I looked at doing that but you get into this cyclical situation unless
> you specifically map each setup data elemement as decrypted. This is ok
> for early_memremap since we have early_memremap_decrypted() but a new
> memremap_decrypt
On Thu, Feb 23, 2017 at 03:34:30PM -0600, Tom Lendacky wrote:
> Hmm... maybe I'm missing something here. This doesn't have anything to
> do with kexec or efi_reuse_config. This has to do with the fact that
I said kexec because kexec uses the setup_data mechanism to pass config
tables to the seco
On Thu, Feb 16, 2017 at 09:45:35AM -0600, Tom Lendacky wrote:
> Add support for changing the memory encryption attribute for one or more
> memory pages.
"This will be useful when we, , for example."
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cacheflush.h |3 ++
> arch/x8
On Tue, Feb 21, 2017 at 11:18:08AM -0600, Tom Lendacky wrote:
> It's the latter. It's really only used for working with values that
> will either be written to or read from cr3. I'll add some comments
> around the macros as well as expand on it in the commit message.
Ok, that makes sense. Normal
On Tue, Feb 21, 2017 at 12:42:45PM -0500, Rik van Riel wrote:
> Do we want that in kernel/ or in arch/x86/mm/ ?
If you'd ask me, I don't have a strong preference. It is a pile of
functionality which is part of the SME feature and as such, it is closer
to the CPU. So arch/x86/cpu/sme.c or so.
But
On Tue, Feb 21, 2017 at 08:55:30AM -0600, Tom Lendacky wrote:
> Actually, %rbp will have the encryption bit set in it at the time of the
> check so if SME is active we won't take the jump to .Lskip_fixup.
Ha, I didn't think of that! Do you see now what I mean with being
explicit in the asm boot co
On Thu, Feb 16, 2017 at 09:45:09AM -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be mapped decrypted. Add support to apply the proper
> attributes to the EFI page tables and to the early_memremap and memremap
> APIs to i
On Thu, Feb 16, 2017 at 09:44:30AM -0600, Tom Lendacky wrote:
> This patch adds support to return the E820 type associated with an address
s/This patch adds/Add/
> range.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/e820/api.h |2 ++
> arch/x86/include/asm/e820/types.h |
On Thu, Feb 16, 2017 at 09:44:11AM -0600, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decr
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Modify and create some macros for calculating physi
On Thu, Feb 16, 2017 at 09:43:58AM -0600, Tom Lendacky wrote:
> Add support to be able to either encrypt or decrypt data in place during
> the early stages of booting the kernel. This does not change the memory
> encryption attribute - it is used for ensuring that data present in either
> an encryp
On Thu, Feb 16, 2017 at 09:43:48AM -0600, Tom Lendacky wrote:
> Add to the early_memremap support to be able to specify encrypted and
early_memremap()
Please append "()" to function names in your commit messages text.
> decrypted mappings with and without write-protection. The use of
> write-pro
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
Let's not write it like some technical document: "Secu
On Thu, Feb 16, 2017 at 09:43:19AM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the
On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote:
> create mode 100644 Documentation/x86/amd-memory-encryption.txt
> create mode 100644 arch/x86/include/asm/mem_encrypt.h
> create mode 100644 arch/x86/kernel/mem_encrypt_boot.S
> create mode 100644 arch/x86/kernel/mem_encrypt_init.c
On Thu, Feb 16, 2017 at 09:43:07AM -0600, Tom Lendacky wrote:
> Add support for Secure Memory Encryption (SME). This initial support
> provides a Kconfig entry to build the SME support into the kernel and
> defines the memory encryption mask that will be used in subsequent
> patches to mark pages a
On Thu, Feb 16, 2017 at 09:42:25AM -0600, Tom Lendacky wrote:
> For processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
>
> Acked-by: Borislav Petkov
> Signed-off-by: Tom Lendacky
Just a nit:
Subj
On Thu, Feb 16, 2017 at 09:42:54AM -0600, Tom Lendacky wrote:
> When System Memory Encryption (SME) is enabled, the physical address
> space is reduced. Adjust the x86_phys_bits value to reflect this
> reduction.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/cpu/common.c | 10 +++
On Thu, Feb 16, 2017 at 01:42:13PM -0600, Tom Lendacky wrote:
> I realize it's a bit more code and expands the changes but I thought it
> would be a bit clearer as to what was going on this way. And then the
> follow on patch for the physical address reduction goes in nicely, too.
Well, the code f
On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote:
> Update the CPU features to include identifying and reporting on the
> Secure Memory Encryption (SME) feature. SME is identified by CPUID
> 0x801f, but requires BIOS support to enable it (set bit 23 of
> SYS_CFG MSR). Only show th
Ok, this time detailed review :-)
On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote:
> This patch adds a Documenation entry to decribe the AMD Secure Memory
> Encryption (SME) feature.
Please introduce a spellchecker into your patch creation workflow. I see
two typos in one line.
Also
On Wed, Feb 15, 2017 at 11:44:24AM +0100, Jiri Olsa wrote:
> does it say unsupported when you omit -a?
Yeah, it does dump the event name like it was counting but then it says
. For example:
amd_iommu_0/...
> [jolsa@krava perf]$ ./perf stat -e 'cpu/cpu-cycles/'
^
Haha, I ch
On Wed, Feb 15, 2017 at 02:13:29PM +0700, Suravee Suthikulpanit wrote:
> > So you can define a static struct pmu in the driver and do struct
> > assignment directly instead of writing them one-by-one.
>
> I believe this is the same suggestion you have made in V8.
Here's what I mean:
---
diff --g
On Tue, Feb 07, 2017 at 02:40:28AM -0600, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit
>
> This patch series modifies the existing IOMMU and Perf drivers to support
> systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU
> instance.
> This allows users to specify pe
is the IOMMU index. This allows users to specify
> different events to be programmed onto performance counters
> of each IOMMU.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee Suthikulpanit
> ---
...
> @@ -414,46 +417,46 @@ static __init void amd_io
multi-IOMMU in subsequent patch.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
...
> @@ -2765,48 +2763,58 @@ u8 amd_iommu_pc_get_max_counters(unsigned int idx)
> }
> EXPORT_SYMBOL(amd_iom
MU
> perf implementation only supports a single IOMMU. A subsequent
> patch will add support for multiple IOMMUs, and will use a proper IOMMU index.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
...
> di
On Wed, Jan 25, 2017 at 10:46:53AM +0100, Peter Zijlstra wrote:
> Which is absolutely insane.
Right,
IMO, the simplest thing to do for your purposes is to embed a struct
amd_iommu pointer into struct perf_amd_iommu at init time so that you
don't have to do all that crazy dance in the PMU function
is the IOMMU index. This allows users to specify
> different events to be programed onto performance counters
"programmed"
Please introduce a spellchecker into your patch creation workflow.
> of each IOMMU.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by:
On Mon, Jan 16, 2017 at 01:23:35AM -0600, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit
>
> Introduce static amd_iommu_attr_groups to simplify the
> sysfs attributes initialization code.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-b
need to check the return value from
> amd_iommu_get_reg() before using the value.
So basically you wanna say:
"Add amd_iommu_{g,s}et_reg() error handling."
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpa
; So break it down to amd_iommu_pc_[get|set]_reg(),
> and modifies them to allow callers to specify IOMMU index. This prepares
and modify
> the driver for supporting multi-IOMMU in subsequent patch.
>
> Also remove unnecessary function declarations in amd_iommu_proto.h.
>
> Cc: Pete
ion in
> amd_iommu_proto.h.
This sentence can go away: never write "what" the patch is doing -
always "why" it is doing it.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86
as static.
>
> This function will also be used by Perf AMD IOMMU driver.
>
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/events/amd/iommu.h | 2 ++
> drivers/iommu/amd_iommu.c | 6 +++---
>
ro.
That last one doesn't read like a sentence.
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/events/amd/iommu.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git
)
"Make use"?
> This should not affect logic and functionality.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/events/amd/iommu.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
On Sat, Jan 14, 2017 at 09:58:29AM +0700, Suravee Suthikulpanit wrote:
> I'll update the commit log to mention
> /bus/event_source/devices/amd_iommu_X instead.
Yes, so /sys/devices/ contains *all* devices on the system and the iommu
ones appear there too but since in the commit message you were ta
On Fri, Jan 13, 2017 at 05:24:01PM +0700, Suravee Suthikulpanit wrote:
> IIUC, Perf tools looks at the /sys/devices/x to identify
> availalble PMUs. Are you planning to have perf tools look at
> /sys/devices/system/iommu/xxx instead?
No, I'm planning to understand what do you mean exactly. Bec
evel devices hierarchy?
Why not add a proper hierarchy to
/sys/devices/system/iommu/ ...
?
Jörg, don't you have a sane iommu hierarchy already in sysfs?
> This allows users to specify different events to be programed
> onto performance counters of each IOMMU.
>
> Cc: Peter Zi
On Mon, Jan 09, 2017 at 09:33:46PM -0600, Suravee Suthikulpanit wrote:
> This patch introduces amd_iommu_get_num_iommus(). This is intended for
There's that "This patch" again... but you get the idea :)
> Perf AMD IOMMU driver.
>
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
On Mon, Jan 09, 2017 at 09:33:45PM -0600, Suravee Suthikulpanit wrote:
> This patch cleans up:
> * Various bitwise operations in perf_iommu_enable_event
> * Make use macros BIT(x)
>
> This should not affect logic and functionality.
>
> Cc: Peter Zijlstra
> Cc: Boris
On Mon, Jan 09, 2017 at 09:33:44PM -0600, Suravee Suthikulpanit wrote:
> This patch declare pr_fmt for perf/amd_iommu and remove unnecessary
There's that "This patch" again.
> pr_debug.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee
tch also removes unnecessary function declarations in
"Also, remove unnecessary ..."
> amd_iommu_proto.h.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Joerg Roedel
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/events/amd/iommu.c | 45 ++
the MSB sign bit.
Past tense also reads funnily: "Fix overflow handling ..." sounds much
better.
> * Remove unnecessary local64_set().
But you don't remove it - you add it. Huh?
> * Coding style and make use of GENMASK_ULL macro.
>
> Cc: Peter Zijlstra
>
On Tue, Nov 29, 2016 at 12:48:17PM -0600, Tom Lendacky wrote:
> > One more thing: just like we're adding an =on switch, we'd need an =off
> > switch in case something's wrong with the SME code. IOW, if a user
> > supplies "mem_encrypt=off", we do not encrypt.
>
> Well, we can document "off", but i
On Wed, Nov 09, 2016 at 06:38:38PM -0600, Tom Lendacky wrote:
> This patch adds the support to check if SME has been enabled and if the
> mem_encrypt=on command line option is set. If both of these conditions
> are true, then the encryption mask is set and the kernel is encrypted
> "in place."
>
>
On Wed, Nov 09, 2016 at 06:38:26PM -0600, Tom Lendacky wrote:
> This patch adds the support to check if SME has been enabled and if the
> mem_encrypt=on command line option is set. If both of these conditions
> are true, then the encryption mask is set and the kernel is encrypted
> "in place."
>
>
On Wed, Nov 09, 2016 at 06:37:40PM -0600, Tom Lendacky wrote:
> Add support to check if memory encryption is active in the kernel and that
> it has been enabled on the AP. If memory encryption is active in the kernel
> but has not been enabled on the AP then do not allow the AP to continue
> start
On Wed, Nov 09, 2016 at 06:38:38PM -0600, Tom Lendacky wrote:
> This patch adds the support to check if SME has been enabled and if the
> mem_encrypt=on command line option is set. If both of these conditions
> are true, then the encryption mask is set and the kernel is encrypted
> "in place."
Som
On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote:
> The issue is it's a (potential) security hole, not a slowdown.
How? Because the bounce buffers will be unencrypted and someone might
intercept them?
> To disable unsecure things. If someone enables SEV one might have an
> expec
On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote:
> > Makes sense, but I think at least a dmesg warning here
> > might be a good idea.
>
> Good idea. Should it be a warning when it is first being set up or
> a warning the first time the bounce buffers need to be used. Or maybe
> both
On Sat, Nov 19, 2016 at 12:48:27PM -0600, Tom Lendacky wrote:
> Should I move this functionality into the sme_set_mem_* functions or
> remove the sme_set_mem_* functions and use the set_memory_* functions
> directly. The latter means calculating the number of pages, but makes
> it clear that this
On Sat, Nov 19, 2016 at 12:33:49PM -0600, Tom Lendacky wrote:
> >> +{
> >> + /* SME is not active, just return true */
> >> + if (!sme_me_mask)
> >> + return true;
> >
> > I don't understand the logic here: SME is not active -> apply encryption?!
>
> It does seem counter-intuitive, but
On Wed, Nov 09, 2016 at 06:37:08PM -0600, Tom Lendacky wrote:
> When Secure Memory Encryption is enabled, the trampoline area must not
> be encrypted. A CPU running in real mode will not be able to decrypt
> memory that has been encrypted because it will not be able to use addresses
> with the memo
On Wed, Nov 09, 2016 at 06:36:55PM -0600, Tom Lendacky wrote:
> This patch adds support to be change the memory encryption attribute for
> one or more memory pages.
"Add support for changing ..."
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cacheflush.h |3 +
> arch/x86/inclu
On Wed, Nov 09, 2016 at 06:36:31PM -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be accessed unencrypted. Add support to apply the
> proper attributes to the EFI page tables and to the early_memremap and
> memremap APIs
On Wed, Nov 09, 2016 at 06:36:20PM -0600, Tom Lendacky wrote:
> The boot data and command line data are present in memory in an
> un-encrypted state and are copied early in the boot process. The early
> page fault support will map these areas as encrypted, so before attempting
> to copy them, add
Btw, for your next submission, this patch can be split in two exactly
like the commit message paragraphs are:
On Wed, Nov 09, 2016 at 06:36:10PM -0600, Tom Lendacky wrote:
> Add support to be able to either encrypt or decrypt data in place during
> the early stages of booting the kernel. This does
On Tue, Nov 15, 2016 at 03:22:45PM -0600, Tom Lendacky wrote:
> Hmmm... I still need the ebx value from the CPUID instruction to
> calculate the proper reduction in physical bits, so I'll still need
> to make the CPUID call.
if (c->extended_cpuid_level >= 0x801f) {
cpui
On Tue, Nov 15, 2016 at 10:06:16AM -0600, Tom Lendacky wrote:
> Yes, but that doesn't relate to the physical address space reduction.
>
> Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is
> never used, there is a physical reduction of the address space. So when
> checking whet
On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote:
> The feature may be present and enabled even if it is not currently
> active. In other words, the SYS_CFG MSR bit could be set but we aren't
> actually using encryption (sme_me_mask is 0). As long as the SYS_CFG
> MSR bit is set we ne
On Tue, Nov 15, 2016 at 01:10:35PM +0100, Joerg Roedel wrote:
> Maybe add a comment here why you can't use cpu_has (yet).
So that could be alleviated by moving this function *after*
init_scattered_cpuid_features(). Then you can simply do *cpu_has().
Also, I'm not sure why we're checking CPUID for
On Mon, Nov 14, 2016 at 12:18:44PM -0600, Tom Lendacky wrote:
> The %rsi register can be clobbered by the called function so I'm saving
> it since it points to the real mode data. I might be able to look into
> saving it earlier and restoring it before needed, but I though this
> might be clearer.
On Wed, Nov 09, 2016 at 06:35:43PM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the
On Wed, Nov 09, 2016 at 06:34:59PM -0600, Tom Lendacky wrote:
> Update the cpu features to include identifying and reporting on the
Here and for all other commit messages:
s/cpu/CPU/g
> Secure Memory Encryption feature.
>
...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoi
+ Toshi.
On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
> For processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
>
> Acked-by: Borislav Petkov
> Signed-off-by: Tom Lendacky
>
On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
> This patch adds a Documenation entry to decribe the AMD Secure Memory
> Encryption (SME) feature.
>
> Signed-off-by: Tom Lendacky
> ---
> Documentation/kernel-parameters.txt |5 +++
> Documentation/x86/amd-memory-encrypt
On Thu, Sep 15, 2016 at 12:08:04PM -0500, Tom Lendacky wrote:
> The problem is that this physical address does not contain the
> encryption bit, and even if it did, it wouldn't matter. The __va()
> define creates a virtual address that will be mapped as encrypted given
> the current approach (whic
On Thu, Sep 15, 2016 at 11:57:41AM -0500, Tom Lendacky wrote:
> If I do that, then I could put an #ifdef in the header to include the
> asm/mem_encrypt.h if the memory encryption is configured, else set the
> value to zero.
Yeah, something along those lines...
> I'll look into this. One immediate
On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote:
> This is still required because just using the __va() would still cause
> the mapping created to have the encryption bit set. The ioremap call
> will result in the mapping not having the encryption bit set.
I meant this: https://lkml.k
On Mon, Aug 22, 2016 at 05:39:08PM -0500, Tom Lendacky wrote:
> This patch adds the support to check if SME has been enabled and if the
> mem_encrypt=on command line option is set. If both of these conditions
> are true, then the encryption mask is set and the kernel is encrypted
> "in place."
>
>
On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote:
> Since the setup data is in memory in the clear, it must be accessed as
> un-encrypted. Always use ioremap (similar to sysfs setup data support)
> to map the data.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/kdebugfs.c |
On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote:
> Add support to check if memory encryption is active in the kernel and that
> it has been enabled on the AP. If memory encryption is active in the kernel
A small nit: let's write out "AP" the first time at least: "... on the
Applicatio
On Mon, Sep 12, 2016 at 10:41:29AM -0500, Tom Lendacky wrote:
> Looking at __change_page_attr_set_clr() isn't it possible for some of
> the pages to be changed before an error is encountered since it is
> looping? If so, we may still need to flush. The CPA_FLUSHTLB flag
> should take care of a fai
On Mon, Sep 12, 2016 at 10:14:59AM -0500, Tom Lendacky wrote:
> I did run checkpatch against everything, but was always under the
> assumption that I shouldn't change existing warnings/errors like this.
> If it's considered ok since I'm touching that line of code then I'll
> take care of those situ
On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote:
> I can look into that. The reason I put this here is this is all the
> early page fault support that is very specific to this file. I modified
> an existing static function to take advantage of the mapping support.
Yeah, but all this
On Mon, Aug 22, 2016 at 05:38:49PM -0500, Tom Lendacky wrote:
> Update the KVM support to include the memory encryption mask when creating
> and using nested page tables.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/kvm_host.h |3 ++-
> arch/x86/kvm/mmu.c |8
On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote:
> Add support to check if memory encryption is active in the kernel and that
> it has been enabled on the AP. If memory encryption is active in the kernel
> but has not been enabled on the AP then do not allow the AP to continue
> start
On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote:
> Add support to the AMD IOMMU driver to set the memory encryption mask if
> memory encryption is enabled.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |2 ++
> arch/x86/mm/mem_encrypt.c |
On Mon, Aug 22, 2016 at 05:38:07PM -0500, Tom Lendacky wrote:
> Since DMA addresses will effectively look like 48-bit addresses when the
> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
> device performing the DMA does not support 48-bits. SWIOTLB will be
> initialized to c
On Mon, Aug 22, 2016 at 05:37:57PM -0500, Tom Lendacky wrote:
> When Secure Memory Encryption is enabled, the trampoline area must not
> be encrypted. A cpu running in real mode will not be able to decrypt
s/cpu/CPU/... always :-)
> memory that has been encrypted because it will not be able to us
On Mon, Aug 22, 2016 at 05:37:49PM -0500, Tom Lendacky wrote:
> This patch adds support to be change the memory encryption attribute for
> one or more memory pages.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cacheflush.h |3 +
> arch/x86/include/asm/mem_encrypt.h | 13 ++
On Mon, Aug 22, 2016 at 05:37:38PM -0500, Tom Lendacky wrote:
> BOOT data (such as EFI related data) is not encyrpted when the system is
> booted and needs to be accessed as non-encrypted. Add support to the
> early_memremap API to identify the type of data being accessed so that
> the proper encr
On Mon, Aug 22, 2016 at 05:37:23PM -0500, Tom Lendacky wrote:
> Encrypt memory areas in place when possible (e.g. zero page, etc.) so
> that special handling isn't needed afterwards.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/head64.c | 93
> ++
On Thu, Sep 08, 2016 at 08:26:27AM -0500, Tom Lendacky wrote:
> When does this value get initialized? Since _PAGE_ENC is #defined to
> sme_me_mask, which is not set until the boot process begins, I'm afraid
> we'd end up using the initial value of sme_me_mask, which is zero. Do
> I have that righ
On Wed, Sep 07, 2016 at 09:30:54AM -0500, Tom Lendacky wrote:
> _PAGE_ENC is #defined as sme_me_mask and sme_me_mask has already been
> set (or not set) at this point - so it will be the mask if SME is
> active or 0 if SME is not active.
Yeah, I remember :-)
> sme_early_init() is merely propagati
On Wed, Sep 07, 2016 at 09:02:38AM -0500, Tom Lendacky wrote:
> Ugh.. I thought I caught all of these. Obviously not. I'll go through
> all the patches on this.
What you could do is run all patches through scripts/checkpatch.pl
and fix those issues which make sense to you. What I'm saying is, y
On Mon, Aug 22, 2016 at 05:37:10PM -0500, Tom Lendacky wrote:
> This adds support to be able to either encrypt or decrypt data during
> the early stages of booting the kernel. This does not change the memory
> encryption attribute - it is used for ensuring that data present in
> either an encrypted
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Update kernel boot support to call an SME routine t
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Update kernel boot support to call an SME routine t
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Update kernel boot support to call an SME routine t
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Update kernel boot support to call an SME routine t
On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote:
> Update the cpu features to include identifying and reporting on the
> Secure Memory Encryption feature.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cpufeature.h|7 +--
> arch/x86/include/asm/cpufeatu
201 - 300 of 352 matches
Mail list logo
