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:	Fri, 04 May 2007 08:38:53 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Andi Kleen <ak@...e.de>, Chris Wright <chrisw@...s-sol.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Zachary Amsden <zach@...are.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 3/3] boot bzImages under paravirt

Rusty Russell <rusty@...tcorp.com.au> writes:

> (This is kind of a bonus, but it shows how minor the change is to boot
> bzImages)
>
> Skipping over the "cli" and segment loading is enough to allow lguest
> to boot bzImages.  There are some "out" insns in the unpacking code,
> but lguest already has to emulate/skip-over them because of random x86
> probes during boot.
>
> We can no longer assume the launcher has set the bss to zero: we now
> need to zero it ourselves.

Ok.  Although we can hoist the bss zeroing, if everything needs it.

Are you booting with P=V now?  If not I expect you will run
into trouble if you set CONFIG_RELOCATABLE.

> Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
> ---
>  Documentation/lguest/lguest.c    |  134 +++++++-------------------------------
>  arch/i386/boot/compressed/head.S |    6 +
>  drivers/lguest/core.c            |    8 +-
>  drivers/lguest/lguest.c          |    2
>  4 files changed, 41 insertions(+), 109 deletions(-)
>
> diff -r 73d71b701360 arch/i386/boot/compressed/head.S
> --- a/arch/i386/boot/compressed/head.S	Fri May 04 22:49:34 2007 +1000
> +++ b/arch/i386/boot/compressed/head.S	Fri May 04 22:51:49 2007 +1000
> @@ -32,6 +32,11 @@
>  	.globl startup_32
>  
>  startup_32:
> +#ifdef CONFIG_PARAVIRT
> +        movl %cs,%eax
> +        andl $0x3,%eax
> +        jnz calc_delta
> +#endif
>  	cld
>  	cli
>  	movl $(__BOOT_DS),%eax
> @@ -48,6 +53,7 @@ startup_32:
>   * data at 0x34-0x3f are used as the stack for this calculation.
>   * Only 4 bytes are needed.
>   */
> +calc_delta:
>  	leal 0x40(%esi), %esp
>  	call 1f
>  1:	popl %ebp

In essence this is ok.  I would like to do the research to see if we
can perhaps just remove the segment reload.  Short of that we should
at least be able to remove the unnecessary preprocessor test for
CONFIG_PARAVIRT.

Hmm.  I'm wondering about the segment reload and how much of a problem
that is.  My memory says that segment reloads are not actually a
privileged operation, so we may be able to support this even in
paravirt mode.  How hard would that be to support?  The segment
we reload is a fixed part of our boot protocol.

Anyway something to research.

> +#warning document this with reference to Documentation/i386/boot.txt
> +	u8 hdr[0x300];
> +	int r;
> +	void *p = (void *)0x100000;
> +
> +	lseek(fd, 0, SEEK_SET);
> +	read(fd, hdr, sizeof(hdr));
> +
> +	lseek(fd, (unsigned long)(hdr[0x1F1]+1) * 512, SEEK_SET);

I guess this works.  You don't handle the old case of set_sectors == 0
but I guess you don't support any kernels where that is the case.

> +
> +	while ((r = read(fd, p, 65535)) > 0)
> +		p += r;
> +
> +	return *(unsigned long *)&hdr[0x214];
>  }
>  
>  /*L:140 Loading the kernel is easy when it's a "vmlinux", but most kernels

Eric
-
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/

Powered by blists - more mailing lists