From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
Ryan Wanner <ryan.wanner@microchip.com>,
David Laight <David.Laight@ACULAB.COM>,
stable <stable@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Mark Brown <broonie@kernel.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
Ronald Wahl <ronald.wahl@raritan.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] spi: atmel: Prevent spi transfers from being killed
Date: Tue, 5 Dec 2023 10:22:56 +0100 (CET) [thread overview]
Message-ID: <1788823860.72909.1701768176780.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20231205083102.16946-1-miquel.raynal@bootlin.com>
----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
> All being well, it was reported that JFFS2 was showing a splat when
> interrupting a transfer. After some more debate about whether JFFS2
> should be fixed and how, it was also pointed out that the whole
> consistency of the filesystem in case of parallel I/O would be
> compromised. Changing JFFS2 behavior would in theory be possible but
> nobody has the energy and time and knowledge to do this now, so better
> prevent spi transfers to be interrupted by the user.
Well, it's not really an JFFS2 issue.
The real problem is, that with the said change anyone can abort an IO.
Usually file systems assume that an IO can only fail in fatal situations.
That's why UBIFS, for example, switches immediately to read-only mode.
So, an unprivileged user can force UBIFS into read-only mode, which is a
local DoS attack vector.
JFFS2, on the other hand, dies a different death. If you abort one IO,
another IO path can still be active and will violate the order of written
data.
Long story short, aborting pure user inflicted IO is fine. This is the "dd"
use case.
But as soon a filesystem is on top, things get complicated.
Maybe it is possible to teach the SPI subsystem whether an IO comes from spidev
or the kernel itself?
Thanks,
//richard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-12-05 9:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 8:31 [PATCH] spi: atmel: Prevent spi transfers from being killed Miquel Raynal
2023-12-05 9:22 ` Richard Weinberger [this message]
2023-12-05 9:28 ` Miquel Raynal
2023-12-05 9:23 ` Ronald Wahl
2023-12-05 15:41 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1788823860.72909.1701768176780.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=David.Laight@ACULAB.COM \
--cc=alexandre.belloni@bootlin.com \
--cc=broonie@kernel.org \
--cc=claudiu.beznea@tuxon.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=ronald.wahl@raritan.com \
--cc=ryan.wanner@microchip.com \
--cc=stable@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox