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
| ||
|
Date: Wed, 6 Mar 2019 12:08:03 +0000 From: Jean-Philippe Brucker <jean-philippe.brucker@....com> To: Auger Eric <eric.auger@...hat.com>, "eric.auger.pro@...il.com" <eric.auger.pro@...il.com>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>, "joro@...tes.org" <joro@...tes.org>, "alex.williamson@...hat.com" <alex.williamson@...hat.com>, "jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>, "yi.l.liu@...ux.intel.com" <yi.l.liu@...ux.intel.com>, Will Deacon <Will.Deacon@....com>, Robin Murphy <Robin.Murphy@....com> Cc: Marc Zyngier <Marc.Zyngier@....com>, "peter.maydell@...aro.org" <peter.maydell@...aro.org>, "kevin.tian@...el.com" <kevin.tian@...el.com>, "ashok.raj@...el.com" <ashok.raj@...el.com>, Christoffer Dall <Christoffer.Dall@....com> Subject: Re: [PATCH v4 02/22] iommu: introduce device fault data On 06/03/2019 09:38, Auger Eric wrote: >>> +struct iommu_fault_unrecoverable { >>> + __u32 reason; /* enum iommu_fault_reason */ >>> +#define IOMMU_FAULT_UNRECOV_PASID_VALID (1 << 0) >>> +#define IOMMU_FAULT_UNRECOV_PERM_VALID (1 << 1) >> >> Not needed, since @perm is already a bitfield > not exactly, READ is encoded as 0. We need to differentiate read fault > from no perm provided. However if I follow your recommendation below and > transform the READ FAULT into a set bit this makes sense. Ah yes, seeing four defines I assumed read was in there. No need for INST I think, it's already described by EXEC >>> +#define IOMMU_FAULT_UNRECOV_ADDR_VALID (1 << 2) >>> +#define IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID (1 << 3) >>> + __u32 flags; >>> + __u32 pasid; >>> +#define IOMMU_FAULT_PERM_WRITE (1 << 0) /* write */ >>> +#define IOMMU_FAULT_PERM_EXEC (1 << 1) /* exec */ >>> +#define IOMMU_FAULT_PERM_PRIV (1 << 2) /* priviledged */ >> >> typo "privileged" > OK >> >>> +#define IOMMU_FAULT_PERM_INST (1 << 3) /* instruction */ >> >> Could you move these outside the struct definition? They are shared with >> the other struct. And it would be less confusing, from the device driver >> point of view, to merge those with the existing IOMMU_FAULT_* defines >> (but moving them to UAPI and making them bits) > ok I will look at this. Need to check if the read fault value is not > hardcoded anywhere. Oh right, looks like a couple of IOMMU drivers do. Hard to say if they mean READ or just "don't care", at first glance. I guess we can keep the FAULT_PERM variant until we actually unify the fault reporting API (not overly complicated since there are three users. I have patches for that buried somewhere) >> >>> + __u32 perm; >>> + __u64 addr; >>> + __u64 fetch_addr; >>> +}; >>> + >>> +/* >>> + * Page Request data (aka. recoverable fault data) >>> + * @flags : encodes whether the pasid is valid and whether this >>> + * is the last page in group >>> + * @pasid: pasid >>> + * @grpid: page request group index >>> + * @perm: requested page permissions >>> + * @addr: page address >>> + */ >>> +struct iommu_fault_page_request { >>> +#define IOMMU_FAULT_PAGE_REQUEST_PASID_PRESENT (1 << 0) >> >> PASID_VALID, to be consistent with the other set of flags? > OK >> >>> +#define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1) >>> +#define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA (1 << 2) >>> + __u32 flags; >>> + __u32 pasid; >>> + __u32 grpid; >>> + __u32 perm; >>> + __u64 addr; >> >> Given that we'll be reporting stall faults using this struct, it would >> be good to have the fetch_addr field and flag here as well. > OK >> >>> + __u64 private_data[2]; >>> +}; >>> + >>> +/** >>> + * struct iommu_fault - Generic fault data >>> + * >>> + * @type contains fault type >>> + */ >>> + >>> +struct iommu_fault { >>> + __u32 type; /* enum iommu_fault_type */ >>> + __u32 reserved; >>> + union { >>> + struct iommu_fault_unrecoverable event; >>> + struct iommu_fault_page_request prm; >> >> What's the 'm' in "prm"? Maybe just "pr"? > This stands for page request message, I think this is the Intel's naming? Looks like it's the PCI naming, let's stick with it then Thanks, Jean
Powered by blists - more mailing lists