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:	Wed, 20 Jun 2012 13:59:23 -0400
From:	Ulrich Drepper <drepper@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Yinghai Lu <yinghai@...nel.org>, jbarnes@...tuousgeek.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	lenb@...nel.org, x86@...nel.org, linux-pci@...r.kernel.org
Subject: Re: SNB PCI root information

On Wed, Jun 20, 2012 at 1:17 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> I don't understand this.  Is there an *advantage* to silently throwing
> away the information the user specified on the command line?  If the
> user goes to the trouble of discovering and using a command line
> argument, I think that user-supplied information should override
> anything the kernel can figure out on its own.  Ulrich, do you have an
> opinion either way?

If the BIOS information we look for would be something generic then we
might want to have something to overwrite.  But in this case it's a
very specific piece of information which only has one correct value
and I'd hope the BIOS writers get it right.

Assuming this there *might* be value in having it the way the patch
does now.  If the BIOS changes it could in theory also renumber the
devices etc.  In this case the kernel command line overwrite values
might become wrong while a newly-added _PXM entry might be right.
We've seen all kind of things happening on BIOS updates...

On the other hand it's easy enough to then remove the kernel command
line parameter.  It's also probably more in line with other parameters
which overwrite information the kernel determines otherwise
automatically.

I'd be willing to go with Yinghai's recommendation and give the BIOS
writers the benefit of a doubt that they get things right.  If they
prove to be incapable again we can still change the option handling to
overwrite the kernel setting regardless.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ