linux-kernel - Re: 2.6.19-rc4: known unfixed regressions (v3)

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: <m1hcxb7xes.fsf@ebiederm.dsl.xmission.com>
Date:	Tue, 07 Nov 2006 14:35:23 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	olson@...hscale.com
Cc:	"Bryan O'Sullivan" <bos@...pentine.com>,
	Adrian Bunk <bunk@...sta.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.19-rc4: known unfixed regressions (v3)

Dave Olson <olson@...hscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | > Displaying something that might change is a fact of life, and no
> | > different than the PCI world.  It's still best to keep things as
> | > correct as possible.
> | 
> | No.  I was thinking of the rat hole in pci config space you have to
> | access to read these registers.  You have to actively write a pci
> | config value to select which register you are going to read.
> | 
> | So by default it is not safe to touch this value from user space,
> | because you could mess up the kernel, if the kernel is updating the
> | value.
>
> Nonetheless, as root, lspci already does that (it displays the MSI
> interrupt info).  I  wasn't talking about fixing that, just saying
> that having the data being as correct as possible, is highly
> desirable.   We can't know everything that everybody is doing with
> the data.

I think we are talking past each other.  I think it is fine but silly
to set a standard register that isn't actually used.  It probably makes
debugging a little easier but it might also make things a little more
confusing because we are doing something totally unnecessary.

The pci capability is fine.  The issue with the hyptertrasnport interrupt
capability is that it is 8 bytes long and controls up to 1024 bytes of data.
It is not nor can I ever it image it being safe for lspci to write the
window address register to read back the interrupt routing register.
Someone poking at this with setpci and lspci is fine.

In general reads of random registers are racy but harmless.  Writes of
registers that the kernel needs to have a specific value should never
ever be done by default, because bad nasty things may happen.  It is
a very good way to shoot yourself in the foot.

> Improvements in the pciutils library and locking with respect to the
> kernel may well be desirable, but are an independent issue from
> correctness.

This is not a race issue this is a true correctness issue.  There
is an address register and a data register.  It will never be correct
for any user space program to write to the address register without
first proving that the kernel does not care what value that register
takes on, or the user has sufficient privileges and says do it anyway
I know what I am doing.

These are not ordinary pci config space registers, although they are standard
registers for hypertransport devices.

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