Re: [PATCH] Documentation: kdump: describe jumping to dump-capture kernel

[Dave Young]

Hi,
On 02/13/18 at 04:22pm, Gioh Kim wrote:
> Jumping between the system kernel and the dump-capture kernel
> has been supported for long time but there is no description
> how to use it. This patch adds the description how to use kexec tool
> to jump to the dump-capture kernel and jump back to the system kernel.

I do not think this should belong to kdump documentation.  There are a
lot of choices after a vmcore saving, one can reboot, halt, even go
ahead with real root filesystem init path.  We do not need to document
all these in kdump.txt.

Since it is a general use case not only for kdump, add more info in
kexec man page would be better.

> 
> Signed-off-by: Gioh Kim 
> ---
>  Documentation/kdump/kdump.txt | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 51814450a7f8..35b71fef5d88 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -460,6 +460,44 @@ and the system will boot into the dump-capture kernel.
>  For testing purposes, you can trigger a crash by using "ALT-SysRq-c",
>  "echo c > /proc/sysrq-trigger" or write a module to force the panic.
>  
> +Jump between the System kernel and the Dump-capture kernel
> +===
> +
> +Without system crash, the system can jump to the dump-capture kernel.
> +
> +1) Enable "jump between system kernel and dump-capture kernel" support under
> +   "Processor type and features"
> +
> +   CONFIG_KEXEC_JUMP=y
> +
> +2) Load the dump-capture kernel with --load-preserve-context and mem-max
> +   options as following.
> +
> +   kexec -l  \
> +   --initrd= --args-linux \
> +   --append="root= " \
> +   --load-preserve-context \
> +   --mem-max=
> +
> +3) Jump to the loaded kernel
> +
> +   kexec -e
> +
> +Now the system is running with the dump-capture kernel. You can jump back
> +to the system kernel.
> +
> +1) Find kexec_jump_back_entry address in kernel booting parameters in
> +   /proc/cmdline. That is the address for kexec to jump to. For example:
> +   kexec_jump_back_entry=0x000810d2
> +
> +2) Following command sets the jump-back address for kexec.
> +
> +   kexec --load-jump-back-helper --entry=0x810d2
> +
> +3) Jump to the system kernel
> +
> +   kexec -e
> +
>  Write Out the Dump File
>  ===
>  
> -- 
> 2.11.0
> 

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Dave Young]

On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, 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
> > as originally booted.
> 
> Hi Tom,
> 
> Looks like kdump will break, I didn't see the similar handling for kdump 
> cases, see kernel:
> kimage_alloc_crash_control_pages(), kimage_load_crash_segment(), etc.
> 
> We need to support kdump with SME, kdump 
> kernel/initramfs/purgatory/elfcorehdr/etc
> are all loaded into the reserved memory(see crashkernel=X) by userspace 
> kexec-tools.

For kexec_load, it is loaded by kexec-tools, we have in kernel loader
syscall kexec_file_load, it is handled in kernel.

> I think a straightforward way would be to mark the whole reserved memory 
> range without
> encryption before loading all the kexec segments for kdump, I guess we can 
> handle this
> easily in arch_kexec_unprotect_crashkres().
> 
> Moreover, now that "elfcorehdr=X" is left as decrypted, it needs to be 
> remapped to the
> encrypted data.

Tom, could you have a try on kdump according to suggestion from Xunlei?
It is just based on theoretical patch understanding, there could be
other issues when you work on it. Feel free to ask if we can help on
anything.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Dave Young]

Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.

On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> 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 kexec_load() syscall, AFAICT. And that code does a lot of
> things during that init, like machine_kexec_prepare()->init_pgtable() to
> prepare the ident mapping of the second kernel, for example.
> 
> What I'm aiming at is that the first kernel knows *exactly* whether SME
> is enabled or not and doesn't need to tell the second one through some
> sysfs entries - it can do that during loading.
> 
> So I don't think we need any userspace things at all...

If kdump kernel can get the SME status from hardware register then this
should be not necessary and this patch can be dropped.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Dave Young]

On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> >>> determine if SME is active.
> >>>
> >>> A new directory will be created:
> >>>   /sys/kernel/mm/sme/
> >>>
> >>> And two entries within the new directory:
> >>>   /sys/kernel/mm/sme/active
> >>>   /sys/kernel/mm/sme/encryption_mask
> >>
> >> Why do they care, and what will they be doing with this information?
> > 
> > Since kdump will copy old memory but need this to know if the old memory
> > was encrypted or not. With this sysfs file we can know the previous SME
> > status and pass to kdump kernel as like a kernel param.
> > 
> > Tom, have you got chance to try if it works or not?
> 
> What will the kdump kernel do with it though?  We kexec() into that
> kernel so the SME keys will all be the same, right?  So, will the kdump
> kernel be just setting the encryption bit in the PTE so it can copy the
> old plaintext out?

I assume it is for active -> non active case, the new boot need to know
the old memory is encrypted. But I think I did not read all the patches
I may miss things.

> 
> Why do we need both 'active' and 'encryption_mask'?  How could it be
> that the hardware-enumerated 'encryption_mask' changes across a kexec()?

Leave this question to Tom..

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Dave Young]

On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> > 
> > A new directory will be created:
> >   /sys/kernel/mm/sme/
> > 
> > And two entries within the new directory:
> >   /sys/kernel/mm/sme/active
> >   /sys/kernel/mm/sme/encryption_mask
> 
> Why do they care, and what will they be doing with this information?

Since kdump will copy old memory but need this to know if the old memory
was encrypted or not. With this sysfs file we can know the previous SME
status and pass to kdump kernel as like a kernel param.

Tom, have you got chance to try if it works or not?

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

[Dave Young]

On 03/06/17 at 11:58am, Tom Lendacky wrote:
> On 3/1/2017 3:25 AM, Dave Young wrote:
> > Hi Tom,
> 
> Hi Dave,
> 
> > 
> > On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > > 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.
> > > > 
> > > > Is the point of kexec and kdump to ehh, dump memory ? But if the
> > > > rest of the memory is encrypted you won't get much, will you?
> > > 
> > > Kexec can be used to reboot a system without going back through BIOS.
> > > So you can use kexec without using kdump.
> > > 
> > > For kdump, just taking a quick look, the option to enable memory
> > > encryption can be provided on the crash kernel command line and then
> > 
> > Is there a simple way to get the SME status? Probably add some sysfs
> > file for this purpose.
> 
> Currently there is not.  I can look at adding something, maybe just the
> sme_me_mask value, which if non-zero, would indicate SME is active.
> 
> > 
> > > crash kernel can would be able to copy the memory decrypted if the
> > > pagetable is set up properly. It looks like currently ioremap_cache()
> > > is used to map the old memory page.  That might be able to be changed
> > > to a memremap() so that the encryption bit is set in the mapping. That
> > > will mean that memory that is not marked encrypted (EFI tables, swiotlb
> > > memory, etc) would not be read correctly.
> > 
> > Manage to store info about those ranges which are not encrypted so that
> > memremap can handle them?
> 
> I can look into whether something can be done in this area. Any input
> you can provide as to what would be the best way/place to store the
> range info so kdump can make use of it, would be greatly appreciated.

Previously to support efi runtime in kexec, I passed some efi
infomation via setup_data, see below userspace kexec-tools commit:
e1ffc9e9a0769e1f54185003102e9bec428b84e8, it was what Boris mentioned
about the setup_data use case for kexec.

Suppose you have successfully tested kexec reboot, so the EFI tables you
mentioned should be those area in old mem for copying /proc/vmcore? If
only EFI tables and swiotlb maybe not worth to passing those stuff
across kexec reboot.

I have more idea about this for now..
> 
> > 
> > > 
> > > > 
> > > > Would it make sense to include some printk to the user if they
> > > > are setting up kdump that they won't get anything out of it?
> > > 
> > > Probably a good idea to add something like that.
> > 
> > It will break kdump functionality, it should be fixed instead of
> > just adding printk to warn user..
> 
> I do want kdump to work. I'll investigate further what can be done in
> this area.

Thanks a lot!

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

[Dave Young]

On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data.  This will make the appropriate
> decision as to whether a RAM remapping can be done or if a fallback to
> ioremap_cache() is needed (similar to the setup data debugfs support).
> 
> Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
> ---
>  arch/x86/kernel/ksysfs.c |   27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
> index 4afc67f..d653b3e 100644
> --- a/arch/x86/kernel/ksysfs.c
> +++ b/arch/x86/kernel/ksysfs.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -79,12 +80,12 @@ static int get_setup_data_paddr(int nr, u64 *paddr)
>   *paddr = pa_data;
>   return 0;
>   }
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
>   if (!data)
>   return -ENOMEM;
>  
>   pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
>   i++;
>   }
>   return -EINVAL;
> @@ -97,17 +98,17 @@ static int __init get_setup_data_size(int nr, size_t 
> *size)
>   u64 pa_data = boot_params.hdr.setup_data;
>  
>   while (pa_data) {
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
>   if (!data)
>   return -ENOMEM;
>   if (nr == i) {
>   *size = data->len;
> - iounmap(data);
> + memunmap(data);
>   return 0;
>   }
>  
>   pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
>   i++;
>   }
>   return -EINVAL;
> @@ -127,12 +128,12 @@ static ssize_t type_show(struct kobject *kobj,
>   ret = get_setup_data_paddr(nr, );
>   if (ret)
>   return ret;
> - data = ioremap_cache(paddr, sizeof(*data));
> + data = memremap(paddr, sizeof(*data), MEMREMAP_WB);
>   if (!data)
>   return -ENOMEM;
>  
>   ret = sprintf(buf, "0x%x\n", data->type);
> - iounmap(data);
> + memunmap(data);
>   return ret;
>  }
>  
> @@ -154,7 +155,7 @@ static ssize_t setup_data_data_read(struct file *fp,
>   ret = get_setup_data_paddr(nr, );
>   if (ret)
>   return ret;
> - data = ioremap_cache(paddr, sizeof(*data));
> + data = memremap(paddr, sizeof(*data), MEMREMAP_WB);
>   if (!data)
>   return -ENOMEM;
>  
> @@ -170,15 +171,15 @@ static ssize_t setup_data_data_read(struct file *fp,
>   goto out;
>  
>   ret = count;
> - p = ioremap_cache(paddr + sizeof(*data), data->len);
> + p = memremap(paddr + sizeof(*data), data->len, MEMREMAP_WB);
>   if (!p) {
>   ret = -ENOMEM;
>   goto out;
>   }
>   memcpy(buf, p + off, count);
> - iounmap(p);
> + memunmap(p);
>  out:
> - iounmap(data);
> + memunmap(data);
>   return ret;
>  }
>  
> @@ -250,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data, 
> int *nr)
>   *nr = 0;
>   while (pa_data) {
>   *nr += 1;
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
>   if (!data) {
>   ret = -ENOMEM;
>   goto out;
>   }
>   pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
>   }
>  
>  out:
> 

It would be better that these cleanup patches are sent separately.

Acked-by: Dave Young <dyo...@redhat.com>

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

[Dave Young]

On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data.  This simplifies the code and will
> make the appropriate decision as to whether a RAM remapping can be done
> or if a fallback to ioremap_cache() is needed (which includes checking
> PageHighMem).
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kernel/kdebugfs.c |   30 +++---
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
> index bdb83e4..c3d354d 100644
> --- a/arch/x86/kernel/kdebugfs.c
> +++ b/arch/x86/kernel/kdebugfs.c
> @@ -48,17 +48,13 @@ static ssize_t setup_data_read(struct file *file, char 
> __user *user_buf,
>  
>   pa = node->paddr + sizeof(struct setup_data) + pos;
>   pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
> - if (PageHighMem(pg)) {
> - p = ioremap_cache(pa, count);
> - if (!p)
> - return -ENXIO;
> - } else
> - p = __va(pa);
> + p = memremap(pa, count, MEMREMAP_WB);
> + if (!p)
> + return -ENXIO;

-ENOMEM looks better for memremap, ditto for other places..

>  
>   remain = copy_to_user(user_buf, p, count);
>  
> - if (PageHighMem(pg))
> - iounmap(p);
> + memunmap(p);
>  
>   if (remain)
>   return -EFAULT;
> @@ -127,15 +123,12 @@ static int __init create_setup_data_nodes(struct dentry 
> *parent)
>   }
>  
>   pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
> - if (PageHighMem(pg)) {
> - data = ioremap_cache(pa_data, sizeof(*data));
> - if (!data) {
> - kfree(node);
> - error = -ENXIO;
> - goto err_dir;
> - }
> - } else
> - data = __va(pa_data);
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
> + if (!data) {
> + kfree(node);
> + error = -ENXIO;
> + goto err_dir;
> + }
>  
>   node->paddr = pa_data;
>   node->type = data->type;
> @@ -143,8 +136,7 @@ static int __init create_setup_data_nodes(struct dentry 
> *parent)
>   error = create_setup_data_node(d, no, node);
>   pa_data = data->next;
>  
> - if (PageHighMem(pg))
> - iounmap(data);
> + memunmap(data);
>   if (error)
>   goto err_dir;
>   no++;
> 

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

[Dave Young]

On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
> +   unsigned long size)
> +{
> + /*
> +  * SME is not active, return true:
> +  *   - For early_memremap_pgprot_adjust(), returning true or false
> +  * results in the same protection value
> +  *   - For arch_memremap_do_ram_remap(), returning true will allow
> +  * the RAM remap to occur instead of falling back to ioremap()
> +  */
> + if (!sme_active())
> + return true;

>From the function name shouldn't above be return false? 

> +
> + /* Check if the address is part of the setup data */
> + if (memremap_is_setup_data(phys_addr, size))
> + return false;
> +
> + /* Check if the address is part of EFI boot/runtime data */
> + switch (efi_mem_type(phys_addr)) {
> + case EFI_BOOT_SERVICES_DATA:
> + case EFI_RUNTIME_SERVICES_DATA:

Only these two types needed? I'm not sure about this, just bring up the
question.

> + return false;
> + default:
> + break;
> + }
> +
> + /* Check if the address is outside kernel usable area */
> + switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> + case E820_TYPE_RESERVED:
> + case E820_TYPE_ACPI:
> + case E820_TYPE_NVS:
> + case E820_TYPE_UNUSABLE:
> + return false;
> + default:
> + break;
> + }
> +
> + return true;
> +}
> +

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

[Dave Young]

Hi Tom,

On 02/17/17 at 10:43am, Tom Lendacky wrote:
> On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > 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.
> > 
> > Is the point of kexec and kdump to ehh, dump memory ? But if the
> > rest of the memory is encrypted you won't get much, will you?
> 
> Kexec can be used to reboot a system without going back through BIOS.
> So you can use kexec without using kdump.
> 
> For kdump, just taking a quick look, the option to enable memory
> encryption can be provided on the crash kernel command line and then

Is there a simple way to get the SME status? Probably add some sysfs
file for this purpose.

> crash kernel can would be able to copy the memory decrypted if the
> pagetable is set up properly. It looks like currently ioremap_cache()
> is used to map the old memory page.  That might be able to be changed
> to a memremap() so that the encryption bit is set in the mapping. That
> will mean that memory that is not marked encrypted (EFI tables, swiotlb
> memory, etc) would not be read correctly.

Manage to store info about those ranges which are not encrypted so that
memremap can handle them?

> 
> > 
> > Would it make sense to include some printk to the user if they
> > are setting up kdump that they won't get anything out of it?
> 
> Probably a good idea to add something like that.

It will break kdump functionality, it should be fixed instead of
just adding printk to warn user..

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

[Dave Young]

Add kexec list..

On 03/01/17 at 05:25pm, Dave Young wrote:
> Hi Tom,
> 
> On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > 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.
> > > 
> > > Is the point of kexec and kdump to ehh, dump memory ? But if the
> > > rest of the memory is encrypted you won't get much, will you?
> > 
> > Kexec can be used to reboot a system without going back through BIOS.
> > So you can use kexec without using kdump.
> > 
> > For kdump, just taking a quick look, the option to enable memory
> > encryption can be provided on the crash kernel command line and then
> 
> Is there a simple way to get the SME status? Probably add some sysfs
> file for this purpose.
> 
> > crash kernel can would be able to copy the memory decrypted if the
> > pagetable is set up properly. It looks like currently ioremap_cache()
> > is used to map the old memory page.  That might be able to be changed
> > to a memremap() so that the encryption bit is set in the mapping. That
> > will mean that memory that is not marked encrypted (EFI tables, swiotlb
> > memory, etc) would not be read correctly.
> 
> Manage to store info about those ranges which are not encrypted so that
> memremap can handle them?
> 
> > 
> > > 
> > > Would it make sense to include some printk to the user if they
> > > are setting up kdump that they won't get anything out of it?
> > 
> > Probably a good idea to add something like that.
> 
> It will break kdump functionality, it should be fixed instead of
> just adding printk to warn user..
> 
> Thanks
> Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

[Dave Young]

Hi Tom,

On 02/16/17 at 09:41am, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
> 
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be automatically
> decrypted when read from DRAM and will be automatically encrypted when
> written to DRAM. Details on SME can found in the links below.
> 
> The SME feature is identified through a CPUID function and enabled through
> the SYSCFG MSR. Once enabled, page table entries will determine how the
> memory is accessed. If a page table entry has the memory encryption mask set,
> then that memory will be accessed as encrypted memory. The memory encryption
> mask (as well as other related information) is determined from settings
> returned through the same CPUID function that identifies the presence of the
> feature.
> 
> The approach that this patch series takes is to encrypt everything possible
> starting early in the boot where the kernel is encrypted. Using the page
> table macros the encryption mask can be incorporated into all page table
> entries and page allocations. By updating the protection map, userspace
> allocations are also marked encrypted. Certain data must be accounted for
> as having been placed in memory before SME was enabled (EFI, initrd, etc.)
> and accessed accordingly.
> 
> This patch series is a pre-cursor to another AMD processor feature called
> Secure Encrypted Virtualization (SEV). The support for SEV will build upon
> the SME support and will be submitted later. Details on SEV can be found
> in the links below.
> 
> The following links provide additional detail:
> 
> AMD Memory Encryption whitepaper:
>
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> 
> AMD64 Architecture Programmer's Manual:
>http://support.amd.com/TechDocs/24593.pdf
>SME is section 7.10
>SEV is section 15.34
> 
> This patch series is based off of the master branch of tip.
>   Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")
> 
> ---
> 
> Still to do: IOMMU enablement support
> 
> Changes since v3:
> - Broke out some of the patches into smaller individual patches
> - Updated Documentation
> - Added a message to indicate why the IOMMU was disabled
> - Updated CPU feature support for SME by taking into account whether
>   BIOS has enabled SME
> - Eliminated redundant functions
> - Added some warning messages for DMA usage of bounce buffers when SME
>   is active
> - Added support for persistent memory
> - Added support to determine when setup data is being mapped and be sure
>   to map it un-encrypted
> - Added CONFIG support to set the default action of whether to activate
>   SME if it is supported/enabled
> - Added support for (re)booting with kexec

Could you please add kexec list in cc when you updating the patches so
that kexec/kdump people do not miss them?

> 
> Changes since v2:
> - Updated Documentation
> - Make the encryption mask available outside of arch/x86 through a
>   standard include file
> - Conversion of assembler routines to C where possible (not everything
>   could be converted, e.g. the routine that does the actual encryption
>   needs to be copied into a safe location and it is difficult to
>   determine the actual length of the function in order to copy it)
> - Fix SME feature use of scattered CPUID feature
> - Creation of SME specific functions for things like encrypting
>   the setup data, ramdisk, etc.
> - New take on early_memremap / memremap encryption support
> - Additional support for accessing video buffers (fbdev/gpu) as
>   un-encrypted
> - Disable IOMMU for now - need to investigate further in relation to
>   how it needs to be programmed relative to accessing physical memory
> 
> Changes since v1:
> - Added Documentation.
> - Removed AMD vendor check for setting the PAT write protect mode
> - Updated naming of trampoline flag for SME as well as moving of the
>   SME check to before paging is enabled.
> - Change to early_memremap to identify the data being mapped as either
>   boot data or kernel data.  The idea being that boot data will have
>   been placed in memory as un-encrypted data and would need to be accessed
>   as such.
> - Updated debugfs support for the bootparams to access the data properly.
> - Do not set the SYSCFG[MEME] bit, only check it.  The setting of the
>   MemEncryptionModeEn bit results in a reduction of physical address size
>   of the processor.  It is possible that BIOS could have configured resources
>   resources into a range that will now not be addressable.  To prevent this,
>   rely on BIOS to set the SYSCFG[MEME] bit and only then enable memory
>   encryption support in the kernel.
> 
> Tom Lendacky (28):
>   x86: Documentation for AMD Secure Memory Encryption (SME)
>   x86: Set the write-protect cache mode for full PAT support
>   x86: Add the 

Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

[Dave Young]

On 08/17/16 at 07:36pm, Joe Perches wrote:
> On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> > nr_cpus can help to save memory. So we should remind user of it.
> 
> trivia:
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> []
> > @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel:
> >  * Boot parameter "1" boots the dump-capture kernel into single-user
> >    mode without networking. If you want networking, use "3".
> >  
> > -* We generally don' have to bring up a SMP kernel just to capture the
> > +* We generally don' have to bring up an SMP kernel just to capture the
> 
> don't or do not
> 

Use do not is better, also need replace 'We' with 'You' to be
consistent with other part.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] Documentation: kdump: add description of enable multi-cpus support

[Dave Young]

On 08/10/16 at 02:22pm, Zhou Wenjian wrote:
> multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
> 
> Signed-off-by: Zhou Wenjian 
> Acked-by: Baoquan He 
> ---
>  Documentation/kdump/kdump.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index b474060..9c8d18e 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
>Note, though maxcpus always works, we should replace it by nr_cpus to
>save memory if supported by the current ARCH, such as x86.
>  
> +* We should enable multi-cpu support in dump-capture kernel if we intend
> +  to use multi-thread programs with it, such as parallel dump feature of
> +  makedumpfile. Otherwise, the multi-thread program may have a great
> +  performance degradation. To enable multi-cpu support, we should bring up
> +  a SMP dump-capture kernel and specify maxcpus\nr_cpus, disable_cpu_apic=[X]
> +  options while loading it.

Again, please replace "we" with second person "you"..

> +
>  * For s390x there are two kdump modes: If a ELF header is specified with
>the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
>is done on all other architectures. If no elfcorehdr= kernel parameter is
> -- 
> 1.8.3.1
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

Hi, Russell

On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.

I think getting memory ranges from device tree will be better than
adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
you can refer to the patchset.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: fix crashkernel= handling

[Dave Young]

On 04/01/16 at 02:25pm, Russell King - ARM Linux wrote:

[snip]

> Well, if we want to remove it, we then need to sort out a method of
> specifying a limit on the address - where platforms physical memory
> bridges the 4GB CPU-accessible limit, the crashkernel region must be
> allocated below that so that it is boot-time accessible.
> 
> Some patches also have boot-time only aliases of RAM, with the normal
> alias above 4GB (eg, TI Keystone2) where the running view of RAM is
> at 0x8, but it has a non-coherent boot alias at 0x8000.
> 
> I've patches which resolve some of the issues there, and making that
> change would make this patch dependent on those changes.  So, I
> recommend that this patch remains as-is for the time being, and this
> issue is addressed in a later patch after the Keystone2 idmap_to_phys()
> patches, similar to:
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 0a12fcf1aff6..74781e6d4e87 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -962,7 +962,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN  (128 << 20)
> -#define CRASH_ADDR_MAX   (PHYS_OFFSET + (512 << 20))
>  
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -992,7 +991,8 @@ static void __init reserve_crashkernel(void)
>   return;
>  
>   if (crash_base <= 0) {
> - crash_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_MAX,
> + unsigned long long crash_max = idmap_to_phys((u32)~0);
> + crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>   crash_size, CRASH_ALIGN);
>   if (!crash_base) {
>   pr_err("crashkernel reservation failed - No suitable 
> area found.\n");
> 
> Right now, I don't want to tie this facility to TI Keystone2 support
> as what this patch is doing is something that the ARM kexec support
> should have been doing since it was first introduced, so folk may
> want to backport this change to stable trees.

Is it possible for PHYS_OFFSET + (512 << 20) be larger than 4G assume that 
phys_addr_t is 32bit, if so it can be trunked to a small value then
the max will be wrong?

Otherwise I think use it temprarily is fine.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: fix crashkernel= handling

[Dave Young]

Hi, Russell

A long standing issue, but nobody tried to do it. Thank you for bringing up.

On 03/29/16 at 11:10am, Russell King wrote:
> When the kernel crashkernel parameter is specified with just a size, we
> are supposed to allocate a region from RAM to store the crashkernel.
> However, ARM merely reserves physical address zero with no checking
> that there is even RAM there.
> 
> Fix this by lifting similar code from x86, importing it to ARM with
> the ARM specific parameters added.
> 
> Update the kdump documentation to reflect this change.
> 
> Signed-off-by: Russell King 
> ---
>  Documentation/kdump/kdump.txt | 13 +++--
>  arch/arm/kernel/setup.c   | 26 ++
>  2 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index bc4bd5a44b88..88ff63d5fde3 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -263,12 +263,6 @@ been removed from the machine.
>  crashkernel=:[,:,...][@offset]
>  range=start-[end]
>  
> -Please note, on arm, the offset is required.
> -crashkernel=:[,:,...]@offset
> -range=start-[end]
> -
> -'start' is inclusive and 'end' is exclusive.
> -
>  For example:
>  
>  crashkernel=512M-2G:64M,2G-:128M
> @@ -307,10 +301,9 @@ Boot into System Kernel
> on the memory consumption of the kdump system. In general this is not
> dependent on the memory size of the production system.
>  
> -   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
> -   will be aligned to 128MiB (0x0800), so if the start address is not 
> then
> -   any space below the alignment point may be overwritten by the 
> dump-capture kernel,
> -   which means it is possible that the vmcore is not that precise as 
> expected.
> +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>  
>  
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 7d0cba6f1cc5..5d8511c425f0 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>  
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN  (128 << 20)
> +#define CRASH_ADDR_MAX   (PHYS_OFFSET + (512 << 20))

Any reason to limit crash mem within the first 512M only? What if one want to
reserve memory over 512M?

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html