Re: [PATHC v2 5/9] ima: on soft reboot, save the measurement list

[Mimi Zohar]

Hi Dave,

On Thu, 2016-09-01 at 09:57 +0800, Dave Young wrote:
> On 08/30/16 at 06:40pm, Mimi Zohar wrote:

> > + * Called during kexec_file_load so that IMA can add a segment to the kexec
> > + * image for the measurement list for the next kernel.
> > + */
> > +void ima_add_kexec_buffer(struct kimage *image)
> > +{
> > +   static int registered = 0;
> > +   struct kexec_buf kbuf = { .image = image, .buf_align = PAGE_SIZE,
> > + .buf_min = 0, .buf_max = ULONG_MAX,
> > + .top_down = true, .skip_checksum = true };
> > +   int ret;
> > +
> > +   if (!kexec_can_hand_over_buffer())
> > +   return;
> > +
> > +   kexec_segment_size = ALIGN(ima_get_binary_runtime_size() + PAGE_SIZE,
> > +  PAGE_SIZE);
> > +
> > +   if (kexec_segment_size >= (ULONG_MAX - sizeof(long))) {
> > +   pr_err("Binary measurement list too large.\n");
> > +   return;
> > +   }
> 
> Now we added a limitation that total segment size can not be larger than
> half of totalram. see kernel/kexec_core.c sanity_check_segment_list()
> 
> So can it fail early here if kexec_segment_size is over half of total
> ram?

Sure, I'll include this change in the next post.

Mimi


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v24 9/9] Documentation: dt: chosen properties for arm64 kdump

[AKASHI Takahiro]

Rob,

On Wed, Aug 31, 2016 at 02:02:16PM +0900, AKASHI Takahiro wrote:
> On Wed, Aug 31, 2016 at 08:45:46AM +0900, AKASHI Takahiro wrote:
> > Rob,
> > 
> > On Tue, Aug 30, 2016 at 11:34:10AM -0500, Rob Herring wrote:
> > > On Sun, Aug 21, 2016 at 11:28 PM, AKASHI Takahiro
> > >  wrote:
> > > > Rob,
> > > > [Cc: Mark]
> > > >
> > > > On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote:
> > > >> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote:
> > > >> > From: James Morse 
> > > >> >
> > > >> > Add documentation for
> > > >> > linux,crashkernel-base and crashkernel-size,
> > > >> > linux,usable-memory-range, and
> > > >> > linux,elfcorehdr
> > > >> > used by arm64 kexec/kdump to decribe the kdump reserved area, and
> > > >> > the elfcorehdr's location within it.
> > > >> >
> > > >> > Signed-off-by: James Morse 
> > > >> > [takahiro.aka...@linaro.org:
> > > >> > renamed "usable-memory" to "usable-memory-range",
> > > >> > added "linux,crashkernel-base" and "-size" ]
> > > >> > Signed-off-by: AKASHI Takahiro 
> > > >> > ---
> > > >> >  Documentation/devicetree/bindings/chosen.txt | 50 
> > > >> > 
> > > >> >  1 file changed, 50 insertions(+)
> > > >> >
> > > >> > diff --git a/Documentation/devicetree/bindings/chosen.txt 
> > > >> > b/Documentation/devicetree/bindings/chosen.txt
> > > >> > index 6ae9d82..236188a 100644
> > > >> > --- a/Documentation/devicetree/bindings/chosen.txt
> > > >> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > > >> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, 
> > > >> > and only needed on
> > > >> >  book3e) by some versions of kexec-tools to tell the new kernel that 
> > > >> > it
> > > >> >  is being booted by kexec, as the booting environment may differ 
> > > >> > (e.g.
> > > >> >  a different secondary CPU release mechanism)
> > > >> > +
> > > >> > +linux,crashkernel-base
> > > >> > +linux,crashkernel-size
> > > >> > +--
> > > >> > +These properties (currently used on PowerPC and arm64) indicates
> > > >> > +the base address and the size, respectively, of the reserved memory
> > > >> > +range for crash dump kernel.
> > > >> > +e.g.
> > > >> > +
> > > >> > +/ {
> > > >> > +   chosen {
> > > >> > +   linux,crashkernel-base = <0x9 0xf000>;
> > > >> > +   linux,crashkernel-size = <0x0 0x1000>;
> > > >> > +   };
> > > >> > +};
> > > >> > +
> > > >> > +linux,usable-memory-range
> > > >> > +-
> > > >> > +
> > > >> > +This property (currently used only on arm64) holds the memory range,
> > > >> > +the base address and the size, which can be used as system ram on
> > > >> > +the *current* kernel. Note that, if this property is present, any 
> > > >> > memory
> > > >> > +regions under "memory" nodes in DT blob or ones marked as 
> > > >> > "conventional
> > > >> > +memory" in EFI memory map should be ignored.
> > > >> > +e.g.
> > > >> > +
> > > >> > +/ {
> > > >> > +   chosen {
> > > >> > +   linux,usable-memory-range = <0x9 0xf000 0x0 
> > > >> > 0x1000>;
> > > >> > +   };
> > > >> > +};
> > > >>
> > > >> I've read the discussion on this. I think you should use the existing
> > > >> linux,usable-memory property in the memory nodes. If UEFI systems don't
> > > >> have memory nodes, then you can find an UEFI way to describe this. DT 
> > > >> is
> > > >> not the dumping ground for what doesn't fit in UEFI. How do x86 systems
> > > >> work?
> > > >
> > > > Kdump for x86 passes the range of usable memory to crash dump kernel
> > > > either via:
> > > > (a) "memmap=nn@ss" command line parameter, or
> > > > (b) faked BIOS e820 map (a sort of memory map table)
> > > >
> > > > (a) was rejected by Mark [1], and (b) is x86-specific.
> > > >
> > > > I believe that my approach is better because it works in the same way
> > > > either on UEFI systems or DT-based systems.
> > > 
> > > So we have a new way for both UEFI and DT. If UEFI folks can't come up
> > > with a standard way to do things in the UEFI standard, then we just
> > > dump them into DT?
> > 
> > No, I don't think so.
> > According to "Documentation/devicetree/bindings/chosen.txt,
> >   "The chosen node does not represent a real device, but serves as a place
> >for passing data between firmware and the operating system, like boot
> >arguments."
> > 
> > Since kexec/dump is some sort of boot loader, it all makes sense to
> > add a new property as an interface from the old kernel(kexec/dump)
> > to the new kernel. So my approach doesn't break any DT rules.
> > 
> > Please note that, even on UEFI/APCI systems, there are already a few
> > properties used under /chosen, like "linux,uefi-system-table" and 
> > "linux,mmap-*."
> > (Those properties are currently *not* defined in this document, though.)
> > 
> > > I'd rather see alignment with existing DT 

RE: "kernel version not supported" message is causing concerns

[Atsushi Kumagai]

Hello Louis,

>Hello,
>
>Every so often, I get questions or bug report about the fact that makedumpfile
>issues the following message when running :
>
>   The kernel version is not supported.
>   The created dumpfile may be incomplete.
>
>While I understand the requirement for this message, it almost systematically 
>is
>understood by users as "makedumpfile is broken".

I don't think the message itself is bad, the situation for users has
a problem, I guess.
If a distribution provides a combination of a kernel and a makedumpfile
which doesn't support it, it stands to reason that users send a bug report.

>I would like to discuss the opportunity of changing the wording of this message
>so it appears less confusing. Maybe something like :
>
>Warning: makedumpfile has not been tested on this version of the kernel.
> If the created dumpfile is incomplete, you may need to upgrade to a
> newer version of makedumpfile.

I suspect such message doesn't make sense because even the latest makedumpfile
doesn't support the kernel version in your most cases, right ?

I know I have to work harder for following up the latest kernel ASAP,
but I don't agree with your suggestion.


Thanks,
Atsushi Kumagai

>I would be happy to propose a pull request for such a change if accepted.
>
>Kind regards,
>
>...Louis
>
>
>--
>Louis Bouchard
>Software engineer, Cloud & Sustaining eng.
>Canonical Ltd
>Ubuntu developer   Debian Maintainer
>GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
>
>___
>kexec mailing list
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec