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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

Hi David,

Are you referring to (older) systems without IOMMU? Since IOMMU and
VT-d (for Intel) exactly solve that security problem.

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