Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'
在 2018年12月07日 04:11, Borislav Petkov 写道: > On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote: >> I have noticed the changes on x86, but for IA64, i'm not sure whether it >> should do the same >> thing, so keep it as before. >> >> If IA64 people would like to give any comment, that will be appreciated. > > I think you should not touch ia64 and not make Tony unnecessarily power > up the old rust. > > :-) > Ok, it's good to me. And i will get rid of these changes for ia64 in patch v9. Thanks. Lianbo ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/2 v2] kdump, vmcoreinfo: Export the value of sme mask to vmcoreinfo
在 2018年12月05日 18:24, Dave Young 写道:
> On 12/02/18 at 11:08am, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
>> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
>> contains the memory encryption mask, so need to remove the sme mask
>> to obtain the true physical address.
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/kernel/machine_kexec_64.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 4c8acdfdc5a7..1860fe24117d 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -352,10 +352,24 @@ void machine_kexec(struct kimage *image)
>>
>> void arch_crash_save_vmcoreinfo(void)
>> {
>> +u64 sme_mask = sme_me_mask;
>> +
>> VMCOREINFO_NUMBER(phys_base);
>> VMCOREINFO_SYMBOL(init_top_pgt);
>> vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
>> pgtable_l5_enabled());
>> +/*
>> + * Currently, the local variable 'sme_mask' stores the value of
>> + * sme_me_mask(bit 47), and also write the value of sme_mask to
>> + * the vmcoreinfo.
>> + * If need, the bit(sme_mask) might be redefined in the future,
>> + * but the 'bit63' will be reserved.
>> + * For example:
>> + * [ misc ][ enc bit ][ other misc SME info ]
>> + * ____1000______..._
>> + * 63 59 55 51 47 43 39 35 31 27 ... 3
>> + */
>> +VMCOREINFO_NUMBER(sme_mask);
>
> #define VMCOREINFO_NUMBER(name) \
> vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
>
> VMCOREINFO_NUMBER is defined as above, so it looks questionable to add
> more users of that for different data types although it may work in real
> world.
>
Thank you, Dave.
For the sme_mask, the bit47 is set '1', and the VMCOREINFO_NUMBER is a signed
64 bit number(x86_64), it is big enough to the sme_mask.
> A new macro like below may be better, may need to choose a better name
> though:
> _VMCOREINFO_NUMBER(name, format, type)
> so you can pass the format specifier and data types explictly
>
That should be a good suggestion. But for now, maybe it is not time for
improving it.
Because it is still big enough.
Thanks.
Lianbo
>
>>
>> #ifdef CONFIG_NUMA
>> VMCOREINFO_SYMBOL(node_data);
>> --
>> 2.17.1
>>
>
> Thanks
> Dave
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 4/4] kexec/kexec-arm64.c: Add missing error handling paths
Hello Akashi,
Thanks for your review and sorry for my late reply.
It seems I found the root cause of the issue and it is quite different
from what I was thinking before.
The issue happens because we pass '/chosen' string to
'fdt_add_subnode()' in 'kexec/dt-ops.c' instead of 'chosen' string.
The different strings being passed to 'fdt_add_subnode()' and
'fdt_path_offset()' are 'chosen' and '/chosen' respectively for
adding/finding offset of the '/chosen' node in the kernel, see
'drivers/firmware/efi/libstub/fdt.c' for details of such use-cases.
When I fix the 'kexec-tools' to pass the same strings according to the
function being called, it fixes all the 'kexec -l' and 'kexec -p'
use-cases I could try on my boards, including the '--dtb' use cases.
So, I think this should be a workable solution.
@Vicente: Can you please drop the earlier approaches I shared and just
try the hack'ish patch below. If this works for all the use-cases at
your side, I can try and send a formal version of this one out.
Thanks,
Bhupesh
/--/
>From 7fb5e848cef268f6c3c61e001050cfd9202f5790 Mon Sep 17 00:00:00 2001
From: Bhupesh Sharma
Date: Sun, 2 Dec 2018 02:07:56 +0530
Subject: [PATCH] arm64: Fix fdt handling
Signed-off-by: Bhupesh Sharma
---
kexec/dt-ops.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/kexec/dt-ops.c b/kexec/dt-ops.c
index 915dbf55afd2..33d9b14900a9 100644
--- a/kexec/dt-ops.c
+++ b/kexec/dt-ops.c
@@ -9,6 +9,7 @@
#include "dt-ops.h"
static const char n_chosen[] = "/chosen";
+static const char chosen[] = "chosen";
static const char p_bootargs[] = "bootargs";
static const char p_initrd_start[] = "linux,initrd-start";
@@ -26,7 +27,7 @@ int dtb_set_initrd(char **dtb, off_t *dtb_size,
off_t start, off_t end)
value = cpu_to_fdt64(start);
-result = dtb_set_property(dtb, dtb_size, n_chosen, p_initrd_start,
+result = dtb_set_property(dtb, dtb_size, chosen, p_initrd_start,
, sizeof(value));
if (result)
@@ -34,11 +35,11 @@ int dtb_set_initrd(char **dtb, off_t *dtb_size,
off_t start, off_t end)
value = cpu_to_fdt64(end);
-result = dtb_set_property(dtb, dtb_size, n_chosen, p_initrd_end,
+result = dtb_set_property(dtb, dtb_size, chosen, p_initrd_end,
, sizeof(value));
if (result) {
-dtb_delete_property(*dtb, n_chosen, p_initrd_start);
+dtb_delete_property(*dtb, chosen, p_initrd_start);
return result;
}
@@ -47,7 +48,7 @@ int dtb_set_initrd(char **dtb, off_t *dtb_size,
off_t start, off_t end)
int dtb_set_bootargs(char **dtb, off_t *dtb_size, const char *command_line)
{
-return dtb_set_property(dtb, dtb_size, n_chosen, p_bootargs,
+return dtb_set_property(dtb, dtb_size, chosen, p_bootargs,
command_line, strlen(command_line) + 1);
}
@@ -79,16 +80,17 @@ int dtb_set_property(char **dtb, off_t *dtb_size,
const char *node,
goto on_error;
}
-nodeoffset = fdt_path_offset(new_dtb, node);
-
+nodeoffset = fdt_path_offset(new_dtb, n_chosen);
+
if (nodeoffset == -FDT_ERR_NOTFOUND) {
-result = fdt_add_subnode(new_dtb, nodeoffset, node);
+result = fdt_add_subnode(new_dtb, 0, node);
-if (result) {
+if (result < 0) {
dbgprintf("%s: fdt_add_subnode failed: %s\n", __func__,
fdt_strerror(result));
goto on_error;
}
+nodeoffset = result;
} else if (nodeoffset < 0) {
dbgprintf("%s: fdt_path_offset failed: %s\n", __func__,
fdt_strerror(nodeoffset));
@@ -127,7 +129,7 @@ on_error:
int dtb_delete_property(char *dtb, const char *node, const char *prop)
{
int result;
-int nodeoffset = fdt_path_offset(dtb, node);
+int nodeoffset = fdt_path_offset(dtb, n_chosen);
if (nodeoffset < 0) {
dbgprintf("%s: fdt_path_offset failed: %s\n", __func__,
--
2.7.4
On Tue, Dec 4, 2018 at 8:39 AM AKASHI Takahiro
wrote:
>
> Bhupesh,
>
> Thank you for submitting a patch. One comment:
>
> On Fri, Nov 30, 2018 at 11:02:45AM +0530, Bhupesh Sharma wrote:
> > While creating the 2nd dtb to be passed to the secondary kernel
> > for arm64, we need to handle the return values from helper fdt
> > functions properly, to make sure that we can handle various command-line
> > options being passed to 'kexec' both for kexec load and kdump
> > purposes.
> >
> > This will provide proper error reporting to the calling
> > function in case something goes wrong.
> >
> > Without this patch, we get misleading error FDT_ERR_BADOFFSET reported
> > when we pass a .dtb to 'kexec -p' using '--dtb' option, which doesn't
> > contain the '/chosen' node (for e.g. the rockchip sapphire board
> > dtb -> rk3399-sapphire.dtb).
> >
> ># kexec -d -p Image --reuse-cmdline --dtb rk3399-sapphire.dtb
> ><..snip..>
> >load_crashdump_segments: elfcorehdr 0xbfff-0xbfff33ff
> >get_cells_size: #address-cells:2 #size-cells:2
> >
Re: [PATCH v2 0/7] add platform/firmware keys support for kernel verification by IMA
Hi Nayna, On Sun, 2018-12-09 at 01:56 +0530, Nayna Jain wrote: > On secure boot enabled systems, a verified kernel may need to kexec > additional kernels. For example, it may be used as a bootloader needing > to kexec a target kernel or it may need to kexec a crashdump kernel. > In such cases, it may want to verify the signature of the next kernel > image. > > It is possible that the new kernel image is signed with third party keys > which are stored as platform or firmware keys in the 'db' variable. The > kernel, however, can not directly verify these platform keys, and an > administrator may therefore not want to trust them for arbitrary usage. > In order to differentiate platform keys from other keys and provide the > necessary separation of trust the kernel needs an additional keyring to > store platform/firmware keys. > > The secure boot key database is expected to store the keys as EFI > Signature List(ESL). The patch set uses David Howells and Josh Boyer's > patch to access and parse the ESL to extract the certificates and load > them onto the platform keyring. > > The last patch in this patch set adds support for IMA-appraisal to > verify the kexec'ed kernel image based on keys stored in the platform > keyring. Thanks! This patch set is now in the #next-integrity branch. https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/ Mimi ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
