On Tue, Jun 24, 2014 at 01:31:25PM -0400, Vivek Goyal wrote:
> I think problem is that we shift 1 by 32 bits in this case (31 - 0 +
> 1) and that overflows the size of unsigned. So there is this corner
> case where it does not seem to work (or atleast outputs warning).
Right, that is a corner
On Sun, Jun 15, 2014 at 06:35:15PM +0200, Borislav Petkov wrote:
[..]
> > +int kexec_setup_initrd(struct boot_params *params,
> > + unsigned long initrd_load_addr, unsigned long initrd_len)
> > +{
> > + params->hdr.ramdisk_image = initrd_load_addr & 0xUL;
> > +
On Sun, Jun 15, 2014 at 06:35:15PM +0200, Borislav Petkov wrote:
[..]
+int kexec_setup_initrd(struct boot_params *params,
+ unsigned long initrd_load_addr, unsigned long initrd_len)
+{
+ params-hdr.ramdisk_image = initrd_load_addr 0xUL;
+ params-hdr.ramdisk_size =
On Tue, Jun 24, 2014 at 01:31:25PM -0400, Vivek Goyal wrote:
I think problem is that we shift 1 by 32 bits in this case (31 - 0 +
1) and that overflows the size of unsigned. So there is this corner
case where it does not seem to work (or atleast outputs warning).
Right, that is a corner case
On Mon, Jun 16, 2014 at 11:27:20PM +0200, Borislav Petkov wrote:
> On Mon, Jun 16, 2014 at 05:15:00PM -0400, Vivek Goyal wrote:
> > Do we want to show all the rejection messages from bzImage64 and
> > bzImage32 loaders. It might be too verbose to show users that before
> > vmlinux loader accepted
On Mon, Jun 16, 2014 at 05:15:00PM -0400, Vivek Goyal wrote:
> Do we want to show all the rejection messages from bzImage64 and
> bzImage32 loaders. It might be too verbose to show users that before
> vmlinux loader accepted the image other loaders on this arches rejcted
> the image.
I get all
On Mon, Jun 16, 2014 at 10:57:43PM +0200, Borislav Petkov wrote:
> On Mon, Jun 16, 2014 at 04:06:08PM -0400, Vivek Goyal wrote:
> > There can be more than one loader and the one which claims first
> > to recognize the image will get to load the image. So once 32 bit
> > loader support comes in, it
On Mon, Jun 16, 2014 at 04:06:08PM -0400, Vivek Goyal wrote:
> There can be more than one loader and the one which claims first
> to recognize the image will get to load the image. So once 32 bit
> loader support comes in, it might happen that we ask 64bit loader
> first and it rejects the image
On Sun, Jun 15, 2014 at 06:35:15PM +0200, Borislav Petkov wrote:
[..]
> > +int bzImage64_probe(const char *buf, unsigned long len)
> > +{
> > + int ret = -ENOEXEC;
> > + struct setup_header *header;
> > +
> > + /* kernel should be atleast two sector long */
>
>
On Sun, Jun 15, 2014 at 06:35:15PM +0200, Borislav Petkov wrote:
[..]
+int bzImage64_probe(const char *buf, unsigned long len)
+{
+ int ret = -ENOEXEC;
+ struct setup_header *header;
+
+ /* kernel should be atleast two sector long */
two
On Mon, Jun 16, 2014 at 04:06:08PM -0400, Vivek Goyal wrote:
There can be more than one loader and the one which claims first
to recognize the image will get to load the image. So once 32 bit
loader support comes in, it might happen that we ask 64bit loader
first and it rejects the image and
On Mon, Jun 16, 2014 at 10:57:43PM +0200, Borislav Petkov wrote:
On Mon, Jun 16, 2014 at 04:06:08PM -0400, Vivek Goyal wrote:
There can be more than one loader and the one which claims first
to recognize the image will get to load the image. So once 32 bit
loader support comes in, it might
On Mon, Jun 16, 2014 at 05:15:00PM -0400, Vivek Goyal wrote:
Do we want to show all the rejection messages from bzImage64 and
bzImage32 loaders. It might be too verbose to show users that before
vmlinux loader accepted the image other loaders on this arches rejcted
the image.
I get all that.
On Mon, Jun 16, 2014 at 11:27:20PM +0200, Borislav Petkov wrote:
On Mon, Jun 16, 2014 at 05:15:00PM -0400, Vivek Goyal wrote:
Do we want to show all the rejection messages from bzImage64 and
bzImage32 loaders. It might be too verbose to show users that before
vmlinux loader accepted the
On 06/15/2014 09:35 AM, Borislav Petkov wrote:
>
>> +if (memcmp((char *)>header, "HdrS", 4) != 0) {
>
> Not strncmp? "HdrS" is a string...
>
No, memcmp() is more appropriate. It is really more of a byte sequence
than a string.
It could just as easily be done as:
header->header
On Tue, Jun 03, 2014 at 09:07:00AM -0400, Vivek Goyal wrote:
> This is loader specific code which can load bzImage and set it up for
> 64bit entry. This does not take care of 32bit entry or real mode entry.
>
> 32bit mode entry can be implemented if somebody needs it.
>
> Signed-off-by: Vivek
On Tue, Jun 03, 2014 at 09:07:00AM -0400, Vivek Goyal wrote:
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry.
32bit mode entry can be implemented if somebody needs it.
Signed-off-by: Vivek Goyal
On 06/15/2014 09:35 AM, Borislav Petkov wrote:
+if (memcmp((char *)header-header, HdrS, 4) != 0) {
Not strncmp? HdrS is a string...
No, memcmp() is more appropriate. It is really more of a byte sequence
than a string.
It could just as easily be done as:
header-header ==
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry.
32bit mode entry can be implemented if somebody needs it.
Signed-off-by: Vivek Goyal
---
arch/x86/include/asm/kexec-bzimage.h | 11 ++
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry.
32bit mode entry can be implemented if somebody needs it.
Signed-off-by: Vivek Goyal vgo...@redhat.com
---
arch/x86/include/asm/kexec-bzimage.h | 11 ++
20 matches
Mail list logo
