[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP6odjh5qgh2dcURHrQ6ERn6a4TfCgBXPm3eJmw2ZsAKyzEzvQ@mail.gmail.com>
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
Powered by blists - more mailing lists