unning 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.S
index eaa843
aram. If there is a swap, then userspace
will have less memory pressure. crashkernel=auto can focus on the
kernel usage.
Kairui Song (3):
vmcore: simplify read_from_olemem
vmcore: Add interface to write to old mem
x86_64: implement copy_to_oldmem_page
arch/x86/kernel/crash_dump_64.c | 49 --
fs/
files.
Signed-off-by: Kairui Song
---
fs/proc/vmcore.c | 129 +
include/linux/crash_dump.h | 18 --
2 files changed, 131 insertions(+), 16 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 124c2066f3e5..23acc0f2ecd7 100644
static
Size of vmcore.o:
textdata bss dec hex filename
Before: 7677 109 8878741ec2 fs/proc/vmcore.o
After: 7669 109 8878661eba fs/proc/vmcore.o
Signed-off-by: Kairui Song
---
fs/proc/vmcore.c | 27 ++-
1 file
Previous commit introduced writing support for vmcore, it requires
per-architecture implementation for the writing function.
Signed-off-by: Kairui Song
---
arch/x86/kernel/crash_dump_64.c | 49 +++--
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch
On Wed, Sep 9, 2020 at 10:04 PM Eric W. Biederman wrote:
>
> Kairui Song writes:
>
> > Currently vmcore only supports reading, this patch series is an RFC
> > to add writing support to vmcore. It's x86_64 only yet, I'll add other
> > architecture later if there i
On Thu, Sep 10, 2020 at 12:43 AM Kairui Song wrote:
>
> On Wed, Sep 9, 2020 at 10:04 PM Eric W. Biederman
> wrote:
> >
> > Kairui Song writes:
> >
> > > Currently vmcore only supports reading, this patch series is an RFC
> > > to add writing supp
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
tal 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
he old framebuffer.
After the relocation, the framebuffer is no longer a VGA
framebuffer, so just clean it up should be good.
Kairui Song (2):
x86/kexec: Use up-to-dated screen_info copy to fill boot params
hyperv_fb: Update screen_info after removing old framebuffer
arch/x86/kernel/kexec-bzima
-by: Kairui Song
---
drivers/video/fbdev/hyperv_fb.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 02411d89cb46..e36fb1a0ecdb 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev
,
kexec'ed kernel may attempt to write to an invalid framebuffer
memory region.
There are two screen_info globally available, boot_params.screen_info
and screen_info. Later one is a copy, and could be updated by drivers.
So let kexec_file_load use the updated copy.
Signed-off-by: Kairui Song
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
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 actuall
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:
&
is helpful if device dump is
using too much memory, disabling device dump could make sure a regular
vmcore without device dump data is still available.
Signed-off-by: Kairui Song
Reviewed-by: Bhupesh Sharma
Acked-by: Dave Young
---
Hi Andrew, sorry for the trouble but could you help pick u
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 relocation on
On Thu, Jul 23, 2020 at 8:00 AM Bjorn Helgaas wrote:
>
> On Wed, Jul 22, 2020 at 03:50:48PM -0600, Jerry Hoemann wrote:
> > On Wed, Jul 22, 2020 at 10:21:23AM -0500, Bjorn Helgaas wrote:
> > > On Wed, Jul 22, 2020 at 10:52:26PM +0800, Kairui Song wrote:
>
> > >
response. The test machine was
not available for sometime, and I restarted to work on this problem.
For the workaround mention by Deepa (by remote the is_kdump_kernel()
check), it didn't work, the machine still hangs upon shutdown.
The devices that were left in an unknown state and sending interrupt
could be a problem, but it's irrelevant to this hanging problem.
I think I didn't make one thing clear, The PCI UR error never arrives
in kernel, it's the iLo BMC on that HPE machine caught the error, and
send kernel an NMI. kernel is panicked by NMI, I'm still trying to
figure out why the NMI hanged kernel, even with panic=-1,
panic_on_io_nmi, panic_on_unknown_nmi all set. But if we can avoid the
NMI by shutdown the devices in right order, that's also a solution.
--
Best Regards,
Kairui Song
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:
> > > &
ng 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
>
> >
> > 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 static
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 | 5 +
security
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_keyring.c
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=noruntime
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
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 +
drivers/acpi/acpica/tbxfroot.c
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/
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 secon
ed 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
.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
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 | 5 +
security
.
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_load
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_keyring.c
rm 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
--- a/certs/
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 efi=noruntime or efi=old_
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:
> >&g
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 av
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 .platfo
pi_os_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
.
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/system_keyring.h | 5
-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/arch/x86
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/kernel
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 usage
x86
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
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, 10 insertions(+)
diff --git
, and
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
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 .platfo
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' signatur
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 wrot
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 bel
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:
> &
-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 from V1:
Get rid of a lot
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
> > like this:
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 differen
/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 the unwinding directly on fake
faa22be81
(perf_trace_run_bpf_submit+0x41/0xb0)
Simply store the IP still won't really fix the problem, it just passed
the test. Just had a try to have bpf functions set the
X86_EFLAGS_FIXED for the flags and always dump the bp, it bypassed
this specified problem.
Using frame pointer unwinder for testing this, and seems ORC is fine with this.
--
Best Regards,
Kairui Song
On Fri, May 17, 2019 at 4:15 PM Kairui Song wrote:
>
> On Fri, May 17, 2019 at 4:11 PM Peter Zijlstra wrote:
> >
> > On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
> > > On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
> > > >
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 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
(/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 as the marker for target frame
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
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:
> >
> >
ve 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
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/x86/
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
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 V4:
- Remove the unregistering funtio
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, remove
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, as Jiri
On Thu, Mar 7, 2019 at 1:03 AM Jiri Bohac wrote:
>
> Hi,
>
> On Wed, Mar 06, 2019 at 07:38:59PM +0800, Kairui Song wrote:
> > +int register_mem_pfn_is_ram(int (*fn)(unsigned long pfn))
> > +{
> > + if (mem_pfn_is_ram)
> > + return -
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 GA
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
---
I'm not
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 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
.
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.c | 3 +++
3
.
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/kexec
- 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| 22
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
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 variable.
Kairui
1 - 100 of 128 matches
Mail list logo
