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:
>
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
is 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
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
kernel_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
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
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
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: afc18069a2cb7ead5f86623a5f3d4ad6e21f940d
Gitweb:
https://git.kernel.org/tip/afc18069a2cb7ead5f86623a5f3d4ad6e21f940d
Author:Kairui Song
AuthorDate:Wed, 14 Oct 2020 17:24:28 +08:00
Committer
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 3cb73bc3fa2a3cb80b88aa63b48409939e0d996b
Gitweb:
https://git.kernel.org/tip/3cb73bc3fa2a3cb80b88aa63b48409939e0d996b
Author:Kairui Song
AuthorDate:Wed, 14 Oct 2020 17:24:29 +08:00
Committer
,
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
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
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
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
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
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
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 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
Commit-ID: 5a949b38839e284b1307540c56b03caf57da9736
Gitweb: https://git.kernel.org/tip/5a949b38839e284b1307540c56b03caf57da9736
Author: Kairui Song
AuthorDate: Mon, 10 Jun 2019 15:36:17 +0800
Committer: Borislav Petkov
CommitDate: Mon, 10 Jun 2019 22:00:26 +0200
x86/kexec: Add
Commit-ID: 6bbeb276b71f06c5267bfd154629b1bec82e7136
Gitweb: https://git.kernel.org/tip/6bbeb276b71f06c5267bfd154629b1bec82e7136
Author: Kairui Song
AuthorDate: Mon, 29 Apr 2019 08:23:18 +0800
Committer: Borislav Petkov
CommitDate: Thu, 6 Jun 2019 20:13:48 +0200
x86/kexec: Add the EFI
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 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:
> > > &
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 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 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 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
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 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
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 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
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:
> > > >
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
Commit-ID: d15d356887e770c5f2dcf963b52c7cb510c9e42d
Gitweb: https://git.kernel.org/tip/d15d356887e770c5f2dcf963b52c7cb510c9e42d
Author: Kairui Song
AuthorDate: Tue, 23 Apr 2019 00:26:52 +0800
Committer: Ingo Molnar
CommitDate: Mon, 29 Apr 2019 08:25:05 +0200
perf/x86: Make perf
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:
/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
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
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
-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 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:
> &
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 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 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
(/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
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 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:
> &
ve any suggestion about how should I improve it?
--
Best Regards,
Kairui Song
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:
> >
> >
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
Commit-ID: ffc8599aa9763f39f6736a79da4d1575e7006f9a
Gitweb: https://git.kernel.org/tip/ffc8599aa9763f39f6736a79da4d1575e7006f9a
Author: Kairui Song
AuthorDate: Fri, 8 Mar 2019 11:05:08 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 23 Mar 2019 12:11:49 +0100
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
>
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 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 -
Commit-ID: 179fb36abb097976997f50733d5b122a29158cba
Gitweb: https://git.kernel.org/tip/179fb36abb097976997f50733d5b122a29158cba
Author: Kairui Song
AuthorDate: Wed, 6 Mar 2019 19:18:27 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 6 Mar 2019 23:27:44 +0100
x86/hyperv: Fix kernel
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
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
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
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, 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 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:
> >
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 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
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, 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
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
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
Commit-ID: ccec81e4251f5a5421e02874e394338a897056ca
Gitweb: https://git.kernel.org/tip/ccec81e4251f5a5421e02874e394338a897056ca
Author: Kairui Song
AuthorDate: Tue, 5 Feb 2019 01:38:52 +0800
Committer: Borislav Petkov
CommitDate: Wed, 6 Feb 2019 15:29:03 +0100
x86/kexec: Fill
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_
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/
Commit-ID: 2aa958c99c7fd3162b089a1a56a34a0cdb778de1
Gitweb: https://git.kernel.org/tip/2aa958c99c7fd3162b089a1a56a34a0cdb778de1
Author: Kairui Song
AuthorDate: Fri, 18 Jan 2019 19:13:08 +0800
Committer: Borislav Petkov
CommitDate: Fri, 1 Feb 2019 18:18:54 +0100
x86/kexec: Don't setup
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 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
- 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
.
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
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
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 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 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, 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
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
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
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
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
-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
.
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
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
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
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 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 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 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
> &
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
.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
1 - 100 of 128 matches
Mail list logo
