linux-kernel - RE: [PATCH 1/1] intel_txt: to fix build errors of CONFIG_ACPI

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, 14 Aug 2009 10:06:44 +0800
From:	"Wang, Shane" <shane.wang@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>
CC:	"Cihula, Joseph" <joseph.cihula@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"jbeulich@...ell.com" <jbeulich@...ell.com>,
	"peterm@...hat.com" <peterm@...hat.com>,
	"Wei, Gang" <gang.wei@...el.com>
Subject: RE: [PATCH 1/1] intel_txt: to fix build errors of CONFIG_ACPI_SLEEP

I agree with hpa, considering TXT doesnot depends on acpi sleep.

However, for hpa's patch, set_mac_regions() is for S3 only. I am wondering whether we should enlarge the range of CONFIG_ACPI_SLEEP in set_mac_regions().
Certainly, for code cleanness, this patch is fine since the assignment

+#ifdef CONFIG_X86_TRAMPOLINE
 	/* AP trampoline code */
-	tboot->mac_regions[1].start =
-			PFN_PHYS(PFN_DOWN(virt_to_phys(trampoline_base)));
-	tboot->mac_regions[1].size = PFN_UP(TRAMPOLINE_SIZE) << PAGE_SHIFT;
+	add_mac_region(virt_to_phys(trampoline_base), TRAMPOLINE_SIZE);
+#endif
 	/* kernel code + data + bss */
-	tboot->mac_regions[2].start = PFN_PHYS(PFN_DOWN(virt_to_phys(&_text)));
-	tboot->mac_regions[2].size = PFN_PHYS(PFN_UP(virt_to_phys(&_end))) -
-				     PFN_PHYS(PFN_DOWN(virt_to_phys(&_text)));
+	add_mac_region(virt_to_phys(_text), _end - _text);

takes effect but tboot->mac_regions[] will never be used without S3.

Thanks.
Shane

H. Peter Anvin wrote:
> On 08/12/2009 11:46 PM, Ingo Molnar wrote:
>> * Wang, Shane <shane.wang@...el.com> wrote:
>> 
>>> Signed-off-by: Shane Wang <shane.wang@...el.com>
>>> 
>>> diff -r 7358cf1b3090 arch/x86/kernel/tboot.c
>>> --- a/arch/x86/kernel/tboot.c   Wed Aug 12 03:04:23 2009 -0700
>>> +++ b/arch/x86/kernel/tboot.c   Wed Aug 12 18:06:21 2009 -0700
>>> @@ -169,6 +169,7 @@ void tboot_create_trampoline(void)
>>> 
>>>  static void set_mac_regions(void)
>>>  {
>>> +#ifdef CONFIG_ACPI_SLEEP
>>>         tboot->num_mac_regions = 3;
>>>         /* S3 resume code */
>>>         tboot->mac_regions[0].start =
>>> PFN_PHYS(PFN_DOWN(acpi_wakeup_address)); @@ -181,6 +182,7 @@ static
>>>         void set_mac_regions(void) tboot->mac_regions[2].start =
>>>         PFN_PHYS(PFN_DOWN(virt_to_phys(&_text)));
>>>                                      tboot->mac_regions[2].size =
>>> PFN_PHYS(PFN_UP(virt_to_phys(&_end))) -
>>> PFN_PHYS(PFN_DOWN(virt_to_phys(&_text))); +#endif 
>> 
>> These #ifdefs are quite ugly. Why not add a 'depends on ACPI_SLEEP'
>> rule to the INTEL_TXT Kconfig section?
> 
> I *strongly* disagree with that kind of false dependencies.  It makes
> it seem like there is something magic going on, which invites cargo
> cult programming in the future.  I also think those particular
> #ifdefs are fairly innocuous... it's not like they're hiding flow of
> control or major chunks of code.
> 
> However, I think the actual code to set the sections is ugly as hell,
> which is probably why the #ifdef sticks in your eyes.
> 
> Consider the attached instead patch, which abstracts some of the (way
> more complex than it should be) open-coded stuff and therefore makes
> it stick out less.
> 
> 	-hpa

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