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:	Tue, 04 Mar 2008 17:51:16 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"Mark McLoughlin" <markmc@...hat.com>,
	"Alexander van Heukelum" <heukelum@...lshack.com>,
	"Ingo Molnar" <mingo@...e.hu>, "Ian Campbell" <ijc@...lion.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>, "Andi Kleen" <ak@...e.de>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2


On Tue, 04 Mar 2008 07:18:48 -0800, "Jeremy Fitzhardinge"
<jeremy@...p.org> said:
> Mark McLoughlin wrote:
> > This is a bit magic, is it worth splitting it out as something like
> > is_paravirt_environment() ?
> >   
> 
> Yes, is_paravirt() already exists for this purpose.

Hi,

If it exists, it is well-hidden. A grep for is_paravirt on the testing
tree turns up nothing. Did you get the name right?

> The code looking at the boot params will only work if we actually booted 
> via the paravirt Linux boot protocol, which Xen doesn't at present.

I chose to code it exactly this way, because it is what is used in
head_32.S to choose how to start the kernel. Or is this code not
executed at all?

[excerpt form head_32.S]
        cmpw $0x207, pa(boot_params + BP_version)
        jb default_entry

        /* Paravirt-compatible boot parameters.  Look to see what
        architecture
                we're booting under. */
        movl pa(boot_params + BP_hardware_subarch), %eax
        cmpl $num_subarch_entries, %eax
        jae bad_subarch

        movl pa(subarch_entries)(,%eax,4), %eax
        subl $__PAGE_OFFSET, %eax
        jmp *%eax
[and]
subarch_entries:
        .long default_entry             /* normal x86/PC */
        .long lguest_entry              /* lguest hypervisor */
        .long xen_entry                 /* Xen hypervisor */
num_subarch_entries = (. - subarch_entries) / 4
[end]

If this is indeed not executed, is there a way to detect whether
we can expect the environment to behave like a normal pc in terms
of magic addresses, bios areas, isa reserved address space and so
on?

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - mmm... Fastmail...

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ