linux-kernel - Re: [PATCH 6/8] SFI: add ACPI extensions

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, 23 Jun 2009 12:51:39 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	sfi-devel@...plefirmware.org, linux-kernel@...r.kernel.org,
	Feng Tang <feng.tang@...el.com>,
	Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 6/8] SFI: add ACPI extensions

On Tue, 23 Jun 2009, Andi Kleen wrote:
> Len Brown <lenb@...nel.org> writes:

> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> > @@ -277,6 +277,9 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler)

> > +	if (acpi_disabled)
> > +		return 1;

> This seems like a weird place to hook this in. Shouldn't that be somewhere else, more
> high level?

acpi_table_parse() is actually a high-level API available to drivers.

Today, drivers tend to test acpi_disabled on their own,
which may be too high level...

The catalyst for this change, IIR, was the PCI code calling
and not checking the return value:

--- a/arch/x86/pci/mmconfig-shared.c
...
@@ -606,7 +607,8 @@ static void __init __pci_mmcfg_init(int early)
...
-               acpi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+               if (acpi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg))
+                       sfi_acpi_table_parse(ACPI_SIG_MCFG, NULL, NULL, 0, pci_parse_mcfg);
...


> > +	num_entries = (xsdt->header.length - sizeof(struct acpi_table_header) /
> > +		sizeof(u64));
> > +
> > +	pr_debug(PREFIX "XSDT has %d entries\n", num_entries);
> > +
> > +	for (i = 0; i < num_entries; i++)
> > +		sfi_tb_install_table(xsdt->table_offset_entry[i], SFI_ACPI_TABLE);
> 
> Shouldn't this have some more sanity checking, e.g. for overflows?

good observation. Although we did already check the signature and 
checksum, I don't see that we yet have a sanity check either here
or in sfi_tb_install_table() itself.

thanks,
-Len


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