linux-kernel - Re: [PATCH v12 5/7] iommu/mediatek: Add MT8188 IOMMU Support

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]
Message-ID: <CAGXv+5E13wFUPH9yw+JeP6-=O6ta51shUGsCH1o5Pvsd5W3h2w@mail.gmail.com>
Date:   Thu, 17 Aug 2023 16:10:52 +0800
From:   Chen-Yu Tsai <wenst@...omium.org>
To:     Yong Wu (吴勇) <Yong.Wu@...iatek.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Jianjiao Zeng (曾健姣) 
        <Jianjiao.Zeng@...iatek.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "joro@...tes.org" <joro@...tes.org>,
        Chengci Xu (许承赐) 
        <Chengci.Xu@...iatek.com>,
        YF Wang (王云飞) <YF.Wang@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        Mingyuan Ma (马鸣远) 
        <Mingyuan.Ma@...iatek.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH v12 5/7] iommu/mediatek: Add MT8188 IOMMU Support

On Thu, Aug 17, 2023 at 4:03 PM Yong Wu (吴勇) <Yong.Wu@...iatek.com> wrote:
>
> On Mon, 2023-08-14 at 16:21 +0800, Chen-Yu Tsai wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >  On Mon, Aug 14, 2023 at 3:14 PM Yong Wu (吴勇) <Yong.Wu@...iatek.com>
> > wrote:
> > >
> > > On Fri, 2023-08-11 at 11:30 +0800, Chen-Yu Tsai wrote:
> > > >
> > > > External email : Please do not click links or open attachments
> > until
> > > > you have verified the sender or the content.
> > > >  On Thu, Aug 10, 2023 at 8:23 PM Yong Wu (吴勇) <
> > Yong.Wu@...iatek.com>
> > > > wrote:
> > > > >
> > > > > On Tue, 2023-08-08 at 17:53 +0800, Chen-Yu Tsai wrote:
> > > > > >
> > > > > > External email : Please do not click links or open
> > attachments
> > > > until
> > > > > > you have verified the sender or the content.
> > > > > >  On Fri, Jun 2, 2023 at 5:04 PM Yong Wu <yong.wu@...iatek.com
> > >
> > > > wrote:
> > > > > > >
> > > > > > > From: "Chengci.Xu" <chengci.xu@...iatek.com>
> > > > > > >
> > > > > > > MT8188 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo,
> > the
> > > > > > other
> > > > > > > is for vpp. and 1 INFRA IOMMU.
> > > > > > >
> > > > > > > Signed-off-by: Chengci.Xu <chengci.xu@...iatek.com>
> > > > > > > Signed-off-by: Yong Wu <yong.wu@...iatek.com>
> > > > > > > Reviewed-by: AngeloGioacchino Del Regno <
> > > > > > angelogioacchino.delregno@...labora.com>
> > > > > > > ---
> > > > > > >  drivers/iommu/mtk_iommu.c | 49
> > > > > > +++++++++++++++++++++++++++++++++++++++
> > > > > > >  1 file changed, 49 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/iommu/mtk_iommu.c
> > > > b/drivers/iommu/mtk_iommu.c
> > > > > > > index 9c89cf894a4d..5c66af0c45a8 100644
> > > > > > > --- a/drivers/iommu/mtk_iommu.c
> > > > > > > +++ b/drivers/iommu/mtk_iommu.c
> > > > > > > @@ -170,6 +170,7 @@ enum mtk_iommu_plat {
> > > > > > >         M4U_MT8173,
> > > > > > >         M4U_MT8183,
> > > > > > >         M4U_MT8186,
> > > > > > > +       M4U_MT8188,
> > > > > > >         M4U_MT8192,
> > > > > > >         M4U_MT8195,
> > > > > > >         M4U_MT8365,
> > > > > > > @@ -1593,6 +1594,51 @@ static const struct
> > mtk_iommu_plat_data
> > > > > > mt8186_data_mm = {
> > > > > > >         .iova_region_larb_msk = mt8186_larb_region_msk,
> > > > > > >  };
> > > > > > >
> > > > > > > +static const struct mtk_iommu_plat_data mt8188_data_infra
> > = {
> > > > > > > +       .m4u_plat         = M4U_MT8188,
> > > > > > > +       .flags            = WR_THROT_EN | DCM_DISABLE |
> > > > > > STD_AXI_MODE | PM_CLK_AO |
> > > > > > > +                           MTK_IOMMU_TYPE_INFRA |
> > > > > > IFA_IOMMU_PCIE_SUPPORT |
> > > > > > > +                           PGTABLE_PA_35_EN |
> > > > > > CFG_IFA_MASTER_IN_ATF,
> > > > > >
> > > > > > FWIW, CFG_IFA_MASTER_IN_ATF should not be tied to the
> > compatible
> > > > > > string,
> > > > > > but set via a DT property. The IOMMU controls are secured by
> > > > > > firmware.
> > > > > > It is not a property intrinsically tied to the hardware.
> > > > >
> > > > > The flag CFG_IFA_MASTER_IN_ATF means the registers which
> > > > enable/disable
> > > > > iommu are in the secure world. If the master like pcie want to
> > > > enable
> > > > > iommu, we have to enter secure world to configure it. It should
> > be
> > > > HW
> > > > > intrinsical, right?
> > > >
> > > > If I understand correctly, this is forced by setting some
> > registers.
> > > > The registers are set by the firmware at boot time.
> > >
> > > The register will be set before the masters that have the "iommus="
> > > property probe. If the master doesn't have "iommus=" property in
> > its
> > > dtsi node, this register won't be set, then its iommu will be
> > disabled
> > > and it has to access continuous buffer.
> > >
> > > >
> > > > So if a different firmware that doesn't set the registers is
> > used,
> > > > then the IOMMU is available to non-secure kernel, correct?
> > >
> > > No. The meaning of this register is whether to enable iommu. If the
> > > register are not set, the IOMMU for that master is disabled.
> >
> > For clarity, I'm referring to PERI_MST_PROT [1], not the registers in
> > the
> > IOMMU or LARBs. So not any of the registers used in this patch.
> >
> > If that register doesn't restrict access to IOMMU register space to
> > secure
> > only, then I assume it is controlled by fuses?
>
> Thanks for the clarification. Understand this now. If that register
> doesn't restrict this, the register for enabling the iommu could be
> accessed in normal world.
>
> > [1]
> > https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/be457248c6b0a7f3c61bd95af58372938d13decd/plat/mediatek/drivers/iommu/mt8188/mtk_iommu_plat.c#93
> >
> > > >
> > > > That's why I said that it should not be tied to a particular
> > hardware
> > > > platform, but set using a boolean device tree property.
> > > >
> > > > > >
> > > > > > If on some other project there is no such security
> > requirement
> > > > and
> > > > > > the
> > > > > > IOMMU is opened up to non-secure world, and ATF not even
> > having
> > > > > > support
> > > > > > for the SMC call, this becomes unusable and hard to rectify
> > > > without
> > > > > > introducing a new compatible string.
>
> Then this make sense. Sorry, I don't know if such project exist, I
> guess no, right? we could add it when necessary?

I guess that works. It would be a negative property, such as
"mediatek,iommu-is-non-secure". However, since this lock down is orthogonal
to the SoC model, it would be better to model it as such from the beginning.

ChenYu