On 06/16/2014 02:43 PM, Vivek Goyal wrote:
>>
>> Borislav and I talked about this briefly over IRC. A key part of that
>> is that if userspace could manipulate this system call to consume an
>> unreasonable amount of memory, we would have a problem, for example if
>> this code used vzalloc() inste
On Mon, Jun 16, 2014 at 05:43:13PM -0400, Vivek Goyal wrote:
> Actually currently I am using vzalloc() for command line buffer
> allocation.
>
> image->cmdline_buf = vzalloc(cmdline_len);
> if (!image->cmdline_buf)
> goto out;
>
> Should I switch to using kzalloc() inste
On Mon, Jun 16, 2014 at 02:25:07PM -0700, H. Peter Anvin wrote:
> On 06/16/2014 02:09 PM, Borislav Petkov wrote:
> >
> > Nah, I don't feel strongly about it - I just don't trust userspace and
> > think that every value we get from it should be "sanitized".
> >
>
> Borislav and I talked about thi
On 06/16/2014 02:09 PM, Borislav Petkov wrote:
>
> Nah, I don't feel strongly about it - I just don't trust userspace and
> think that every value we get from it should be "sanitized".
>
Borislav and I talked about this briefly over IRC. A key part of that
is that if userspace could manipulate
On Mon, Jun 16, 2014 at 04:53:31PM -0400, Vivek Goyal wrote:
> Kdump kernel uses a different command line. It adds extra command line
> options to currently running kernels.
>
> Till recent past we used to pass new kernel's memory map using command
> line "memmap=" and when command line size was 2
On Mon, Jun 16, 2014 at 10:05:26PM +0200, Borislav Petkov wrote:
> On Mon, Jun 16, 2014 at 01:38:23PM -0400, Vivek Goyal wrote:
> > And what's the sane default in this case?
>
> COMMAND_LINE_SIZE
>
> > Using current kernel's command line size will not work if future
> > kernel decide to support e
On Mon, Jun 16, 2014 at 01:38:23PM -0400, Vivek Goyal wrote:
> And what's the sane default in this case?
COMMAND_LINE_SIZE
> Using current kernel's command line size will not work if future
> kernel decide to support even longer command line size.
When do you ever get to kexec a kernel with comm
On Fri, Jun 13, 2014 at 05:36:20PM +0200, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 08:46:09AM -0400, Vivek Goyal wrote:
> > If not, then we really can't do anything about it. A large memory
> > allocation will fail and user will get error.
>
> Of course we can! You can't trust userspace an
On Fri, Jun 13, 2014 at 08:46:09AM -0400, Vivek Goyal wrote:
> If not, then we really can't do anything about it. A large memory
> allocation will fail and user will get error.
Of course we can! You can't trust userspace and you need to check the
values it gives you through the syscall.
And you n
On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote:
> On 06/13/14 at 09:50am, Borislav Petkov wrote:
> > On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > > not tell us anything about command line siz
On Fri, Jun 13, 2014 at 09:50:11AM +0200, Borislav Petkov wrote:
> On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > not tell us anything about command line size supported by kernel being
> > loaded.
>
> What
On Fri, Jun 13, 2014 at 04:24:59PM +0800, WANG Chao wrote:
> Emm.. I'm not sure, but I think there might be a chance that
> COMMAND_LINE_SIZE extend in the future. In general 8K is safe to use,
> because the current greatest one is 4K.
Sure, but kexec cannot load a kernel of different arch, can it
On 06/13/14 at 10:10am, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote:
> > By greping for COMMAND_LINE_SIZE for different arch, I think 8K being
> > the fallback, in general, is good for now and the future:
>
> Why - we could simply use the arch default one.
E
On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote:
> By greping for COMMAND_LINE_SIZE for different arch, I think 8K being
> the fallback, in general, is good for now and the future:
Why - we could simply use the arch default one.
--
Regards/Gruss,
Boris.
Sent from a fat crate under
On 06/13/14 at 09:50am, Borislav Petkov wrote:
> On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > not tell us anything about command line size supported by kernel being
> > loaded.
>
> Whatever you do, you d
On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> not tell us anything about command line size supported by kernel being
> loaded.
Whatever you do, you do need a sane default because even querying the
boot protoc
On Wed, Jun 11, 2014 at 04:13:20PM +0200, Borislav Petkov wrote:
> On Fri, Jun 06, 2014 at 02:02:14PM -0400, Vivek Goyal wrote:
> > > If you want to make it more explicit, you could do
> > >
> > > #define RES_OK0
> > > #define RES_ERR 1
> > > #define RES_STOP 2
> >
> > You
On Fri, Jun 06, 2014 at 02:02:14PM -0400, Vivek Goyal wrote:
> > If you want to make it more explicit, you could do
> >
> > #define RES_OK 0
> > #define RES_ERR 1
> > #define RES_STOP2
>
> You are saying that called back function should return this to walk_*
> functio
On Mon, Jun 09, 2014 at 01:35:38PM +0800, WANG Chao wrote:
[..]
> > > What's the upper length of vzalloc(). I think if it is too big to alloc,
> > > then vzalloc() should return me an error?
>
> When allocating too large, eg. vzalloc(-1), kernel spits:
>
> [ 457.407579] vmalloc: allocation fail
On Mon, Jun 09, 2014 at 10:11:22AM +0800, Dave Young wrote:
[..]
> > > > + image->cmdline_buf = vzalloc(cmdline_len);
> > >
> > > You should validate the upper/lower boundary of cmdline_len before
> > > calling vzalloc. When cmdline_len is 0 or too large, vmalloc failure
> > > message would
On 06/09/14 at 10:11am, Dave Young wrote:
> On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> > On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Previous patch provided the interface definition and this patch prvides
> > > > implementati
On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > Previous patch provided the interface definition and this patch prvides
> > > implementation of new syscall.
> > >
> > > Previously segment l
On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > Previous patch provided the interface definition and this patch prvides
> > implementation of new syscall.
> >
> > Previously segment list was prepared in user space. Now user space just
> >
On Fri, Jun 06, 2014 at 04:11:33AM +0200, Borislav Petkov wrote:
[..]
> > > Might wanna define pr_fmt when using the pr_* things fo the first time
> > > in this file.
> >
> > Hmm
> >
> > I see that printk.h already provides a definition is pr_fmt is not
> > defined. So that means I shouldn't
On 06/03/14 at 09:06am, Vivek Goyal wrote:
> Previous patch provided the interface definition and this patch prvides
> implementation of new syscall.
>
> Previously segment list was prepared in user space. Now user space just
> passes kernel fd, initrd fd and command line and kernel will create a
On Thu, Jun 05, 2014 at 04:17:32PM -0400, Vivek Goyal wrote:
> I think everything is already available in "struct kimage *image". So
> I don't have to pass all these separately. I think I will remove all
> these extra parameters and expect arch function to retrieve all that
> from "struct kimage *i
On Thu, Jun 05, 2014 at 01:15:35PM +0200, Borislav Petkov wrote:
[..]
> > --- a/arch/x86/kernel/machine_kexec_64.c
> > +++ b/arch/x86/kernel/machine_kexec_64.c
> > @@ -22,6 +22,13 @@
> > #include
> > #include
> >
> > +/* arch dependent functionality related to kexec file based syscall */
>
On Tue, Jun 03, 2014 at 09:06:56AM -0400, Vivek Goyal wrote:
> Previous patch provided the interface definition and this patch prvides
> implementation of new syscall.
>
> Previously segment list was prepared in user space. Now user space just
> passes kernel fd, initrd fd and command line and ker
Previous patch provided the interface definition and this patch prvides
implementation of new syscall.
Previously segment list was prepared in user space. Now user space just
passes kernel fd, initrd fd and command line and kernel will create a
segment list internally.
This patch contains generic
29 matches
Mail list logo
