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
| ||
|
Message-ID: <af04e964-28b9-4c31-a2e2-93d8410b5e8b@amd.com> Date: Fri, 29 Dec 2023 20:30:00 -0600 From: Mario Limonciello <mario.limonciello@....com> To: Takashi Sakamoto <o-takashi@...amocchi.jp>, linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org Cc: adamg@...ox.com, stable@...r.kernel.org, Jiri Slaby <jirislaby@...nel.org>, Tobias Gruetzmacher <tobias-lists@...gs> Subject: Re: [PATCH] firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards On 12/28/2023 21:57, Takashi Sakamoto wrote: > VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When > the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, > it appears that accesses to its 'Isochronous Cycle Timer' register (offset > 0xf0 on PCI I/O space) often causes unexpected system reboot in any type > of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in > the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), > or in the other OHCI 1394 hardware (e.g. Texas Instruments). > > The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: > use union for callback of transaction completion") added to v6.5 kernel. > It changed 1394 OHCI driver to access to the register every time to > dispatch local asynchronous transaction. However, the issue exists in > older version of kernel as long as it runs in AMD Ryzen machine, since > the access to the register is required to maintain bus time. It is not > hard to imagine that users experience the unexpected system reboot when > generating bus reset by plugging any devices in, or reading the register > by time-aware application programs; e.g. audio sample processing. > > Well, this commit suppresses the system reboot in the combination of > hardware. It avoids the access itself. As a result, the software stack can > not provide the hardware time anymore to unit drivers, userspace > applications, and nodes in the same IEEE 1394 bus. It brings apparent > disadvantage since time-aware application programs require it, while > time-unaware applications are available again; e.g. sbp2. > > Cc: stable@...r.kernel.org > Reported-by: Jiri Slaby <jirislaby@...nel.org> > Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 > Reported-by: Mario Limonciello <mario.limonciello@....com> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 > Reported-by: Tobias Gruetzmacher <tobias-lists@...gs> > Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ > Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 > Closes: https://bugs.launchpad.net/linux/+bug/2043905 > Signed-off-by: Takashi Sakamoto <o-takashi@...amocchi.jp> > --- > drivers/firewire/ohci.c | 49 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c > index 7e88fd489741..62af3fa39a70 100644 > --- a/drivers/firewire/ohci.c > +++ b/drivers/firewire/ohci.c > @@ -279,6 +279,8 @@ static char ohci_driver_name[] = KBUILD_MODNAME; > #define QUIRK_TI_SLLZ059 0x20 > #define QUIRK_IR_WAKE 0x40 > > +#define QUIRK_REBOOT_BY_CYCLE_TIMER_READ 0x80000000 > + > /* In case of multiple matches in ohci_quirks[], only the first one is used. */ > static const struct { > unsigned short vendor, device, revision, flags; > @@ -1724,6 +1726,11 @@ static u32 get_cycle_time(struct fw_ohci *ohci) > s32 diff01, diff12; > int i; > > +#if IS_ENABLED(CONFIG_X86) > + if (ohci->quirks & QUIRK_REBOOT_BY_CYCLE_TIMER_READ) > + return 0; > +#endif > + > c2 = reg_read(ohci, OHCI1394_IsochronousCycleTimer); > > if (ohci->quirks & QUIRK_CYCLE_TIMER) { > @@ -3527,6 +3534,45 @@ static const struct fw_card_driver ohci_driver = { > .stop_iso = ohci_stop_iso, > }; > > +// On PCI Express Root Complex in any type of AMD Ryzen machine, VIA VT6306/6307/6308 with Asmedia > +// ASM1083/1085 brings an inconvenience that read accesses to 'Isochronous Cycle Timer' register > +// (at offset 0xf0 in PCI I/O space) often causes unexpected system reboot. The mechanism is not > +// clear, since the read access to the other registers is enough safe; e.g. 'Node ID' register, > +// while it is probable due to detection of any type of PCIe error. > +#if IS_ENABLED(CONFIG_X86) > + > +#define PCI_DEVICE_ID_ASMEDIA_ASM108X 0x1080 > + > +static bool detect_vt630x_with_asm1083_on_amd_ryzen_machine(const struct pci_dev *pdev, > + struct fw_ohci *ohci) > +{ > + const struct pci_dev *pcie_to_pci_bridge; > + const struct cpuinfo_x86 *cinfo = &cpu_data(0); > + > + // Detect any type of AMD Ryzen machine. > + if (cinfo->x86_vendor != X86_VENDOR_AMD || cinfo->x86 < 0x17) > + return false; Maybe it's better to use X86_FEATURE_ZEN? > + > + // Detect VIA VT6306/6307/6308. > + if (pdev->vendor != PCI_VENDOR_ID_VIA) > + return false; > + if (pdev->device != PCI_DEVICE_ID_VIA_VT630X) > + return false; > + > + // Detect Asmedia ASM1083/1085. > + pcie_to_pci_bridge = pdev->bus->self; > + if (pcie_to_pci_bridge->vendor != PCI_VENDOR_ID_ASMEDIA) > + return false; > + if (pcie_to_pci_bridge->device != PCI_DEVICE_ID_ASMEDIA_ASM108X) > + return false; > + > + return true; > +} > + > +#else > +#define detect_vt630x_with_asm1083_on_amd_ryzen_machine(pdev) false > +#endif > + > #ifdef CONFIG_PPC_PMAC > static void pmac_ohci_on(struct pci_dev *dev) > { > @@ -3630,6 +3676,9 @@ static int pci_probe(struct pci_dev *dev, > if (param_quirks) > ohci->quirks = param_quirks; > > + if (detect_vt630x_with_asm1083_on_amd_ryzen_machine(dev, ohci)) > + ohci->quirks |= QUIRK_REBOOT_BY_CYCLE_TIMER_READ; > + > /* > * Because dma_alloc_coherent() allocates at least one page, > * we save space by using a common buffer for the AR request/
Powered by blists - more mailing lists