Adding Vivek as he is the one who implemented kexec_file_load.
I was hoping he would respond to this thread, and it looks like he
simply has not ever been Cc'd.
Theodore Ts'o writes:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> The bits that actually read Secure Boot state o
Vivek Goyal writes:
> On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
>>
>> Adding Vivek as he is the one who implemented kexec_file_load.
>> I was hoping he would respond to this thread, and it looks like he
>> simply has not ever been Cc'
Vivek Goyal writes:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
>
> [..]
>> > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
>> > error in kexec_load and print some error message.
>>
>> Just like below, does this work for you, Ted?
>>
>> ---
>> arc
rs" boot parameter so that
> you can't change the value of the parameter.
Nacked-by: "Eric W. Biederman"
You are confusing kexec on panic and CONFIG_CRASH_DUMP
which is about the tools for reading the state of the previous kernel.
Eric
> Signed-off-by: Hidehiro Kawai
&g
dwal...@fifo99.com writes:
> On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
>> Hidehiro Kawai writes:
>>
>> > You can call panic notifiers and kmsg dumpers before kdump by
>> > specifying "crash_kexec_post_notifiers" as a boot par
:08AM -0400, Vivek Goyal wrote:
>> > > > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
>> > > > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
>> > > > > > dwal...@fifo99.com writes:
>
Vivek Goyal writes:
> On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote:
>
> [..]
>> > >> > If a machine is failing, there are high chance it can't deliver you
>> > >> > the
>> > >> > notification. Detecting that failure suing some kind of polling
>> > >> > mechanism
>> > >> >
Hidehiro Kawai writes:
> Hello Eric and Vivek,
>
> Do you have any comments?
crash_kexec_post_notifiers is a debugging hack to allow people to test
if the kmsg_dump works better than kexec. crash_kexec_post_notifiers is
not, nor has it ever been a solution for general operation (which is
what I
"河合英宏 / KAWAI，HIDEHIRO" writes:
> Hello,
>
> Thanks for the reply.
>
>> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> [...]
>> A specific hook for a very specific purpose when there is no other way
>> we can consider.
>
> So, is kms
Minfei Huang writes:
> kexec output message misses the prefix "kexec", when Dave Young split
> the kexec code. To keep the same format, add the prefix "kexec" to
> output message.
What of kexec_core? What of the messages that already have a prefix?
Eric
> Following is the format of output mess
Geoff Levand writes:
>> > It was reported that on some systems where purgatory is running
>> > without caches enabled the sha256 calculations would take several
>> > minutes. For bootloaders that just load a new image and
>> > immediately jump into it the loss of the integrity check is worth
>>
Wei Jiangang writes:
> If we specify the 'notsc' boot parameter for the dump-capture kernel,
> and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c >
> /proc/sysrq-trigger",
> the dump-capture kernel will hang in calibrate_delay_converge():
>
> /* wait for "start of" clock tick *
code execution) that can be used to
defeat the signature scheme I am going to nack this.
Nacked-by: "Eric W. Biederman"
I am happy to see support for other architectures, but for the sake of
not moving some code in the kernel let's not build an attackable
infrastructure.
ily receive a
page from the buddy allocator that can exceed 4GiB. This doesn't show
up on 64bit systems as typically the memory limits are less than the
address space. But this code is very necessary on some systems and
removing it is not ok.
Nacked-by: "Eric W. Biederman"
zhongjiang writes:
> From: zhong jiang
>
> when image is loaded into kernel, we need set up page table for it. and
> all valid pfn also set up new mapping. it will tend to establish a pmd
> page table in the form of a large page if pud_present is true.
> relocate_kernel
> points to code segm
Petr Tesarik writes:
> On Tue, 12 Jul 2016 13:25:11 -0300
> Thiago Jung Bauermann wrote:
>
>> Hi Eric,
>>
>> I'm trying to understand your concerns leading to your nack. I hope you
>> don't mind expanding your thoughts on them a bit.
>>
>
ebied...@xmission.com (Eric W. Biederman) writes:
> Petr Tesarik writes:
>
>> On Tue, 12 Jul 2016 13:25:11 -0300
>> Thiago Jung Bauermann wrote:
>>
>>> Hi Eric,
>>>
>>> I'm trying to understand your concerns leading to your nack. I hope y
zhong jiang writes:
> On 2016/7/12 23:19, Eric W. Biederman wrote:
>> zhongjiang writes:
>>
>>> From: zhong jiang
>>>
>>> In general, kexec alloc pages from buddy system, it cannot exceed
>>> the physical address in the system.
>>>
&g
zhong jiang writes:
> On 2016/7/12 23:46, Eric W. Biederman wrote:
>> zhongjiang writes:
>>
>>> From: zhong jiang
>>>
>>> when image is loaded into kernel, we need set up page table for it. and
>>> all valid pfn also set up new mapping. it
zhongjiang writes:
> From: zhong jiang
>
> I hit the following question when run trinity in my system. The
> kernel is 3.4 version. but the mainline have same question to be
> solved. The root cause is the segment size is too large, it can
> expand the most of the area or the whole memory, there
Wei Jiangang writes:
> If we specify the 'notsc' parameter for the dump-capture kernel,
> and then trigger a crash(panic) by using "ALT-SysRq-c" or
> "echo c > /proc/sysrq-trigger", the dump-capture kernel will
> hang in calibrate_delay_converge() and wait for jiffies changes.
> serial log as fol
"Wei, Jiangang" writes:
> Ping ...
> May I ask for some community attention to this series?
> I purpose is fixing the dump-capture kernel hangs in
> calibrate_delay_converge() while specifying notsc.
Did you not see my reply to patch 3/3?
The short version of my feedback is that you seem to be
"Wei, Jiangang" writes:
> Hi Eric,
>
> Thanks for your response.
> But I have some different ideas...
Apologies for not replying to this earlier your reply got lost in my
spam folder and I overlooked it.
> On Mon, 2016-07-25 at 22:53 -0500, Eric W. Biederman wrote
"Wei, Jiangang" writes:
> Hi Eric,
>
> I have several questions about kdump and APIC mode.
> specific issues at the end of the mail.
>
> On Tue, 2016-08-02 at 09:26 -0500, Eric W. Biederman wrote:
[snip]
>> For simplicity when MP support was first added, a few
updates need to be made they should be made before they are part of
the entire image checksum.
No way should this be merged anywhere ever.
Nacked-by: "Eric W. Biederman"
>
> Signed-off-by: Thiago Jung Bauermann
> ---
> include/linux/kexec.h | 23 ++--
; warnings in the last patch.
This is fundamentally broken. You do not increase the integrity of a
system by dropping integrity checks.
No. No. No. No.
Nacked-by: "Eric W. Biederman"
Eric
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
ebied...@xmission.com (Eric W. Biederman) writes:
> Thiago Jung Bauermann writes:
>
>> Hello,
>>
>> The purpose of this new version of the series is to fix a small issue that
>> I found, which is that the kernel doesn't remove the memory reservation
>>
Thiago Jung Bauermann writes:
> Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>> > Thiago Jung Bauermann writes:
>> >> Hello,
>> >>
>> >> The purpose of this new ve
Mimi Zohar writes:
> Hi Andrew,
>
> On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
>> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote:
>> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar
>> > wrote:
>> >
>> > > The TPM PCRs are only reset on a hard reboot. In order to validate a
>
ebied...@xmission.com (Eric W. Biederman) writes:
> Mimi Zohar writes:
>
>> Hi Andrew,
>>
>> On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
>>> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote:
>>> > On Tue, 30 Aug 2016 18:40:02 -0400 Mim
Thiago Jung Bauermann writes:
> Hello Eric,
>
> Am Freitag, 16 September 2016, 14:47:13 schrieb Eric W. Biederman:
>> Mimi Zohar writes:
>> > Hi Andrew,
>> >
>> > On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
>> >> On Wed, 2016-08-
Thiago Jung Bauermann writes:
> Am Samstag, 17 September 2016, 00:17:37 schrieb Eric W. Biederman:
>> Thiago Jung Bauermann writes:
>> > Hello Eric,
>> >
>> > Am Freitag, 16 September 2016, 14:47:13 schrieb Eric W. Biederman:
>> >> I can see
e people who want to receive the
measurment list but don't want to support kexec'ing other kernels or the
other way around. I can very much see bootloaders that expect they will
be the first kernel to not want to compile in the extra code for
receiving the measurment list.
But again that i
Thiago Jung Bauermann writes:
> Hello Eric,
>
> Am Dienstag, 20 September 2016, 11:07:29 schrieb Eric W. Biederman:
>> A semi-generic concept called a hand-over buffer seems to be a
>> construction of infrustructure for no actual reason that will just
>> result in co
Baoquan He writes:
> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> utility, mainly makedumpfile can use them to identify the base of
David Miller writes:
> From: Florian Fainelli
> Date: Thu, 20 Oct 2016 18:15:16 -0700
>
>> The bcm_sf2 driver uses kexec_in_progress to know whether it can power
>> down an integrated PHY during shutdown, and can be built as a module.
>> Other modules may be using this in the future, so export i
David Miller writes:
> From: ebied...@xmission.com (Eric W. Biederman)
> Date: Fri, 21 Oct 2016 00:26:55 -0500
>
>> So as far as I can tell you are advocating for a change to support a
>> driver doing something that is completely pointless. So no let's not
>> exp
Baoquan He writes:
> On 11/02/16 at 04:00am, Thiago Jung Bauermann wrote:
>> Hello,
>>
>> The kexec_file code currently builds the purgatory as a partially linked
>> object
>> (using ld -r). Is there a particular reason to use that instead of a
>> position
>> independent executable (PIE)?
>
ging a __pa to a __pa_symbol it might make things a tad more
reliable depending on the implementation of __pa.
Acked-by: "Eric W. Biederman"
Eric
>> Signed-off-by: Laura Abbott
>> ---
>> Found during review of the kernel. Untested.
>> ---
>> kernel/kexec
Hari Bathini writes:
> Hi Dave,
>
>
> Thanks for the review.
>
>
> On Thursday 01 December 2016 10:26 AM, Dave Young wrote:
>> Hi Hari
>>
>> Personally I like V1 more, but split the patch 2 is easier for ia64
>> people to reivew. I did basic x86 testing, it runs ok.
>>
>> On 11/25/16 at 05:24pm,
zhongjiang writes:
> From: zhong jiang
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
Overall that looks reasonable. Why only every 256 page and not call
cond_resched unconditionally?
The function cond_resched won't
zhongjiang writes:
> From: zhong jiang
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
Acked-by: "Eric W. Biederman"
>
> [ 237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trini
zhong jiang writes:
> On 2016/12/8 17:41, Xunlei Pang wrote:
>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>> From: zhong jiang
>>>
[snip]
>>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>>> index 5616755..bfc9621 100644
>>> --- a/kernel/kexec_core.c
>>> +++ b/kernel/kexec_core.c
>
relying on kernel implementation
details, so if we can do anything else that is more robust it
is much more likely to pass the test of time.
And yes a more robust implementation has been already discussed.
Nacked-by: "Eric W. Biederman"
>
> Signed-off-by: Thomas Garnier
> ---
>
Paweł Lenkow writes:
> Hi!
>
> I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel
> crashes.
Adding the kexec list as there may be someone there who may be more
knowledgeable about our problem.
> First kernel is loaded by UEFI, starts simple init with shell and then
> I
"Dmitry V. Levin" writes:
> Include (guarded by #ifndef __KERNEL__) to fix the following
> linux/kexec.h userspace compilation errors:
>
> /usr/include/linux/kexec.h:53:2: error: unknown type name 'size_t'
> size_t bufsz;
> /usr/include/linux/kexec.h:55:2: error: unknown type name 'size_t'
>
Xunlei Pang writes:
> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
> it has the risk of being modified by some wrong code during system
> is running.
>
> As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
> when using "crash" or "makedumpfile"(etc) util
Xunlei Pang writes:
> kexec setups identity mappings for all the memory mapped in 1st kernel,
> this is not necessary for the kdump case. Actually it can cause extra
> memory consumption for paging structures, which is quite considerable
> on modern machines with huge memory.
>
> E.g. On our 24TB
Petr Tesarik writes:
> On Mon, 20 Mar 2017 10:17:42 +0800
> Xunlei Pang wrote:
>
>> On 03/19/2017 at 02:23 AM, Petr Tesarik wrote:
>> > On Thu, 16 Mar 2017 21:40:58 +0800
>> > Xunlei Pang wrote:
>> >
>> >> On 03/16/2017 at 09:18 PM, Baoquan He wrote:
>> >>> On 03/16/17 at 08:36pm, Xunlei Pang w
Xunlei Pang writes:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like the control page.
>
> Definitely something like this needs a page all to itself, and
Dave Young writes:
> On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
>> Xunlei Pang writes:
>>
>> > As Eric said,
>> > "what we need to do is move the variable vmcoreinfo_note out
>> > of the kernel's .bss section. And modify the code to re
Kees Cook writes:
> On Tue, May 9, 2017 at 4:13 PM, Daniel Micay wrote:
>> On Tue, 2017-05-09 at 16:06 -0700, Kees Cook wrote:
>>> Defining kexec_purgatory as a zero-length char array upsets compile
>>> time size checking. Since this is entirely runtime sized, switch
>>> this to void *. This sil
rated by the future
> CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
> array. This drops the __weak and uses an extern instead, since both
> users define kexec_purgatory.
Acked-by: "Eric W. Biederman"
> Cc: Daniel Micay
> Signed-off-by: Kees
Daniel Walker writes:
> Hi,
>
> These two paths seem to be duplicating each other. We have an issue
> where we're using mtdoops to collect kernel logs on oops and panic, we
> also have a crash kernel (which also collects these logs). mtdoops
> saves logs differently for oops and panic, since oops
Daniel Walker writes:
> On 06/07/2017 09:46 AM, Eric W. Biederman wrote:
>> Daniel Walker writes:
>>
>>> Hi,
>>>
>>> These two paths seem to be duplicating each other. We have an issue
>>> where we're using mtdoops to collect kernel logs o
Pan Bian writes:
> In function kexec_calculate_store_digests(), kfree() is used to free
> memory allocated by crypto_alloc_shash(). It is better to use function
> crypto_free_shash(), which also zeroizes the memory to be freed.
Why is it important to zero memory? There is nothing sensitive bein
Jan H. Schönherr writes:
> Give the administrator the ability to trade kexec safety for kexec speed
> by disabling the digest calculation/verification for regular kexecs.
>
> The behavior of kexec-on-crash is not touched.
The performance of the digest caculation is acceptable on 386s. Or it
was
"Jan H. Schönherr" writes:
> On 02/02/2018 02:42 AM, Eric W. Biederman wrote:
>> Jan H. Schönherr writes:
>>
>>> Give the administrator the ability to trade kexec safety for kexec speed
>>> by disabling the digest calculation/verification for regul
Rahul Lakkireddy writes:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not be easy to reproduce. Snapshot o
Rahul Lakkireddy writes:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not be easy to reproduce. Snapshot
Thadeu Lima de Souza Cascardo writes:
> On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote:
>> Register callback to collect hardware/firmware dumps in second kernel
>> before hardware/firmware is initialized. The dumps for each device
>> will be available under /sys/kernel/crashdd/
Rahul Lakkireddy writes:
> On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman wrote:
>>
>> Rahul Lakkireddy writes:
>>
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporad
Rahul Lakkireddy writes:
> On Tuesday, March 03/27/18, 2018 at 18:47:34 +0530, Eric W. Biederman wrote:
>> Rahul Lakkireddy writes:
>>
>> > On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman
>> > wrote:
>> >>
>> >&g
Rahul Lakkireddy writes:
> On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote:
>> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
>> >Add a new module crashdd that exports the /sys/kernel/crashdd/
>> >directory in second kernel, containing collected hardw
Rahul Lakkireddy writes:
> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> Hi Rahul,
>> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporadically after days or even months
Rahul Lakkireddy writes:
> On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
>> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> > > Hi Rahul,
>> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
Rahul Lakkireddy writes:
> On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman wrote:
>> Rahul Lakkireddy writes:
>>
>> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> >> On 04/18/18 at 06:01pm, Rahul Lakkiredd
While looking this over I found a bug in the way elf notes are being composed.
Rahul Lakkireddy writes:
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index a45f0af22a60..7395462d2f86 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -1145,6 +1150,132 @@ static int __init parse
Rahul Lakkireddy writes:
> v6:
> - Reworked device dump elf note name to contain vendor identifier.
> - Added vmcoredd_header that precedes actual dump in the Elf Note.
> - Device dump's name is moved inside vmcoredd_header.
> - Added "CHELSIO" string as vendor identifier in the Elf Note name
>
Marc Zyngier writes:
> On Tue, 01 May 2018 14:25:54 +0100,
> Bjorn Helgaas wrote:
>
> Hi Bjorn,
>
>> On Tue, May 01, 2018 at 01:59:20PM +0100, Marc Zyngier wrote:
>> > On 01/05/18 13:38, Sinan Kaya wrote:
>> > > +Marc,
>> > >
>> > > On 4/30/2018 5:27 PM, Sinan Kaya wrote:
>> > >> On 4/30/2018 5:
Rahul Lakkireddy writes:
> The sequence of actions done by device drivers to append their device
> specific hardware/firmware logs to /proc/vmcore are as follows:
Except for the missing include that the kbuild test robot caught
I am not seeing a problems.
Acked-by: "Eric W. Biede
Mimi Zohar writes:
> Allow LSMs and IMA to differentiate between the kexec_load and
> kexec_file_load syscalls by adding an "unnecessary" call to
> security_kernel_read_file() in kexec_load. This would be similar to the
> existing init_module syscall calling security_kernel_read_file().
Given t
Mimi Zohar writes:
> On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote:
>> Mimi Zohar writes:
>>
>> > Allow LSMs and IMA to differentiate between the kexec_load and
>> > kexec_file_load syscalls by adding an "unnecessary" call to
>> &
Casey Schaufler writes:
> On 5/3/2018 8:51 AM, Eric W. Biederman wrote:
>> Mimi Zohar writes:
>>
>>> On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote:
>>>> Mimi Zohar writes:
>>>>
>>>>> Allow LSMs and IMA to differentia
Mimi Zohar writes:
> In environments that require the kexec kernel image to be signed, prevent
> using the kexec_load syscall. In order for LSMs and IMA to differentiate
> between kexec_load and kexec_file_load syscalls, this patch set adds a
> call to security_kernel_read_file() in kexec_load_c
Mimi Zohar writes:
> On Thu, 2018-05-03 at 11:42 -0500, Eric W. Biederman wrote:
>> Casey Schaufler writes:
>>
>> > On 5/3/2018 8:51 AM, Eric W. Biederman wrote:
>> >> Mimi Zohar writes:
>> >>
>> >>> On Wed, 2018-05-02 at 0
Mimi Zohar writes:
> [Cc'ing Kees and kernel-hardening]
>
> On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote:
>> Mimi Zohar writes:
>>
>> > In environments that require the kexec kernel image to be signed, prevent
>> > using the kexec
Matthew Garrett writes:
> On Thu, May 3, 2018 at 1:13 PM Eric W. Biederman
> wrote:
>
>> Mimi Zohar writes:
>
>> > In environments that require the kexec kernel image to be signed,
> prevent
>> > using the kexec_load syscall. In order for LSMs
Mimi Zohar writes:
> On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote:
>> Mimi Zohar writes:
>>
>> > [Cc'ing Kees and kernel-hardening]
>> >
>> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote:
>> >> Mimi Zoh
ntroduced
by the last round of changes.
>From 10,000 feet flyover design perspectie and from an ABI perspective
this patchset seems fine.
Acked-by: "Eric W. Biederman"
Eric
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
use
> the name isn't quite right. Especially a wrapper, which is just
> code and execution overhead. Why not change security_kernel_read_file()
> to security_kernel_read_blob() everywhere and be done?
Nacked-by: "Eric W. Biederman"
Nack on this sharing nonsense. These
Dave Young writes:
> [snip]
>
>> >
>> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
>> > + int "System memory size threshold for kdump memory default reserving"
>> > + depends on CRASH_CORE
>> > + default 0
>> > + help
>> > +CRASHKERNEL_DEFAULT_MB is used as default crashkernel value if
>>
Petr Tesarik writes:
2> On Thu, 24 May 2018 09:49:05 +0800
> Dave Young wrote:
>
>> Hi Petr,
>>
>> On 05/23/18 at 10:22pm, Petr Tesarik wrote:
>>[...]
>> > In short, if one size fits none, what good is it to hardcode that "one
>> > size" into the kernel image?
>>
>> I agreed with all the thi
Dave Young writes:
> Hi Eric,
> On 05/23/18 at 10:53am, Eric W. Biederman wrote:
>> Dave Young writes:
>>
>> > [snip]
>> >
>> >> >
>> >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
>> >> > +
I already nacked this approach because the two cases don't
share a bit of code. When I looked closer it was even crazier.
The way ima uses this hook and the post_load hook today is a travesty.
The way the security_kernel_file_read and security_kernel_file_post_read
are called today and are used
ok mess gets cleaned up.
Nacked-by: "Eric W. Biederman"
>
> Signed-off-by: Mimi Zohar
> Cc: Eric Biederman
> Cc: Luis R. Rodriguez
> Cc: Kees Cook
> Cc: David Howells
> ---
> kernel/kexec.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
James Morris writes:
> On Thu, 24 May 2018, Eric W. Biederman wrote:
>
>> Below is where I suggest you start on sorting out these security hooks.
>> - Adding a security_kernel_arg to catch when you want to allow/deny the
>> use of an argument to a syscall. What secur
Petr Tesarik writes:
> V Thu, 24 May 2018 11:34:05 -0500
> ebied...@xmission.com (Eric W. Biederman) napsáno:
>
>> Petr Tesarik writes:
>>
>> 2> On Thu, 24 May 2018 09:49:05 +0800
>> > Dave Young wrote:
>> >
>> >> Hi P
Petr Tesarik writes:
> On Fri, 25 May 2018 15:00:13 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>>[...]
>> The ultimate point is that the absolute best we can do is to run a
>> kernel in memory that we never use for anything else and then we have a
&g
James Morris writes:
> On Fri, 25 May 2018, Eric W. Biederman wrote:
>
>> James Morris writes:
>>
>> > On Thu, 24 May 2018, Eric W. Biederman wrote:
>> >
>> >> Below is where I suggest you start on sorting out these security hooks.
>> >&
Paul Moore writes:
> On Tue, May 29, 2018 at 2:02 PM, Mimi Zohar wrote:
>> Both the init_module and finit_module syscalls call either directly
>> or indirectly the security_kernel_read_file LSM hook. This patch
>> replaces the direct call in init_module with a call to the new
>> security_kernel
Jarrett Farnitano writes:
> Without yielding while loading kimage segments, a large initrd
> will block all other work on the CPU performing the load until
> it is completed. For example loading an initrd of 200MB on a
> low power single core system will lock up the system for a few
> seconds.
>
"Farnitano, Jarrett" writes:
>> On 6/11/18, 4:00 PM, "Eric W. Biederman" wrote:
>>
>> Is there a practical problem with unresponsiveness? You are talking
>> an embedded machine and rarely are there people in front of embedded
>&
ew
> seconds.
>
> To increase system responsiveness to other tasks at that time,
> call cond_resched() in both the crash kernel and normal kernel
> segment loading loops.
>
> Signed-off-by: Jarrett Farnitano
Reviewed-by: "Eric W. Biederman"
> ---
> kernel/kexe
Tetsuo Handa writes:
> I'm waiting for response from makedumpfile developers.
>
> But makedumpfile is a tool for saving kernel crash dump.
> If makedumpfile cannot work, we cannot use kernel crash dump.
I suspect the version string is comparable in size to the pointer to the
version string and a
Linus Torvalds writes:
> On Mon, Aug 20, 2018 at 10:58 AM Nick Desaulniers
> wrote:
>>
>> + akpm, Linus
>>
>> Bumping for review.
>
> Ugh. I am not personally a huge fan of this endless "fix up one at a time".
>
> Just do a patch that removes current_text_addr() entirely and be done
> with it, i
Vivek Goyal writes:
> Current proposed secureboot implementation disables kexec/kdump because
> it can allow unsigned kernel to run on a secureboot platform. Intial
> idea was to sign /sbin/kexec binary and let that binary do the kernel
> signature verification. I had posted RFC patches for this
Vivek Goyal writes:
> On Thu, Nov 21, 2013 at 03:07:04PM -0800, Eric W. Biederman wrote:
>
> [..]
>>
>> Before you are done we need an ELF loader. bzImage really is very
>> uninteresting. To the point I am not at all convinced that an in kernel
>> load
Vivek Goyal writes:
> On Fri, Nov 22, 2013 at 05:34:03AM -0800, Eric W. Biederman wrote:
>
> [..]
>> > Why ELF case is so interesting. I have not use kexec to boot ELF
>> > images in years and have not seen others using it too. In fact bzImage
>> > seems to be
Vivek Goyal writes:
> On Thu, Nov 21, 2013 at 07:19:07PM +, Matthew Garrett wrote:
>> On Thu, Nov 21, 2013 at 02:13:05PM -0500, Vivek Goyal wrote:
>> > On Thu, Nov 21, 2013 at 07:06:20PM +, Matthew Garrett wrote:
>> > > That would require a certain degree of massaging from userspace if we
1 - 100 of 686 matches
Mail list logo
