[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1bcda5b25b1f37d@bloch.sibelius.xs4all.nl>
Date: Fri, 26 Mar 2021 22:13:35 +0100 (CET)
From: Mark Kettenis <mark.kettenis@...all.nl>
To: Arnd Bergmann <arnd@...nel.org>
Cc: sven@...npeter.dev, robh@...nel.org,
iommu@...ts.linux-foundation.org, joro@...tes.org, will@...nel.org,
robin.murphy@....com, marcan@...can.st, maz@...nel.org,
mohamed.mediouni@...amail.com, stan@...ellium.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
> From: Arnd Bergmann <arnd@...nel.org>
> Date: Fri, 26 Mar 2021 21:03:32 +0100
>
> On Fri, Mar 26, 2021 at 6:28 PM Mark Kettenis <mark.kettenis@...all.nl> wrote:
>
> > I haven't figured out how the bypass stuff really works. Corellium
> > added support for it in their codebase when they added support for
> > Thunderbolt, and some of the DARTs that seem to be related to
> > Thunderbolt do indeed have a "bypass" property. But it is unclear to
> > me how the different puzzle pieces fit together for Thunderbolt.
>
> As a general observation, bypass mode for Thunderbolt is what enabled
> the http://thunderclap.io/ attack. This is extremely useful for debugging
> a running kernel from another machine, but it's also something that
> should never be done in a production kernel.
No kidding! I was surprised to see the bypass support on the
Thunderbolt-related nodes.
Powered by blists - more mailing lists