On Fri, Nov 22, 2013 at 09:42:52PM +0100, Jiri Kosina wrote:
[..]
> > @@ -843,7 +1075,11 @@ static int kimage_load_normal_segment(struct kimage
> > *image,
> > PAGE_SIZE - (maddr & ~PAGE_MASK));
> > uchunk = min(ubytes, mchunk);
> >
> > -
On Fri, Nov 22, 2013 at 09:42:52PM +0100, Jiri Kosina wrote:
[..]
@@ -843,7 +1075,11 @@ static int kimage_load_normal_segment(struct kimage
*image,
PAGE_SIZE - (maddr ~PAGE_MASK));
uchunk = min(ubytes, mchunk);
- result =
On 01/06/2014 01:33 PM, Josh Boyer wrote:
> On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin wrote:
>> On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>>>
>>> If secureboot is enabled, it enforces module signature verification. I
>>> think similar will happen for kexec too. How would kernel know that on
On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin wrote:
> On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>>
>> If secureboot is enabled, it enforces module signature verification. I
>> think similar will happen for kexec too. How would kernel know that on
>> a secureboot platform fd original
On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin h...@zytor.com wrote:
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
If secureboot is enabled, it enforces module signature verification. I
think similar will happen for kexec too. How would kernel know that on
a secureboot platform fd original
On 01/06/2014 01:33 PM, Josh Boyer wrote:
On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin h...@zytor.com wrote:
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
If secureboot is enabled, it enforces module signature verification. I
think similar will happen for kexec too. How would kernel know that
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>
> If secureboot is enabled, it enforces module signature verification. I
> think similar will happen for kexec too. How would kernel know that on
> a secureboot platform fd original verification will happen and it is
> sufficient.
>
> I personally
On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
> On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
> wrote:
> > Vivek Goyal writes:
> >
> >> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
> >>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> >
> >>> IMO
On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
If secureboot is enabled, it enforces module signature verification. I
think similar will happen for kexec too. How would kernel know that on
a secureboot platform fd original verification will happen and it is
sufficient.
I personally want to
On Fri, Dec 20, 2013 at 07:32:11PM -0800, H. Peter Anvin wrote:
> thing, as currently built there are megabytes of zeroes in it for no
> good reason.
Then remove them ;) AFAICS, that's x86 only? What a waste!
What's the reason? ALIGN_RODATA? Even if so, vmlinux.gz might be
a fair trade-off.
>
On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
>
> If we're doing fd origin verification (not signatures), can't we
> continue to use a regular bzImage?
I imagine the verification function is separated from the new kexec.
It gets passed the proposed new kernel file*, an optional
On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
If we're doing fd origin verification (not signatures), can't we
continue to use a regular bzImage?
I imagine the verification function is separated from the new kexec.
It gets passed the proposed new kernel file*, an optional
On Fri, Dec 20, 2013 at 07:32:11PM -0800, H. Peter Anvin wrote:
thing, as currently built there are megabytes of zeroes in it for no
good reason.
Then remove them ;) AFAICS, that's x86 only? What a waste!
What's the reason? ALIGN_RODATA? Even if so, vmlinux.gz might be
a fair trade-off.
On 12/20/2013 05:32 PM, Eric W. Biederman wrote:
>
> Stuff and nonsense. bzImage is just an ugly wrapper around an ELF
> image.
>
Not really. We put the ELF image in there to help Xen and presumably
kexec, but there are actually quite a few issues with it... for one
thing, as currently built
"H. Peter Anvin" writes:
> On 12/20/2013 03:11 PM, Eric W. Biederman wrote:
>>
>> In that case the chrome folks would simply have to use an ELF format
>> kernel and not a bzImage.
>>
>
> This is starting to feel like everything is going in the direction of a
> massive feature regression.
On 12/20/2013 03:11 PM, Eric W. Biederman wrote:
>
> In that case the chrome folks would simply have to use an ELF format
> kernel and not a bzImage.
>
This is starting to feel like everything is going in the direction of a
massive feature regression. bzImage may be weird (it has definitely
On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
wrote:
> Vivek Goyal writes:
>
>> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
>>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
>
>>> IMO it's up to user land to search lists of certificates, and present
>>> only
Vivek Goyal writes:
> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
>> IMO it's up to user land to search lists of certificates, and present
>> only the final chain of trust to the kernel for checking.
>>
>> ELF is
On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> > On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
> > > Vivek Goyal writes:
> > >
> > > > On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman
On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W.
Vivek Goyal vgo...@redhat.com writes:
On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
IMO it's up to user land to search lists of certificates, and present
only the final chain of trust to the kernel for checking.
On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
IMO it's up to user land to search lists of
On 12/20/2013 03:11 PM, Eric W. Biederman wrote:
In that case the chrome folks would simply have to use an ELF format
kernel and not a bzImage.
This is starting to feel like everything is going in the direction of a
massive feature regression. bzImage may be weird (it has definitely
grown
H. Peter Anvin h...@zytor.com writes:
On 12/20/2013 03:11 PM, Eric W. Biederman wrote:
In that case the chrome folks would simply have to use an ELF format
kernel and not a bzImage.
This is starting to feel like everything is going in the direction of a
massive feature regression.
On 12/20/2013 05:32 PM, Eric W. Biederman wrote:
Stuff and nonsense. bzImage is just an ugly wrapper around an ELF
image.
Not really. We put the ELF image in there to help Xen and presumably
kexec, but there are actually quite a few issues with it... for one
thing, as currently built
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
> > Vivek Goyal writes:
> >
> > > On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
> > >
> >
> > The init_size should be reflected in the .bss of
On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
The init_size should be reflected in the .bss of
On Wed, Dec 04, 2013 at 09:56:57AM +0800, Baoquan He wrote:
> On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> > + * that kexec_mutex is held.
> > + */
>
> I think kexec_add_buffer is guaranteed to be called before allocating
> control pages, why not updating image->control_page after each time
>
On Wed, Dec 04, 2013 at 09:35:29AM +0800, Baoquan He wrote:
> On 12/02/13 at 10:44am, Vivek Goyal wrote:
> > On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
> >
> > [..]
> > > > +void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
> > > > +
On 12/04/13 at 09:56am, Baoquan He wrote:
> On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> > + * that kexec_mutex is held.
> > + */
>
> I think kexec_add_buffer is guaranteed to be called before allocating
> control pages, why not updating image->control_page after each time
> kexec_add_buffer is
On 12/04/13 at 09:56am, Baoquan He wrote:
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
kexec_add_buffer is called.
On Wed, Dec 04, 2013 at 09:35:29AM +0800, Baoquan He wrote:
On 12/02/13 at 10:44am, Vivek Goyal wrote:
On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
[..]
+void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
+ unsigned long
On Wed, Dec 04, 2013 at 09:56:57AM +0800, Baoquan He wrote:
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> + * that kexec_mutex is held.
> + */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image->control_page after each time
kexec_add_buffer is called. Then when control page is needed, effective
On 12/02/13 at 10:44am, Vivek Goyal wrote:
> On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
>
> [..]
> > > +void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
> > > + unsigned long kernel_len, char *initrd,
> > > + unsigned long
On 12/02/13 at 10:44am, Vivek Goyal wrote:
On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
[..]
+void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
+ unsigned long kernel_len, char *initrd,
+ unsigned long initrd_len,
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
kexec_add_buffer is called. Then when control page is needed, effective
address
On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
[..]
> > +void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
> > + unsigned long kernel_len, char *initrd,
> > + unsigned long initrd_len, char *cmdline,
> > +
On 11/29/13 at 11:10am, Baoquan He wrote:
> On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> > diff --git a/arch/x86/kernel/machine_kexec_64.c
> > b/arch/x86/kernel/machine_kexec_64.c
> > index 4eabc16..fb41b73 100644
> > --- a/arch/x86/kernel/machine_kexec_64.c
> > +++
On 11/29/13 at 11:10am, Baoquan He wrote:
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 4eabc16..fb41b73 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@
On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
[..]
+void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
+ unsigned long kernel_len, char *initrd,
+ unsigned long initrd_len, char *cmdline,
+ unsigned
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 4eabc16..fb41b73 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -22,6 +22,13 @@
> #include
> #include
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 4eabc16..fb41b73 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -22,6 +22,13 @@
#include asm/mmu_context.h
On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
> Vivek Goyal writes:
>
> > On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
> >
> > [..]
> >> > Hmm..., I am running out of ideas here. This is what I understand.
> >> >
> >> > - If I sign the bzImage (using
Vivek Goyal writes:
> On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
>
> [..]
>> > Hmm..., I am running out of ideas here. This is what I understand.
>> >
>> > - If I sign the bzImage (using PKCS1.5 signature), and later it is signed
>> > with authenticode format
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
[..]
Hmm..., I am running out of ideas here. This is what I understand.
- If I sign the bzImage (using PKCS1.5 signature), and later it is signed
with authenticode format
On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
[..]
Hmm..., I am running out of ideas here. This is what I understand.
- If I sign the bzImage (using
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
[..]
> > Hmm..., I am running out of ideas here. This is what I understand.
> >
> > - If I sign the bzImage (using PKCS1.5 signature), and later it is signed
> > with authenticode format signatures, then PKCS1.5 signatures will
On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
[..]
Hmm..., I am running out of ideas here. This is what I understand.
- If I sign the bzImage (using PKCS1.5 signature), and later it is signed
with authenticode format signatures, then PKCS1.5 signatures will not 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
On Wed, 20 Nov 2013, Vivek Goyal wrote:
> This patch implements the in kernel kexec functionality. It implements a
> new system call kexec_file_load. I think parameter list of this system
> call will change as I have not done the kernel image signature handling
> yet. I have been told that I
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
> > > want to be able to
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
want to be able to use the
On Wed, 20 Nov 2013, Vivek Goyal wrote:
This patch implements the in kernel kexec functionality. It implements a
new system call kexec_file_load. I think parameter list of this system
call will change as I have not done the kernel image signature handling
yet. I have been told that I might
Vivek Goyal vgo...@redhat.com 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
This patch implements the in kernel kexec functionality. It implements a
new system call kexec_file_load. I think parameter list of this system
call will change as I have not done the kernel image signature handling
yet. I have been told that I might have to pass the detached signature
and size as
This patch implements the in kernel kexec functionality. It implements a
new system call kexec_file_load. I think parameter list of this system
call will change as I have not done the kernel image signature handling
yet. I have been told that I might have to pass the detached signature
and size as
58 matches
Mail list logo
