netdev - Re: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3 buffer overflows triggered by hardware devices

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, 25 Mar 2014 09:19:03 -0700
From:	Grant Grundler <grantgrundler@...il.com>
To:	David Laight <David.Laight@...lab.com>
Cc:	Alon Nafta <alon@...vatecore.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3 buffer
 overflows triggered by hardware devices

On Tue, Mar 25, 2014 at 2:37 AM, David Laight <David.Laight@...lab.com> wrote:
> From: Alon Nafta
>> I don't think they should be trusted at all, at least not to a point
>> where it's feasible for them to execute code on your system.
>> USB drivers, filesystem drivers, peripheral drivers - they're all on
>> the same boat, obviously having different levels of severity depending
>> on driver popularity.
>
> On a large number of systems any PCI or PCIe hardware has the
> ability to read and write any system physical addresses.
> Not only does this mean that 'dodgy' hardware can change the
> kernel code, but also any attempt to restrict the memory that
> the driver itself can access is likely to be circumventable.
>
> Yes, you can raise the barrier, but there will always be low
> points on it.

David, Alon,
your points are valid but getting a bit philosophical for me.

The original patch was trying to address *abuse* of the tulip chip and
it's not clear to me that's really feasible.  I think this patch is
"safe" in the sense it enforces correct behavior and AFAICT adds no
additional CPU cost.

If we said, "rearrange the code for better readability", would you
object to the patch?

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html