All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	 Ryan Wanner <ryan.wanner@microchip.com>,
	 Ronald Wahl <ronald.wahl@raritan.com>,
	 David Laight <David.Laight@ACULAB.COM>,
	 Nicolas Ferre <nicolas.ferre@microchip.com>,
	 Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	 Alexandre Belloni <alexandre.belloni@bootlin.com>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 stable <stable@vger.kernel.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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2023-12-05  9:23 UTC|newest]

Thread overview: 10+ 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  8:31 ` Miquel Raynal
2023-12-05  9:22 ` Richard Weinberger [this message]
2023-12-05  9:22   ` Richard Weinberger
2023-12-05  9:28   ` Miquel Raynal
2023-12-05  9:28     ` Miquel Raynal
2023-12-05  9:23 ` Ronald Wahl
2023-12-05  9:23   ` Ronald Wahl
2023-12-05 15:41 ` Mark Brown
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=nicolas.ferre@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.