On 01/11/2013 01:08 PM, Vivek Goyal wrote:
A signed /sbin/kexec would realistically have to be statically linked,
at least in the short term; otherwise the libraries and ld.so would need
verification as well.
Yes. That's the expectation. Sign only statically linked exeutables which
don't do an
On Fri, Jan 11, 2013 at 01:03:41PM -0800, H. Peter Anvin wrote:
> On 01/11/2013 12:52 PM, Vivek Goyal wrote:
> >
> > Eric,
> >
> > In a private conversation, David Howells suggested why not pass kernel
> > signature in a segment to kernel and kernel can do the verification.
> >
> > /sbin/kexec s
On 01/11/2013 12:52 PM, Vivek Goyal wrote:
>
> Eric,
>
> In a private conversation, David Howells suggested why not pass kernel
> signature in a segment to kernel and kernel can do the verification.
>
> /sbin/kexec signature is verified by kernel at exec() time. Then
> /sbin/kexec just passes on
On Fri, Jan 11, 2013 at 12:26:56PM -0800, Eric W. Biederman wrote:
[..]
> Recently there is a desire to figure out how to /sbin/kexec support
> signed kernel images. What will probably happen is to have a specially
> trusted userspace application perform the verification. Sort of like
> dom0 for
On Fri, Jan 11, 2013 at 12:26:48PM -0800, H. Peter Anvin wrote:
> >
> >And there is nothing fancy to be done for EFI and SecureBoot? Or is
> >that something that the kernel has to handle on its own (so somehow
> >passing some certificates to somewhere).
> >
>
> For EFI, no... other than passing th
And there is nothing fancy to be done for EFI and SecureBoot? Or is
that something that the kernel has to handle on its own (so somehow
passing some certificates to somewhere).
For EFI, no... other than passing the EFI parameters, which apparently
is *not* currently done (David Woodhouse is w
Konrad Rzeszutek Wilk writes:
> On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
>> The basic kexec interface is.
>>
>> load ranges of virtual addresses physical addresses.
>> jump to the physical address with identity mapped page tables.
>>
>> There are a few flags to allow
David Vrabel writes:
> On 11/01/13 13:22, Daniel Kiper wrote:
>> On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
>>> On 04/01/13 17:01, Daniel Kiper wrote:
My .5 cents:
- We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
probably we should intr
On Fri, Jan 11, 2013 at 03:22:35PM +, David Vrabel wrote:
> On 11/01/13 13:22, Daniel Kiper wrote:
> > On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
> >> On 04/01/13 17:01, Daniel Kiper wrote:
> >>> My .5 cents:
> >>> - We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kex
On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk writes:
>
> > On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
> >> I think that new kexec hypercall function should mimics kexec syscall.
> >> It means that all arguments passed to hypercall s
On 11/01/13 13:22, Daniel Kiper wrote:
> On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
>> On 04/01/13 17:01, Daniel Kiper wrote:
>>> My .5 cents:
>>> - We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
>>> probably we should introduce KEXEC_CMD_kexec_load2 an
On Mon, Jan 07, 2013 at 01:49:44PM +, Ian Campbell wrote:
> On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
> > I think that new kexec hypercall function should mimics kexec syscall.
>
> We want to have an interface can be used by non-Linux domains (both dom0
> and domU) as well though,
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
> On 04/01/13 17:01, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
> >> On 04/01/13 14:22, Daniel Kiper wrote:
> >>> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> On 27/12/1
Konrad Rzeszutek Wilk writes:
> On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
>> I think that new kexec hypercall function should mimics kexec syscall.
>> It means that all arguments passed to hypercall should have same types
>> if it is possible or if it is not possible then conv
On 04/01/13 17:01, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
>> On 04/01/13 14:22, Daniel Kiper wrote:
>>> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
> Andrew Cooper writes:
>
>>>
On 04/01/13 14:22, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
>> On 27/12/12 18:02, Eric W. Biederman wrote:
>>> Andrew Cooper writes:
>>>
On 27/12/2012 07:53, Eric W. Biederman wrote:
> The syscall ABI still has the wrong semantics.
>
> A
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > > >>> On 04.01.13 at 15:2
On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
> I think that new kexec hypercall function should mimics kexec syscall.
We want to have an interface can be used by non-Linux domains (both dom0
and domU) as well though, so please bear this in mind.
Historically we've not always been good a
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > > On Wed, Jan 02, 2013 at 11:26:43AM +00
On Mon, 2013-01-07 at 10:46 +, Andrew Cooper wrote:
> Given that /sbin/kexec creates a binary blob in memory, surely the most
> simple thing is to get it to suitably mlock() the region and give a list
> of VAs to the hypervisor.
More than likely. The DOMID_KEXEC thing was just a radon musin
On 07/01/13 10:25, Ian Campbell wrote:
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
Because current KEXEC_CMD_kexec_load does not load kernel
image and other things into Xen memory. It means that it
should live som
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > > On Wed, Jan 02, 2013 at 11:26:43AM +, And
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > >> /sbin/kexec can load the "Xen" crash kernel its
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> >> /sbin/kexec can load the "Xen" crash kernel itself by issuing
> >> hypercalls using /dev/xen/privcmd. This would rem
On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
> On 04/01/13 14:22, Daniel Kiper wrote:
> > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> >> On 27/12/12 18:02, Eric W. Biederman wrote:
> >>> Andrew Cooper writes:
> >>>
> On 27/12/2012 07:53, Eric W. Biederman
>>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
>> /sbin/kexec can load the "Xen" crash kernel itself by issuing
>> hypercalls using /dev/xen/privcmd. This would remove the need for
>> the dom0 kernel to distinguish between loading a
On Fri, 2013-01-04 at 14:22 +, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > On 27/12/12 18:02, Eric W. Biederman wrote:
> > >Andrew Cooper writes:
> > >
> > >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> > >>>The syscall ABI still has the wrong se
On Fri, Jan 04, 2013 at 03:22:57PM +0100, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > On 27/12/12 18:02, Eric W. Biederman wrote:
> > >Andrew Cooper writes:
> > >
> > >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> > >>>The syscall ABI still has the w
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> On 27/12/12 18:02, Eric W. Biederman wrote:
> >Andrew Cooper writes:
> >
> >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> >>>The syscall ABI still has the wrong semantics.
> >>>
> >>>Aka totally unmaintainable and umergeable.
> >>
>>> On 02.01.13 at 12:26, Andrew Cooper wrote:
> On 27/12/12 18:02, Eric W. Biederman wrote:
>> It probably make sense to split them apart a little even.
>
> Thinking about this split, there might be a way to simply it even more.
>
> /sbin/kexec can load the "Xen" crash kernel itself by issuing
Andrew Cooper writes:
> On 27/12/12 18:02, Eric W. Biederman wrote:
>> Andrew Cooper writes:
>>
>>> On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooper writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even mean,
when the
32 matches
Mail list logo
