On 12/28/18 at 09:12am, Dave Young wrote:
> The code cleanup mentioned in Fixes tag changed the behavior of
> kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> allocate free memory only when kbuf.mem is initialized as zero.
>
> But in x86 kexec_file_load implementation there are a fe
On Tue, Jan 15, 2019 at 10:42 AM Dave Young wrote:
>
> On 01/14/19 at 11:10am, Mimi Zohar wrote:
> > On Sun, 2019-01-13 at 09:39 +0800, Dave Young wrote:
> > > Hi,
> > >
> > > On 01/11/19 at 11:13am, Mimi Zohar wrote:
> > > > On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> > > > [snip]
> >
On 01/14/19 at 11:10am, Mimi Zohar wrote:
> On Sun, 2019-01-13 at 09:39 +0800, Dave Young wrote:
> > Hi,
> >
> > On 01/11/19 at 11:13am, Mimi Zohar wrote:
> > > On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> > > [snip]
> > >
> > > > Personally I would like to see platform key separated fr
- Original Message -
> On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> > No. It needs *both* the vmlinux file and the vmcore file in order to read
> > kernel
> > virtual memory, so just having a kernel virtual address is insufficient.
> >
> > So it's a chicken-and-egg
On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> No. It needs *both* the vmlinux file and the vmcore file in order to read
> kernel
> virtual memory, so just having a kernel virtual address is insufficient.
>
> So it's a chicken-and-egg situation. This particular --osrelease opt
- Original Message -
> On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> > That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> > pulls out the OSRELEASE string from it, so that a user can determine what
> > vmlinux file should be used with that vm
On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> pulls out the OSRELEASE string from it, so that a user can determine what
> vmlinux file should be used with that vmcore for normal crash analysis.
And th
- Original Message -
> On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> > There's no reading of the dumpfile's memory involved, and that being the
> > case,
> > the vmlinux file is not utilized. That's the whole point of the crash
> > option, i.e.,
> > taking a vmcore
On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> There's no reading of the dumpfile's memory involved, and that being the case,
> the vmlinux file is not utilized. That's the whole point of the crash
> option, i.e.,
> taking a vmcore file, and trying to determine what kernel shoul
These changes work in conjunction with the signature
verification support for Xen I published recently.
Prior to this change, kexec supported the following
three modes of operation:
kexec_load:
- unverified loading of kernel into Linux (original mode)
- unverified loading of kernel into Xen
kexec
Changes needed to the xen/common/Makefile in order to stitch in the
compiling of OpenSSL as well as the PECOFF file decoder and signature
verification code.
Signed-off-by: Eric DeVolder
---
xen/common/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/xen/common/Makefile b/xen/comm
This patch creates a new file that is in turn a patch that contains a
small number of changes needed in order to soldier through the
compilation of all the OpenSSL sources within Xen.
This patch is applied to OpenSSL in xen.spec.
Signed-off-by: Eric DeVolder
---
openssl-1.1.0i.patch | 378 +
The changes to xen.spec are needed to unpack, configure and
generate a Makefile for building OpenSSL within Xen.
The changes to xen.spec also apply patches which are primarily
the new files as part of the signature verification effort,
as well as some tweaks to Xen files to facilitate compiling of
This change adds a new entry point in libxenctrl for the
kexec_file_load() operation. The code for kexec_file_load() is nearly
identical to kexec_load() other than the use of hypercall op
KEXEC_CMD_kexec_file_load rather than KEXEC_CMD_kexec_load.
Signed-off-by: Eric DeVolder
---
tools/libxc/xc_
On April 20, 2018, I posted to xen-devel an RFC inquiring about
support for signature verification of kexec within Xen:
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01655.html
Since then, I've worked towards a solution. For the purposes of
understanding signature verification,
This change adds to Xen the kexec_file_load() entry point. The
kexec_file_load() is nearly identical to kexec_load(), but with the
added code to handle checking and handling of PECOFF Authenticode
signature verification.
Signed-off-by: Eric DeVolder
---
xen/common/kexec.c | 131
This is a collection of small changes to Xen sources to
allow compiling of OpenSSL within Xen kernel. There are a
few necessary code stubs, but vast majority is header file
manipulation to pass compilation.
Note I created an include2/ directory to place all the
standard include files needed by the
- Original Message -
> On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> > Preferably it would be left as-is. The crash utility has a "crash
> > --osrelease vmcore"
> > option that only looks at the dumpfile header, and just dump the string.
> > With respect
> > to compr
On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> Preferably it would be left as-is. The crash utility has a "crash
> --osrelease vmcore"
> option that only looks at the dumpfile header, and just dump the string.
> With respect
> to compressed kdumps, crash could alternatively lo
- Original Message -
> On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> > As for makedumpfile, it will be not impossible to remove the
> > init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> > Because historically OSRELEASE has been a kind of a mandatory en
Hi Akashi,
Thanks for the patch.
On 01/11/2019 03:27 PM, AKASHI Takahiro wrote:
# My kexec_file patch for arm64 is now merged in v5.0-rc1.
With this patch, kexec_file_load() system call is supported.
Signed-off-by: AKASHI Takahiro
---
kexec/arch/arm64/kexec-arm64.c| 10 +-
On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> As for makedumpfile, it will be not impossible to remove the
> init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> Because historically OSRELEASE has been a kind of a mandatory entry
> in vmcoreinfo from the beginning o
On 1/11/2019 7:33 AM, Borislav Petkov wrote:
> On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
>> +init_uts_ns.name.release
>> +
>> +
>> +The version of the Linux kernel. Used to find the corresponding source
>> +code from which the kernel has been built.
>> +
On Sun, 2019-01-13 at 09:39 +0800, Dave Young wrote:
> Hi,
>
> On 01/11/19 at 11:13am, Mimi Zohar wrote:
> > On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> > [snip]
> >
> > > Personally I would like to see platform key separated from integrity.
> > > But for the kexec_file part I think it
On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)
You could give it a try - it
On Mon, Jan 14, 2019 at 09:52:14AM +0800, lijiang wrote:
> I would like to remove this variable and post again.
No, you should remove the vmcoreinfo export too:
kernel/crash_core.c:398:VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
after making sure userspace is not using it and *then*
26 matches
Mail list logo
