support when running with SEV
active")
Suggested-by: Borislav Petkov
Signed-off-by: Kairui Song
---
arch/x86/boot/compressed/mem_encrypt.S | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/x86/boot/compressed/mem_encrypt.S
b/arch/x86/boot/compressed/mem_encrypt
;, and reuses the
checking function gart_oldmem_pfn_is_ram introduced in
'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore"),'
as the hook function, but rename to gart_mem_pfn_is_ram as now it's
for a more generic use.
Suggested-by: Baoquan He
Signe
e the
INTEGRITY_PLATFORM_KEYRING to certs/ and let integrity subsystem use
the keyring there, so just linked the .platform keyring into kernel's
.secondary_trusted_keys keyring.
It workd for my case, tested in a VM, I signed the kernel image locally
with pesign and imported the cert to EFI's MokList va
.platform keyring to .secondary_trusted_keys so
kexec_file_load could also leverage the .platform keyring to verify the
kernel image.
Signed-off-by: Kairui Song
---
certs/system_keyring.c | 30 ++
include/keys/platform_keyring.h | 12
securit
;, and reuses the
checking function gart_oldmem_pfn_is_ram introduced in
'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore"),'
as the hook function, but rename to gart_mem_pfn_is_ram as now it's
for a more generic use.
Suggested-by: Baoquan He
Signed-off-by: K
From: Kairui Song
Following kernel panic was observed when doing ftrace stress test:
Unable to handle kernel paging request at virtual address 9699b0f8ece28240
Mem abort info:
ESR = 0x9604
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC
Mark Rutland 于2023年11月14日周二 06:17写道：
>
Hi, Mark and Steven
Thank you so much for the detailed comments.
> On Sun, Nov 12, 2023 at 11:00:30PM +0800, Kairui Song wrote:
> > From: Kairui Song
> >
> > Following kernel panic was observed when doing ftrace stress test:
>
On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
>
> On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> >
> > I'll mostly defer to Josh on unwinding, but a few comments below.
> >
> > On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song
On Tue, Apr 16, 2019 at 7:30 PM Kairui Song wrote:
>
> On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
> >
> > On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> > >
> > > I'll mostly defer to Josh on unwinding, but a few comments b
On Wed, Apr 17, 2019 at 1:45 AM Peter Zijlstra wrote:
>
> On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> > And I also think the "fake"/"real" reg is fragile, could we abuse
> > another eflag (just like PERF_EFLAGS_EXACT) to indicate the regs a
On Wed, Apr 17, 2019 at 4:16 AM Josh Poimboeuf wrote:
>
> On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> > On Tue, Apr 16, 2019 at 7:30 PM Kairui Song wrote:
> > >
> > > On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf
> > > wrote:
> &
[unknown] ([unknown])
Signed-off-by: Kairui Song
---
Update from V2:
- Instead of looking at if BP is 0, use X86_EFLAGS_FIXED flag bit as
the indicator of where the pt_regs is valid for unwinding. As
suggested by Peter Zijlstra
- Update some comments accordingly.
Update
On Tue, Apr 23, 2019 at 7:35 AM Peter Zijlstra wrote:
>
> On Tue, Apr 23, 2019 at 12:26:52AM +0800, Kairui Song wrote:
> > Currently perf callchain doesn't work well with ORC unwinder
> > when sampling from trace point. We'll get useless in kernel callchain
> >
55a22958982a main+0x69a (/usr/bin/perf)
7f71e9202413 __libc_start_main+0xf3 (/usr/lib64/libc-2.28.so)
5541f689495641d7 [unknown] ([unknown])
Signed-off-by: Kairui Song
---
Update from V1:
Get rid of a lot of unneccessary code and just don't dump a inaccurate
BP, and use SP
pg to NULL when the page is
revoked to avoid any misuse. IPI sending will fallback to use non
hypercall based method. This only happens on kexec / kdump so setting to
NULL should be good enough.
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song
---
On Wed, Feb 27, 2019 at 8:02 PM Peter Zijlstra wrote:
>
> On Tue, Feb 26, 2019 at 11:56:15PM +0800, Kairui Song wrote:
> > arch/x86/hyperv/hv_init.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv
urn parse_crashkernel_suffix(ck_cmdline, crash_size,
> > suffix);
> > +#ifdef CONFIG_CRASH_AUTO_STR
> > + if (strncmp(ck_cmdline, "auto", 4) == 0) {
> > + ck_cmdline = CONFIG_CRASH_AUTO_STR;
> > + pr_info("Using crashkernel=auto, the size chosen is a best
> > effort estimation.\n");
> > + }
> > +#endif
> > /*
> >* if the commandline contains a ':', then that's the extended
> >* syntax -- if not, it must be the classic syntax
> > --
> > 2.27.0
> >
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
--
Best Regards,
Kairui Song
endif
> /*
> * if the commandline contains a ':', then that's the extended
> * syntax -- if not, it must be the classic syntax
> --
> 2.27.0
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
Thanks for help pushing the crashkernel=auto to upstream
This patch works well.
Tested-by: Kairui Song
--
Best Regards,
Kairui Song
already in virtual mode, kernel simply do fixed mapping
reuse the recorded virt address. If the virt address is incorrect,
the mapping will be invalid.
Update the virt_addaress as well when inserting a memmap entry to
fix this potential issue.
Signed-off-by: Kairui Song
---
drivers/firmware/efi
id size\n");
> return -EINVAL;
> }
>
> /* match ? */
> - if (system_ram >= start && system_ram < end) {
> + if (total_mem >= start && total_mem < end) {
> *crash_size = size;
> break;
> }
> @@ -250,6 +260,12 @@ static int __init __parse_crashkernel(char *cmdline,
> if (suffix)
> return parse_crashkernel_suffix(ck_cmdline, crash_size,
> suffix);
> +#ifdef CONFIG_CRASH_AUTO_STR
> + if (strncmp(ck_cmdline, "auto", 4) == 0) {
> + ck_cmdline = CONFIG_CRASH_AUTO_STR;
> + pr_info("Using crashkernel=auto, the size chosen is a best
> effort estimation.\n");
> + }
> +#endif
> /*
> * if the commandline contains a ':', then that's the extended
> * syntax -- if not, it must be the classic syntax
> --
> 2.18.4
>
--
Best Regards,
Kairui Song
s their total memory value using different methods,
(just check every parse_crashkernel call, and the system_ram param is
filled in many different ways), so I'm really not sure if this
rounding is always suitable.
>
> Thanks,
> Saeed
>
>
--
Best Regards,
Kairui Song
On Wed, Sep 25, 2019 at 5:55 PM Baoquan He wrote:
>
> On 09/20/19 at 12:05am, Kairui Song wrote:
> > Currently, kernel fails to boot on some HyperV VMs when using EFI.
> > And it's a potential issue on all platforms.
> >
> > It's caused a broken kernel rel
On Wed, Jan 16, 2019 at 11:32 AM Dave Young wrote:
>
> On 01/16/19 at 12:10am, Borislav Petkov wrote:
> > On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> > > When efi=noruntime or efi=oldmap is used, EFI services won't be available
> > > in the
ts also
need to get acpi_rsdp from boot_params according to commit message of
ae7e1238e68f2a472a125673ab506d49158c1889). Will add some comment and
discuss.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Best Regards,
Kairui Song
/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -77,6 +77,11 @@ void choose_random_location(unsigned long input,
> unsigned long *output,
> unsigned long output_size,
> unsigned long *virt_addr);
> +struct mem_vector {
> + unsigned long long start;
> + unsigned long long size;
> +};
> +
> /* cpuflags.c */
> bool has_cpuflag(int flag);
> #else
> @@ -116,3 +121,17 @@ static inline void console_init(void)
> void set_sev_encryption_mask(void);
>
> #endif
> +
> +/* acpi.c */
> +#ifdef CONFIG_RANDOMIZE_BASE
> +/* Amount of immovable memory regions */
> +int num_immovable_mem;
> +#endif
> +
> +#ifdef CONFIG_EARLY_SRAT_PARSE
> +void get_immovable_mem(void);
> +#else
> +static void get_immovable_mem(void)
> +{
> +}
> +#endif
> --
> 2.20.1
>
>
>
--
Best Regards,
Kairui Song
tch exposes the .platform, and makes it useable for other
components. For example, kexec_file_load could use this .platform
keyring to verify the kernel image's image.
Suggested-by: Mimi Zohar
Signed-off-by: Kairui Song
---
certs/system_keyring.c| 9 +
include/keys/system_keyring.h
.
Tested in a VM with locally signed kernel with pesign and imported the
cert to EFI's MokList variable.
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
Update from V2:
- Use IS_ENABLED in kexec_file_lo
platform keyring. Also, decrease
the error message log level when verification failed with -ENOKEY,
so that if called tried multiple time with different keyring it
won't generate extra noises.
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyr
On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
>
> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> > I didn't see a way to reuse things in that patch series, situation is
> > different, in that patch it needs to get RSDP in very early boot stage
&
On Thu, Jan 17, 2019 at 3:51 PM Chao Fan wrote:
>
> On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> >On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
> >>
> >> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> >> >
On Thu, Jan 17, 2019 at 3:58 PM Chao Fan wrote:
>
> On Wed, Jan 16, 2019 at 03:28:52PM +0800, Kairui Song wrote:
> >On Mon, Jan 7, 2019 at 11:24 AM Chao Fan wrote:
> >>
> >> +
> >> +/* Determine RSDP, based on acpi_os_get_root_pointer(). */
> >>
On Thu, Jan 17, 2019 at 11:04 PM David Howells wrote:
>
> Kairui Song wrote:
>
> > +extern const struct key* __init integrity_get_platform_keyring(void);
>
> This should really be in keys/system_keyring.h and probably shouldn't be
> exposed directly if it can be a
On Fri, Jan 18, 2019 at 10:00 AM Dave Young wrote:
>
> On 01/18/19 at 09:35am, Dave Young wrote:
> > On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> > > On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > > > This patch series adds a .platform_trus
s_get_root_pointer_late and store rsdp
pointer as mentioned? Will updat the patch and post V2, and cc
linux-acpi as well later.
> > On 01/17/19 at 03:41pm, Kairui Song wrote:
> > > On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
> > > >
> > > > On Wed
the kexec mailing list). It's a bit late to be
> > asking to move it, isn't it?
>
> Hmm, apologize for being late, I did not get chance to have a look the
> old series. Since we have the needs now, it should be still fine
>
> Maybe Kairui can check Nayna's old series, see if he can do something
> again?
>
> >
> > Mimi
> >
>
> Thanks
> Dave
--
Best Regards,
Kairui Song
t and fix like this series do.
>
> >
> > Mimi
> >
>
> Thanks
> Dave
Yes, for now, I think it's good to fix the problem by following this
patch series and get kexec_file_load work with platform keyring first.
Will adopt suggestion from Mimi in the previous reply and update the
patch series.
For other remaining potential issues, kexec_load not being protected,
it could be disabled by config, and the improvement may require more
discussion. And issues like where the keyring is located, dependency
to making the keyring available for more general use could be
discussed later.
--
Best Regards,
Kairui Song
.
Tested in a VM with locally signed kernel with pesign and imported the
cert to EFI's MokList variable.
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
Update from V1:
- Make platform_trusted_keys s
tch exposes the .platform, and makes it useable for other
components. For example, kexec_file_load could use this .platform
keyring to verify the kernel image's image.
Suggested-by: Mimi Zohar
Signed-off-by: Kairui Song
---
certs/system_keyring.c| 9 +
include/keys/system_keyring.h
platform keyring. Also, decrease
the error message log level when verification failed with -ENOKEY,
so that if called tried multiple time with different keyring it
won't generate extra noises.
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 15 ---
certs/system_keyr
This patch series fix the kexec panic on efi=noruntime or efi=old_map
and leverage acpi_rsdp_addr to make the second kernel boot up properly.
Kairui Song (2):
x86, kexec_file_load: Don't setup EFI info if EFI runtime is not
enabled
x86, kexec_file_load: make it work with efi=norunti
97.983962] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When efi runtime is not enabled, efi memmap is not mapped, so just skip
EFI info setup.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/kexec
kernel, this commit make
use of it, detect and set the RSDP address when it's required for second
kernel to boot.
Tested with an EFI enabled KVM VM with efi=noruntime.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 21 +
On Tue, Jan 15, 2019 at 11:34 PM Mimi Zohar wrote:
>
> On Tue, 2019-01-15 at 17:45 +0800, Kairui Song wrote:
> [snip]
>
> > diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> > index f45d6edecf99..bfabc2a8111d 100644
> > --- a/security/integri
On Tue, Jan 15, 2019 at 11:47 PM Mimi Zohar wrote:
>
> On Tue, 2019-01-15 at 17:45 +0800, Kairui Song wrote:
>
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c
> > index 7d97e432cbbc..a06b04065bb1 100644
> > --- a/
stored in xattr.
This patch exposes the .platform keyring, making it accessible for
verifying PE signed kernel images as well.
Suggested-by: Mimi Zohar
Signed-off-by: Kairui Song
Reviewed-by: Mimi Zohar
Tested-by: Mimi Zohar
---
certs/system_keyring.c| 9 +
include/keys/syste
igned-off-by: Kairui Song
Reviewed-by: Mimi Zohar
Tested-by: Mimi Zohar
---
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyring.c| 13 -
include/linux/verification.h | 1 +
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arc
Make platform_trusted_keys static, and update commit message as suggested
by Mimi Zohar
- Always check if platform keyring is initialized before use it
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
arch/x86/k
parse RSDP.
Update from V1:
- Add a cover letter and fix some type in commit message
- Previous patches are not sent in a single thread
Kairui Song (3):
x86, kexec_file_load: Don't setup EFI info if EFI runtime is not
enabled
acpi: store acpi_rsdp address for later kexec u
97.983962] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When efi runtime is not enabled, efi memmap is not mapped, so just skip
EFI info setup.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/kexec
kernel, this commit makes
use of it, detect and set the RSDP address when it's required for second
kernel to boot.
Tested with an EFI enabled KVM VM with efi=noruntime.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 10 ++
1 file changed
introduce an acpi_os_get_root_pointer_late for later kexec usage.
Signed-off-by: Kairui Song
---
drivers/acpi/osl.c | 10 ++
include/linux/acpi.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..6340d34d0df1 100644
--- a
s.
>
> Also, after Chao's stuff, you won't need to call
> acpi_os_get_root_pointer() because the early code would've done that.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Good suggestion, will wait for Chao's update then.
--
Best Regards,
Kairui Song
On Fri, Jan 18, 2019, 19:54 Mimi Zohar
> On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initializ
On Fri, Jan 18, 2019 at 8:37 PM Dave Young wrote:
>
> On 01/18/19 at 08:34pm, Dave Young wrote:
> > On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > > This patch series adds a .platform_trus
On Fri, Jan 18, 2019 at 9:42 PM Kairui Song wrote:
>
> On Fri, Jan 18, 2019 at 8:37 PM Dave Young wrote:
> >
> > On 01/18/19 at 08:34pm, Dave Young wrote:
> > > On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > > > On Fri, 2019-01-18 at 17:17 +0800, Kairui
On Fri, Jan 18, 2019 at 10:36 PM Nayna wrote:
> On 01/18/2019 04:17 AM, Kairui Song wrote:
> > commit 9dc92c45177a ('integrity: Define a trusted platform keyring')
> > introduced a .platform keyring for storing preboot keys, used for
> > verifying kernel images
On Fri, Jan 18, 2019 at 10:28 PM Kairui Song wrote:
>
> On Fri, Jan 18, 2019 at 9:42 PM Kairui Song wrote:
> >
> > On Fri, Jan 18, 2019 at 8:37 PM Dave Young wrote:
> > >
> > > On 01/18/19 at 08:34pm, Dave Young wrote:
> > > > On 01/18/19 at 06:5
stored in xattr.
This patch exposes the .platform keyring, making it
accessible for verifying PE signed kernel images as well.
Suggested-by: Mimi Zohar
Signed-off-by: Kairui Song
---
certs/system_keyring.c| 9 +
include/keys/system_keyring.h | 9 +
security/integrity/digsig
oises.
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyring.c| 13 -
include/linux/verification.h | 1 +
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/
Zohar
- Always check if platform keyring is initialized before use it
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyring.c
On Mon, Jan 21, 2019 at 6:00 PM Kairui Song wrote:
>
> This patch series adds a .platform_trusted_keys in system_keyring as the
> reference to .platform keyring in integrity subsystem, when platform
> keyring is being initialized it will be updated, so it will be
> accessable f
platform keyring")
Signed-off-by: Kairui Song
---
certs/system_keyring.c| 4 ++--
include/keys/system_keyring.h | 9 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 19bd0504bbcb..c05c29ae4d5d 100644
--
at value for second kernel's
boot_params unconditionally, this ensure second kernel always use the
same RSDP value as the first kernel.
Tested with an EFI enabled KVM VM with efi=noruntime.
Signed-off-by: Kairui Song
---
This is update of part of patch series: "[PATCH v3 0/3] make kexec work
with
On Wed, Jan 23, 2019 at 10:14 PM Baoquan He wrote:
>
> On 01/02/19 at 06:54pm, Kairui Song wrote:
> > diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> > index 58176b56354e..c8a56f083419 100644
> > --- a/arch/x86/kernel/aperture_64.c
&
On Thu, May 23, 2019 at 1:34 PM Song Liu wrote:
>
> Commit d15d356887e7 removes regs->ip for !perf_hw_regs(regs) case. This
> patch adds regs->ip back.
>
> Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without
> CONFIG_FRAME_POINTER")
> Cc: Kai
if (!update_stack_state(state, next_bp)) {
+ goto bad_address;
+ }
+ }
return true;
For ORC unwinder, I think the unwinder can't find any info about the
JITed part. Maybe if can let it just skip the JITed part and go to
kernel context, then should be good enough.
--
Best Regards,
Kairui Song
On Thu, May 23, 2019 at 4:28 PM Song Liu wrote:
>
> > On May 22, 2019, at 11:48 PM, Kairui Song wrote:
> >
> > On Thu, May 23, 2019 at 7:46 AM Josh Poimboeuf wrote:
> >>
> >> On Wed, May 22, 2019 at 12:45:17PM -0500, Josh Poimboeuf wrote:
> >>&g
On Thu, May 23, 2019 at 9:32 PM Josh Poimboeuf wrote:
>
> On Thu, May 23, 2019 at 02:48:11PM +0800, Kairui Song wrote:
> > On Thu, May 23, 2019 at 7:46 AM Josh Poimboeuf wrote:
> > >
> > > On Wed, May 22, 2019 at 12:45:17PM -0500, Josh Poimboeuf wrote:
> > &g
On Thu, May 23, 2019 at 11:24 PM Josh Poimboeuf wrote:
>
> On Thu, May 23, 2019 at 10:50:24PM +0800, Kairui Song wrote:
> > > > Hi Josh, this still won't fix the problem.
> > > >
> > > > Problem is not (or not only) with ___bpf_prog_run, what ac
On Fri, May 17, 2019 at 5:10 PM Peter Zijlstra wrote:
>
> On Fri, May 17, 2019 at 04:15:39PM +0800, Kairui Song wrote:
> > Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
> > some other bfp functions) is now broken, or, strating an unwind
> > direc
ijlstra wrote:
> >>>
> >>> On Fri, May 17, 2019 at 04:15:39PM +0800, Kairui Song wrote:
> >>>> Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
> >>>> some other bfp functions) is now broken, or, strating an unwind
> >>
On Fri, May 24, 2019 at 1:27 AM Josh Poimboeuf wrote:
>
> On Fri, May 24, 2019 at 12:41:59AM +0800, Kairui Song wrote:
> > On Thu, May 23, 2019 at 11:24 PM Josh Poimboeuf
> > wrote:
> > >
> > > On Thu, May 23, 2019 at 10:50:24PM +0800, Kairui Song wrote:
&
On Sat, May 25, 2019 at 7:23 AM Josh Poimboeuf wrote:
>
> On Fri, May 24, 2019 at 10:20:52AM +0800, Kairui Song wrote:
> > On Fri, May 24, 2019 at 1:27 AM Josh Poimboeuf wrote:
> > >
> > > On Fri, May 24, 2019 at 12:41:59AM +0800, Kairui Song wrote:
> > > &
Currently perf callchain is not working properly with ORC unwinder,
we'll get useless in kernel callchain like this:
perf 6429 [000]22.498450: kmem:mm_page_alloc: page=0x176a17
pfn=1534487 order=0 migratetype=0 gfp_flags=GFP_KERNEL
be23e32e __alloc_pages_nodemask+
On Fri, Apr 5, 2019 at 10:09 PM Josh Poimboeuf wrote:
>
> On Fri, Apr 05, 2019 at 01:25:45AM +0800, Kairui Song wrote:
> > Currently perf callchain is not working properly with ORC unwinder,
> > we'll get useless in kernel callchain like this:
> >
>
ong, or give any suggestion about how should I improve it?
--
Best Regards,
Kairui Song
On Sat, Apr 6, 2019 at 12:57 AM Josh Poimboeuf wrote:
>
> On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> > Hi Josh, thanks for the review, I tried again, using latest upstream
> > kernel commit ea2cec24c8d429ee6f99040e4eb6c7ad627fe777:
> &
On Sat, Apr 6, 2019 at 1:27 AM Josh Poimboeuf wrote:
>
> On Sat, Apr 06, 2019 at 01:05:55AM +0800, Kairui Song wrote:
> > On Sat, Apr 6, 2019 at 12:57 AM Josh Poimboeuf wrote:
> > >
> > > On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> > > &g
b/include/linux/perf_event.h
> index f3864e1c5569..0f560069aeec 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1062,7 +1062,7 @@ static inline void perf_arch_fetch_caller_regs(struct
> pt_regs *regs, unsigned lo
> * the nth caller. We only need a few of the regs:
> * - ip for PERF_SAMPLE_IP
> * - cs for user_mode() tests
> - * - bp for callchains
> + * - sp for callchains
> * - eflags, for future purposes, just in case
> */
> static inline void perf_fetch_caller_regs(struct pt_regs *regs)
--
Best Regards,
Kairui Song
On Fri, Apr 19, 2019 at 5:43 PM Peter Zijlstra wrote:
>
> On Fri, Apr 19, 2019 at 10:17:49AM +0800, Kairui Song wrote:
> > On Fri, Apr 19, 2019 at 8:58 AM Josh Poimboeuf wrote:
> > >
> > > I still don't like using regs->bp because it results in different co
a22960d9c1 [unknown] (/usr/bin/perf)
55a22958982a main+0x69a (/usr/bin/perf)
7f71e9202413 __libc_start_main+0xf3 (/usr/lib64/libc-2.28.so)
5541f689495641d7 [unknown] ([unknown])
Co-developed-by: Josh Poimboeuf
Signed-off-by: Kairui Song
---
Update from V3:
- Alway start
and import the key
> then to reuse kexec_file_load.
>
> I think we do not care if platform key can be added to secondary or not,
> any suggestions how can kexec_file to use the platform key?
>
> >
> > Mimi
> >
> >
> > On Tue, 2019-01-08 at 16:12 +0
97.983962] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When efi runtime is not enabled, efi memmap is not mapped, so just skip
EFI info setup.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/kexec-b
kernel, this commit make
use of it, detect and set the RSDP address when it's required for second
kernel to boot.
Tested with an EFI enabled KVM VM with efi=noruntime.
Suggested-by: Dave Young
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 21 +
CCing more people
On Wed, Jan 9, 2019 at 2:47 PM Kairui Song wrote:
>
> When efi=noruntime or efi=oldmap is used, EFI services won't be available
> in the second kernel, therefore the second kernel will not be able to get
> the ACPI RSDP address from firmware by calling EFI s
CCing more people
On Wed, Jan 9, 2019 at 2:45 PM Kairui Song wrote:
>
> Currenly with "efi=noruntime" in kernel command line, calling
> kexec_file_load will raise below problem:
>
> [ 97.967067] BUG: unable to handle kernel NULL pointer dereference at
> 0
failed with -ENOKEY,
so that if called tried multiple time with different keyring it
won't generate extra noises.
Signed-off-by: Kairui Song
---
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyring.c| 7 ++-
include/linux/verification.h | 1 +
3
t to EFI's MokList variable.
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
arch/x86/kernel/kexec-bzimage64.c | 13 ++---
certs/system_keyring.c| 10 +-
include/keys/system_key
appraisal could use the keyring and verify the image.
This patch exposes the .platform and makes other components, like
kexec_file_load, could use this .platform keyring to verify the
kernel image.
Suggested-by: Mimi Zohar
Signed-off-by: Kairui Song
---
certs/system_keyring.c| 3 ++
On machines where the GART aperture is mapped over physical RAM,
/proc/kcore contains the GART aperture range and reading it may lead
to kernel panic.
In 'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")',
a workaround is applied for vmcore to let /proc/vmcore return zeroes
when
On Wed, Feb 13, 2019 at 4:28 PM Kairui Song wrote:
>
> On machines where the GART aperture is mapped over physical RAM,
> /proc/kcore contains the GART aperture range and reading it may lead
> to kernel panic.
>
> In 'commit 2a3e83c6f96c ("x86/gart: Exclude GART
On Fri, Mar 8, 2019 at 11:06 AM Kairui Song wrote:
>
> On machines where the GART aperture is mapped over physical RAM,
> /proc/kcore contains the GART aperture range and reading it may lead
> to kernel panic.
>
> Vmcore used to have the same issue, until we fixed it in
>
On Thu, Jan 24, 2019 at 10:17 AM Baoquan He wrote:
>
> On 01/23/19 at 10:50pm, Kairui Song wrote:
> > > > int fix_aperture __initdata = 1;
> > > >
> > > > -#ifdef CONFIG_PROC_VMCORE
> > > > +#if defined(CONFIG_PROC_VMCORE) || defined(CONFIG_P
PI sending will fallback to use non
hypercall based method. This only happens on kexec / kdump so setting to
NULL should be good enough.
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song
---
Update from V1:
- Add comment for the barrier.
arch
On Tue, Mar 5, 2019 at 8:28 PM Peter Zijlstra wrote:
>
> On Wed, Feb 27, 2019 at 10:55:46PM +0800, Kairui Song wrote:
> > On Wed, Feb 27, 2019 at 8:02 PM Peter Zijlstra wrote:
> > >
> > > On Tue, Feb 26, 2019 at 11:56:15PM +0800, Kairui Song wrote:
> >
On Tue, Mar 5, 2019 at 8:33 PM Peter Zijlstra wrote:
>
> On Tue, Mar 05, 2019 at 08:17:03PM +0800, Kairui Song wrote:
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index 7abb09e2eeb8..34aa1e953dfc 100644
> > --- a/arch/x86/hyperv/hv_init.c
&
On Fri, Mar 1, 2019 at 7:12 AM Jiri Bohac wrote:
>
> On Wed, Feb 13, 2019 at 04:28:00PM +0800, Kairui Song wrote:
> > @@ -465,6 +472,12 @@ read_kcore(struct file *file, char __user *buffer,
> > size_t buflen, loff_t *fpos)
> >
On Tue, Feb 19, 2019 at 4:00 PM Kairui Song wrote:
>
> On Thu, Jan 24, 2019 at 10:17 AM Baoquan He wrote:
> >
> > On 01/23/19 at 10:50pm, Kairui Song wrote:
> > > > > int fix_aperture __initdata = 1;
> > > > >
> > > > > -#ifd
PI sending will fallback to use non
hypercall based method. This only happens on kexec / kdump so setting to
NULL should be good enough.
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song
---
Update from V2:
- The memory barrier is not needed, r
nction introduced in
previous vmcore fix. Just with some minor adjustment, rename some
functions for more general usage, and simplify the hook infrastructure
a bit as there is no module usage yet.
Suggested-by: Baoquan He
Signed-off-by: Kairui Song
---
Update from V3:
- Reuse the approach in V2
1 - 100 of 126 matches
Mail list logo
