linux-kernel - Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for x86_init.mapping.pagetable

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, 24 Aug 2012 12:03:09 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Attilio Rao <attilio.rao@...rix.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Subject: Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for
 x86_init.mapping.pagetable_reserve

On Thu, Aug 23, 2012 at 06:13:39PM +0100, Attilio Rao wrote:
> You seriously think that adding a single-check, that will be
> certainly skipped (now), in a boot-time function is going to add any
> performance burden?
> 
> >What you are doing is actively wrong. You suggest that it's fine to
> >call that function with something different than pgt_buf_start as the
> >start argument. That's complete nonsense. The early pages are
> >allocated bottom up beginning at pgt_buf_start. So what the heck would
> >make it sane to change that argument ever?
> 
> If you really don't like this approach, at this point I think the
> best thing to do is to assume that the start address will be
> pgt_buf_start and loose the starting argument at all.
> If you agree I can make a patch for that.

One thing I don't understand is why is xen touching x86 code when it
doesn't have to? At least I cannot find a single reason for it in this
thread.

Thomas is clearly explaining to you that what you're trying to
enforce cannot happen on baremetal x86 and you're still insisting on
"documenting" that.

Here's a simple answer: if it doesn't fix a bug on x86 baremetal (and
you're changing x86 native code only for the sake of xen), there's no
reason wasting energy to create patches.

Thanks.

-- 
Regards/Gruss,
    Boris.
--
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/