linux-kernel - Re: kexec and struct boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 Dec 2012 22:57:47 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kexec and struct boot_params

On Wed, Dec 5, 2012 at 7:12 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Wed, Dec 5, 2012 at 5:57 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> Hi Eric,
>>
>> Could you give a list of struct boot_params field which are initialized
>> properly by kexec?  I think we need to do the sentinel hack, and want to
>> know what to whitelist.
>
> the one with *
> ? means set only when lfb_depth > 8
> also
>    0xa2 to 0x1df is not set
>
> struct x86_linux_param_header {
>         uint8_t  orig_x;                        /* 0x00 */  *
>         uint8_t  orig_y;                        /* 0x01 */  *
>         uint16_t ext_mem_k;                     /* 0x02 -- EXT_MEM_K sits here */   *
>         uint16_t orig_video_page;               /* 0x04 */  *
>         uint8_t  orig_video_mode;               /* 0x06 */  *
>         uint8_t  orig_video_cols;               /* 0x07 */  *
>         uint16_t unused2;                       /* 0x08 */
>         uint16_t orig_video_ega_bx;             /* 0x0a */  *
>         uint16_t unused3;                       /* 0x0c */
>         uint8_t  orig_video_lines;              /* 0x0e */  *
>         uint8_t  orig_video_isVGA;              /* 0x0f */   *
>         uint16_t orig_video_points;             /* 0x10 */   *
>
>         /* VESA graphic mode -- linear frame buffer */
>         uint16_t lfb_width;                     /* 0x12 */   *
>         uint16_t lfb_height;                    /* 0x14 */   *
>         uint16_t lfb_depth;                     /* 0x16 */   *
>         uint32_t lfb_base;                      /* 0x18 */   *
>         uint32_t lfb_size;                      /* 0x1c */   *
>         uint16_t cl_magic;                      /* 0x20 */   *
> #define CL_MAGIC_VALUE 0xA33F
>         uint16_t cl_offset;                     /* 0x22 */   *
>         uint16_t lfb_linelength;                /* 0x24 */   *
>         uint8_t  red_size;                      /* 0x26 */   ?
>         uint8_t  red_pos;                       /* 0x27 */   ?
>         uint8_t  green_size;                    /* 0x28 */   ?
>         uint8_t  green_pos;                     /* 0x29 */   ?
>         uint8_t  blue_size;                     /* 0x2a */   ?
>         uint8_t  blue_pos;                      /* 0x2b */   ?
>         uint8_t  rsvd_size;                     /* 0x2c */   ?
>         uint8_t  rsvd_pos;                      /* 0x2d */   ?
>         uint16_t vesapm_seg;                    /* 0x2e */   *
>         uint16_t vesapm_off;                    /* 0x30 */
>         uint16_t pages;                         /* 0x32 */   *
>         uint8_t  reserved4[12];                 /* 0x34 -- 0x3f reserved for future expansion */
>
>         struct apm_bios_info apm_bios_info;     /* 0x40 */   *
>         struct drive_info_struct drive_info;    /* 0x80 */   *
>         struct sys_desc_table sys_desc_table;   /* 0xa0 */   * only .length =
> 0, aka 0xa2 to 0x1df is not set
>         uint32_t alt_mem_k;                     /* 0x1e0 */  *
>         uint8_t  reserved5[4];                  /* 0x1e4 */
>         uint8_t  e820_map_nr;                   /* 0x1e8 */  *
>         uint8_t  eddbuf_entries;                /* 0x1e9 */  *
>         uint8_t  edd_mbr_sig_buf_entries;       /* 0x1ea */  *
>         uint8_t  reserved6[6];                  /* 0x1eb */
>         HEADER.....                                         copied and or meset 0 and set.
>         uint8_t  reserved16[0x290 - 0x248];     /* 0x248 */
>         uint32_t edd_mbr_sig_buffer[EDD_MBR_SIG_MAX];   /* 0x290 */  *
> #endif
>         struct  e820entry e820_map[E820MAX];    /* 0x2d0 */   *
>         uint8_t _pad8[48];                      /* 0xcd0 */
>         struct  edd_info eddbuf[EDDMAXNR];      /* 0xd00 */   *
>                                                 /* 0xeec */
> #define COMMAND_LINE_SIZE 2048
> };
>
>
>>
>> Also, does kexec set a bootloader ID?
>
> no, 0xff

Hi, Peter,

What's your decision about this?

Do you mean have one boot_params mask in initdata and AND that with
boot_params from bootloader
to clean not used bytes?

So later will not need to check
    if (boot_params.hdr.xloadflags & USE_EXT_BOOT_PARAMS)
?

I worked out other patches that remove kdump 896M limitation.
would like to post those patches to get more testing.
those are needed for bigger system with lots of pcie devices.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/