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, 15 Aug 2023 09:28:54 +0800
From:   Zong Li <zong.li@...ive.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Baolu Lu <baolu.lu@...ux.intel.com>,
        Anup Patel <apatel@...tanamicro.com>,
        Tomasz Jeznach <tjeznach@...osinc.com>,
        Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>, linux@...osinc.com,
        linux-kernel@...r.kernel.org, Sebastien Boeuf <seb@...osinc.com>,
        iommu@...ts.linux.dev, Palmer Dabbelt <palmer@...belt.com>,
        Nick Kossifidis <mick@....forth.gr>,
        linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings

On Wed, Aug 9, 2023 at 10:57 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Thu, Jul 27, 2023 at 10:42:47AM +0800, Zong Li wrote:
>
> > Perhaps this question could be related to the scenarios in which
> > devices wish to be in bypass mode when the IOMMU is in translation
> > mode, and why IOMMU defines/supports this case. Currently, I could
> > envision a scenario where a device is already connected to the IOMMU
> > in hardware, but it is not functioning correctly, or there are
> > performance impacts. If modifying the hardware is not feasible, a
> > default configuration that allows bypass mode could be provided as a
> > solution. There might be other scenarios that I might have overlooked.
> > It seems to me since IOMMU supports this configuration, it would be
> > advantageous to have an approach to achieve it, and DT might be a
> > flexible way.
>
> So far we've taken the approach that broken hardware is quirked in the
> kernel by matching OF compatible string pattners. This is HW that is
> completely broken and the IOMMU doesn't work at all for it.
>
> HW that is slow or whatever is not quirked and this is an admin policy
> choice where the system should land on the security/performance
> spectrum.
>
> So I'm not sure adding DT makes sense here.
>

Hi Jason,
Sorry for being late here, I hadn't noticed this reply earlier. The
approach seems to address the situation. Could you kindly provide
information about the location of the patches? I was wondering about
further details regarding this particular implementation. Thanks

> Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ