linux-kernel - Re: [PATCH v5 2/7] efi: Introduce EFI_NO

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]

Message-ID: <20140619144112.GT24049@console-pimps.org>
Date:	Thu, 19 Jun 2014 15:41:12 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Daniel Kiper <daniel.kiper@...cle.com>
Cc:	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, xen-devel@...ts.xenproject.org,
	andrew.cooper3@...rix.com, boris.ostrovsky@...cle.com,
	david.vrabel@...rix.com, eshelton@...ox.com, hpa@...or.com,
	ian.campbell@...rix.com, jbeulich@...e.com, jeremy@...p.org,
	konrad.wilk@...cle.com, matt.fleming@...el.com, mingo@...hat.com,
	mjg59@...f.ucam.org, stefano.stabellini@...citrix.com,
	tglx@...utronix.de
Subject: Re: [PATCH v5 2/7] efi: Introduce EFI_NO_DIRECT flag

On Wed, 18 Jun, at 06:48:35PM, Daniel Kiper wrote:
> >
> > Why don't you want to export efi.fw_vendor, etc? Rationale please.
> 
> I am exporting real addresses (machine addresses) of things which
> I am able to get. Stuff which was created artificially and lives
> in dom0 address space or does not exist are not exported.
 
So, wouldn't it be easier to just leave those fields as
EFI_INVALID_TABLE_ADDR? If they're not usable why fill out an address?

> Hmmm... I do not know what is wrong with this minimal shuffling. We are
> playing here with internal stuff which is not visible outside of any
> given kernel. Additionally, as I saw in a few places arch bits are
> defined in following way:
> 
> #define ARCH_1 10
> 
> #define A_ARCH_CONST ARCH_1
> #define B_ARCH_CONST (ARCH_1 + 1)
> #define C_ARCH_CONST (ARCH_1 + 2)
> ...
> 
> So I think addition is more natural here than subtraction.

No, because we hit the same problem if we need more non-arch bits after
bit 9, it moves the problem, it doesn't fix it. Though admittedly, using
this level of indirection (going through ARCH_1) instead of using
constants does reduce the problem.

Yes, these bits are internal, and yes the shuffling is minimal, but we
can do better.

I'm not suggesting you need to modify your patch. I'm really just
thinking out loud. I'll take care of fixing this up later.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/