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: <YgowAl01rq5A8Sil@google.com> Date: Mon, 14 Feb 2022 10:33:38 +0000 From: Lee Jones <lee.jones@...aro.org> To: Matthew Wilcox <willy@...radead.org> Cc: "Darrick J. Wong" <djwong@...nel.org>, linux-kernel@...r.kernel.org, Stable <stable@...r.kernel.org>, Christoph Hellwig <hch@....de>, Dave Chinner <dchinner@...hat.com>, Goldwyn Rodrigues <rgoldwyn@...e.com>, "Darrick J . Wong" <darrick.wong@...cle.com>, Bob Peterson <rpeterso@...hat.com>, Damien Le Moal <damien.lemoal@....com>, Theodore Ts'o <tytso@....edu>, Andreas Gruenbacher <agruenba@...hat.com>, Ritesh Harjani <riteshh@...ux.ibm.com>, Johannes Thumshirn <jth@...nel.org>, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, cluster-devel@...hat.com, syzbot+0ed9f769264276638893@...kaller.appspotmail.com Subject: Re: [PATCH 1/1] Revert "iomap: fall back to buffered writes for invalidation failures" Let's attempt to seek beyond the mud slinging, swearing and the whiny amateur dramatics for just a brief moment and concentrate solely on the technicals please. On Fri, 11 Feb 2022, Matthew Wilcox wrote: > On Thu, Feb 10, 2022 at 10:15:52AM +0000, Lee Jones wrote: > > On Wed, 09 Feb 2022, Darrick J. Wong wrote: > > > > > On Wed, Feb 09, 2022 at 08:52:43AM +0000, Lee Jones wrote: > > > > This reverts commit 60263d5889e6dc5987dc51b801be4955ff2e4aa7. > > > > > > > > Reverting since this commit opens a potential avenue for abuse. > > > > > > What kind of abuse? Did you conclude there's an avenue solely because > > > some combination of userspace rigging produced a BUG warning? Or is > > > this a real problem that someone found? > > > > Genuine question: Is the ability for userspace to crash the kernel > > not enough to cause concern? I would have thought that we'd want to > > prevent this. > > The kernel doesn't crash. It's a BUG(). That means it kills the > task which caused the BUG(). If you've specified that the kernel should > crash on seeing a BUG(), well, you made that decision, and you get to > live with the consequences. BUG() calls are architecture specific. If no override is provided, the default appears to panic ("crash") the kernel: /* * Don't use BUG() or BUG_ON() unless there's really no way out; one * example might be detecting data structure corruption in the middle * of an operation that can't be backed out of. If the (sub)system * can somehow continue operating, perhaps with reduced functionality, * it's probably not BUG-worthy. * * If you're tempted to BUG(), think again: is completely giving up * really the *only* solution? There are usually better options, where * users don't need to reboot ASAP and can mostly shut down cleanly. */ #ifndef HAVE_ARCH_BUG #define BUG() do { \ printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \ barrier_before_unreachable(); \ panic("BUG!"); \ } while (0) #endif The kernel I tested with panics and reboots: Kernel panic - not syncing: Fatal exception Here are the BUG related kernel configs I have set: CONFIG_BUG=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y # CONFIG_INPUT_EVBUG is not set CONFIG_BUG_ON_DATA_CORRUPTION=y Not seeing a "CONFIG_PANIC_ON_BUG" equivalent. What is missing? Unless of course you mean disabling BUG support entirely. In which case, this is strongly advised against in the help section and I'm not sure of many development or production kernels that do this. config BUG bool "BUG() support" if EXPERT default y help Disabling this option eliminates support for BUG and WARN, reducing the size of your kernel image and potentially quietly ignoring numerous fatal conditions. You should only consider disabling this option for embedded systems with no facilities for reporting errors. Just say Y. I've always been under the impression that a BUG() call should never be triggerable from userspace. However, I'm always happy to be incorrect and subsequently reeducated. In other words ... Is this a valid issue that you want me to report (in a different way): > Start again, write a good bug report in a new thread. Or is this expected behaviour and therefore not a concern: > > > The BUG report came from page_buffers failing to find any buffer heads > > > attached to the page. > > > > > Yeah, don't care. -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Powered by blists - more mailing lists