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
>
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 ++
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
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: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
> ---
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 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
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
)
"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(-)
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
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 +++---
>
; 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
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
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
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 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
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
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
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
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
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 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
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 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
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: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 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: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: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: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: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: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: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: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: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: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: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 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 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 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 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 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 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 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: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: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: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: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 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 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 Thu, Feb 16, 2017 at 09:48:08AM -0600, Tom Lendacky wrote:
> This patch adds the support to encrypt the kernel in-place. This is
> done by creating new page mappings for the kernel - a decrypted
> write-protected mapping and an encrypted mapping. The kernel is encyrpted
s/encyrpted/encrypted/
On Thu, Feb 16, 2017 at 09:48:25AM -0600, Tom Lendacky wrote:
> This patch adds the support to check if SME has been enabled and if
> memory encryption should be activated (checking of command line option
> based on the configuration of the default state). If memory encryption
> is to be activated
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 PG
On Tue, Feb 28, 2017 at 04:34:39PM -0600, Tom Lendacky wrote:
> Or if we want to guard against ACPI adding a type 0 in the future, I
> could make the function return an int and then return -EINVAL if an e820
> entry isn't found. This might be the better option.
Yap, think so too. I don't trust sp
On Tue, Mar 07, 2017 at 10:05:00AM -0600, Tom Lendacky wrote:
> I can do that. Because phys_base hasn't been updated yet, I'll have to
> create "on" and "off" constants and get their address in a similar way
> to the command line option so that I can do the strncmp properly.
Actually, wouldn't it
On Tue, Mar 07, 2017 at 10:05:00AM -0600, Tom Lendacky wrote:
> > And then you need to correct the function signature in the
> > !CONFIG_AMD_MEM_ENCRYPT case, at the end of this file, too:
> >
> > unsigned long __init sme_enable(struct boot_params *bp) {
> > return 0; }
>
> Yup, miss
ce amd_iommu-specific struct with required
> parameters to be programmed onto the IOMMU performance counter
> control register.
>
> Also update the pasid field from 16 to 20 bits.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee Suthikulpan
ce amd_iommu-specific struct with required
> parameters to be programmed onto the IOMMU performance counter
> control register.
>
> Also update the pasid field from 16 to 20 bits.
>
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Signed-off-by: Suravee Suthikulpani
in the cr3 register, allowing the PGD table to be encrypted. Each successive
I missed that the last time: do you mean here, "The encryption bit can
be specified in the %cr3 register allowing for the page table hierarchy
itself to be encrypted."?
> +level of page tables can also be en
On Wed, Apr 19, 2017 at 09:23:47AM -0500, Tom Lendacky wrote:
> Btw, I tried to update all the subjects and descriptions to be
> more descriptive but I'm sure there is still room for improvement
> so keep the comments on them coming.
No worries there :)
> Note, just because the bit is set in %cr3
On Tue, Apr 18, 2017 at 04:17:11PM -0500, 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/amd.c | 14 ++
On Thu, Apr 20, 2017 at 12:29:20PM -0500, Tom Lendacky wrote:
> Hmmm... and actually if cpu_has(X86_FEATURE_SME) is true then it's a
> given that extended_cpuid_level >= 0x801f. So this can be
> simplified to just:
>
> if (cpu_has(c, X86_FEATURE_SME)) {
> ... the rest of y
On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote:
> Add support to the early boot code to use Secure Memory Encryption (SME).
> Since the kernel has been loaded into memory in a decrypted state, support
> is added to encrypt the kernel in place and update the early pagetables
s/support
On Tue, Apr 18, 2017 at 04:17:27PM -0500, 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 Tue, Apr 18, 2017 at 04:17:54PM -0500, Tom Lendacky wrote:
> Changes to the existing page table macros will allow the SME support to
> be enabled in a simple fashion with minimal changes to files that use these
> macros. Since the memory encryption mask will now be part of the regular
> pagetab
On Tue, Apr 18, 2017 at 04:18:22PM -0500, 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, May 04, 2017 at 09:24:11AM -0500, Tom Lendacky wrote:
> I did this so that an the include order wouldn't cause issues (including
> asm/mem_encrypt.h followed by later by a linux/mem_encrypt.h include).
> I can make this a bit clearer by having separate #defines for each
> thing, e.g.:
>
>
On Thu, May 04, 2017 at 09:34:09AM -0500, Tom Lendacky wrote:
> I masked it out here based on a previous comment from Dave Hansen:
>
> http://marc.info/?l=linux-kernel&m=148778719826905&w=2
>
> I could move the __sme_clr into the individual defines of:
Nah, it is fine as it is. I was just wond
On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote:
> Add a function that will return the E820 type associated with an address
> range.
...
> @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum
> e820_type type)
>* coverage of the desired range ex
On Tue, Apr 18, 2017 at 04:19:00PM -0500, Tom Lendacky wrote:
> The efi_mem_type() function currently returns a 0, which maps to
> EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for
> the supplied physical address. Returning EFI_RESERVED_TYPE implies that
> a memmap entry exist
On Tue, Apr 18, 2017 at 04:18:48PM -0500, Tom Lendacky wrote:
> Add a function that will determine if a supplied physical address matches
> the address of an EFI table.
>
> Signed-off-by: Tom Lendacky
> ---
> drivers/firmware/efi/efi.c | 33 +
> include/linux/ef
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted because UEFI/BIOS does not run with SME active. In order to access
> this data properly it needs to be mapped decrypted.
>
> The early_memremap() suppor
On Tue, Apr 18, 2017 at 04:19:30PM -0500, Tom Lendacky wrote:
> The SMP MP-table is built by UEFI and placed in memory in a decrypted
> state. These tables are accessed using a mix of early_memremap(),
> early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
> to use early_memrema
On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote:
> Persistent memory is expected to persist across reboots. The encryption
> key used by SME will change across reboots which will result in corrupted
> persistent memory. Persistent memory is handed out by block devices
> through memory
On Tue, Apr 18, 2017 at 04:20:10PM -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 Tue, Apr 18, 2017 at 04:20:19PM -0500, 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 Tue, Apr 18, 2017 at 04:20:56PM -0500, Tom Lendacky wrote:
> Since video memory needs to be accessed decrypted, be sure that the
> memory encryption mask is not set for the video ranges.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/vga.h | 13 +
> arch/x86/
On Tue, May 16, 2017 at 02:28:42PM -0500, Tom Lendacky wrote:
> It's most problematic when CONFIG_AMD_MEM_ENCRYPT is not defined since
> we never include an asm/ version from the linux/ path. I could create
> a mem_encrypt.h in include/asm-generic/ that contains the info that
> is in the !CONFIG_A
On Tue, Apr 18, 2017 at 04:21:21PM -0500, 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 Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote:
> I was worried what the compiler might do when CONFIG_EFI is not set,
> but it appears to take care of it. I'll double check though.
There's a efi_enabled() !CONFIG_EFI version too, so should be fine.
> I may introduce a length variab
On Wed, May 17, 2017 at 03:26:58PM -0500, Tom Lendacky wrote:
> > Also, simplify that test:
> >
> > if (mpf->feature1)
> > ...
>
> Ok, I can do that but I hope no one says anything about it being
> unrelated to the patch. :)
Bah, that's minor.
--
Regards/Gruss,
Boris.
Good
On Tue, Apr 18, 2017 at 04:21:49PM -0500, Tom Lendacky wrote:
> Add the support to encrypt the kernel in-place. This is done by creating
> new page mappings for the kernel - a decrypted write-protected mapping
> and an encrypted mapping. The kernel is encrypted by copying it through
> a temporary b
On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> determine if SME is active.
But why do user-space tools need to know that?
I mean, when we load the kdump kernel, we do it with the first kernel,
with the kex
On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state). If memory encryption is to be
> activated, then the encry
On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
> On 4/18/2017 4:22 PM, Tom Lendacky wrote:
> > Add support to check if SME has been enabled and if memory encryption
> > should be activated (checking of command line option based on the
> > configuration of the default state). If memo
On Fri, May 19, 2017 at 03:16:51PM -0500, Josh Poimboeuf wrote:
> I'm the stack validation guy, not the stack protection guy :-)
LOL. I thought you were *the* stacks guy. :-)))
But once you've validated it, you could protect it then too. :-)
--
Regards/Gruss,
Boris.
Good mailing practices
On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote:
> Actually there is. The above will result in data in the cache because
> halt() turns into a function call if CONFIG_PARAVIRT is defined (refer
> to the comment above where do_wbinvd_halt is set to true). I could make
> this a native_w
On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote:
> As long as those never change from static inline everything will be
> fine. I can change it, but I really like how it explicitly indicates
I know what you want to do. But you're practically defining a helper
which contains two arbitra
On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote:
> The "worker" function would be doing the loop through the setup data,
> but since the setup data is mapped inside the loop I can't do the __init
> calling the non-init function and still hope to consolidate the code.
> Maybe I'm missin
On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote:
> I guess I could do that, but this will probably only end up clearing a
> single PGD entry anyway since it's highly doubtful the address range
> would cross a 512GB boundary.
Or you can compute how many 512G-covering, i.e., PGD entries
On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote:
> In addition to the same issue as efi.memmap.phys_map, efi_phys has
> the __initdata attribute so it will be released/freed which will cause
> problems in checks performed afterwards.
Sounds to me like we should drop the __initdata att
On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote:
> In this case we're running identity mapped and the "on" constant ends up
> as kernel address (0x81...) which results in a segfault.
Would
static const char *__on_str = "on";
...
if (!strncmp(buffer,
On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote:
> I can define the command line option and the "on" and "off" values as
> character buffers in the function and initialize them on a per character
> basis (using a static string causes the same issues as referencing a
> string constant),
On Tue, May 30, 2017 at 10:48:27AM -0500, Tom Lendacky wrote:
> I'll look at doing that instead of removing the support for the whole
> file.
Right, so I don't think the stack protector is even ready that early -
we do set it up later:
/* Set up %gs.
*
* The base of %gs
On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote:
> Yes, it's from objtool:
>
> arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return
> instruction outside of a callable function
Oh, well, let's make it a global symbol then. Who knows, we might have
to live-patch it som
On Tue, May 30, 2017 at 12:46:14PM -0500, Tom Lendacky wrote:
> This is an area that I'm not familiar with, so I don't completely
> understand the flow in regards to where/when/how the ELF headers are
> copied and what needs to be done.
So my suggestion is still to put kexec/kdump on the backburne
On Tue, May 30, 2017 at 11:46:52AM -0500, Tom Lendacky wrote:
> Check if you have CONFIG_DEBUG_SECTION_MISMATCH=y
$ grep MISM .config
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
Still no joy.
Can you give me your .config?
--
Regards/Gruss,
Boris.
Good mailing pract
On Wed, May 31, 2017 at 08:37:50AM -0500, Tom Lendacky wrote:
> I like keeping the command line option and the values together. It may
> not look the greatest but I like it more than defining the command line
> option in head_64.S and passing it in as an argument.
>
> OTOH, I don't think the rip-r
On Wed, May 31, 2017 at 11:03:52PM +0800, Xunlei Pang wrote:
> For kdump case, it will be put in some reserved crash memory allocated
> by kexec-tools, and passed the corresponding start address of the
> allocated reserved crash memory to kdump kernel via "elfcorehdr=",
> please see kernel function
1 - 100 of 352 matches
Mail list logo
