linux-kernel - Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

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: <20080825062746.GA26445@elte.hu>
Date:	Mon, 25 Aug 2008 08:27:46 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	David Witbrodt <dawitbro@...global.net>,
	Linux-kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user
	with the same regression

* Yinghai Lu <yhlu.kernel@...il.com> wrote:

> [PATCH] x86: check hpet with BAR v2
> 
> insert some resources to resource tree forcily, so could avoid kernel update the
> resources in pci device.
> 
> should check in device too.
> 
> Signed-off-by: Yinghai Lu <yhlu.kernel@...il.com>
> 
> ---
>  arch/x86/pci/i386.c |   43 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> Index: linux-2.6/arch/x86/pci/i386.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/i386.c
> +++ linux-2.6/arch/x86/pci/i386.c
> @@ -33,6 +33,7 @@
>  #include <linux/bootmem.h>
>  
>  #include <asm/pat.h>
> +#include <asm/hpet.h>
>  
>  #include "pci.h"
>  
> @@ -77,6 +78,30 @@ pcibios_align_resource(void *data, struc
>  }
>  EXPORT_SYMBOL(pcibios_align_resource);
>  
> +static int check_res_with_valid(struct pci_dev *dev, struct resource *res)
> +{
> +	unsigned long base;
> +	unsigned long size;
> +
> +	base = res->start;
> +	size = (res->start == 0 && res->end == res->start) ? 0 :
> +		 (res->end - res->start + 1);
> +
> +	if (!base || !size)
> +		return 0;
> +
> +#ifdef CONFIG_HPET_TIMER
> +	/* for hpet */
> +	if (base == hpet_address && (res->flags & IORESOURCE_MEM)) {
> +		dev_info(&dev->dev, "BAR has HPET at %08lx-%08lx\n",
> +				 base, base + size - 1);
> +		return 1;
> +	}
> +#endif

i think the warning should be more prominent and should also generate a 
stack trace for the kerneloops client to pick up. A WARN() printout 
would be perfect here.

Also, we should do subsequent commits as well enumerating all the other 
'magic' non-PCI-enumerated bus memory resources that matter on a PC 
platform: lapic address and io-apic address(es). Perhaps even the ACPI 
NVS and ACPI data areas that are enumerated in e820.

(the lapic address will likely never be present in a PCI device - but 
maybe the IO-APIC address can be present in theory - so lets protect 
it.)

Another suggestion: perhaps this all should be done as a new, "sticky" 
resource type flag [defined in include/linux/ioport.h and implemented in 
kernel/resource.c], which would be inserted by the hpet driver, and 
which would be listened to by pcibios_allocate_resources() 
automatically. If the resource manager later on finds a generic-looking, 
unclaimed PCI device whose BAR matches on it, then the new semantics 
would mean that the device's BAR will not be touched.

This approach would be even more generic and would allow a robust 
insertion of maybe-PCI addresses into the resource tree.

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