* [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
@ 2024-10-17 22:09 Josh Poimboeuf
2024-10-18 0:33 ` Jens Axboe
2024-10-18 1:47 ` Jens Axboe
0 siblings, 2 replies; 6+ messages in thread
From: Josh Poimboeuf @ 2024-10-17 22:09 UTC (permalink / raw)
To: Phillip Potter; +Cc: linux-kernel, Jordy Zomer, Jens Axboe
The barrier_nospec() after the array bounds check is overkill and
painfully slow for arches which implement it.
Furthermore, most arches don't implement it, so they remain exposed to
Spectre v1 (which can affect pretty much any CPU with branch
prediction).
Instead, clamp the user pointer to a valid range so it's guaranteed to
be a valid array index even when the bounds check mispredicts.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
drivers/cdrom/cdrom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 9b0f37d4b9d4..6a99a459b80b 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -2313,7 +2313,7 @@ static int cdrom_ioctl_media_changed(struct cdrom_device_info *cdi,
return -EINVAL;
/* Prevent arg from speculatively bypassing the length check */
- barrier_nospec();
+ arg = array_index_nospec(arg, cdi->capacity);
info = kmalloc(sizeof(*info), GFP_KERNEL);
if (!info)
--
2.47.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
2024-10-17 22:09 [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed() Josh Poimboeuf
@ 2024-10-18 0:33 ` Jens Axboe
2024-10-18 0:52 ` Josh Poimboeuf
2024-10-18 1:47 ` Jens Axboe
1 sibling, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2024-10-18 0:33 UTC (permalink / raw)
To: Josh Poimboeuf, Phillip Potter; +Cc: linux-kernel, Jordy Zomer
On 10/17/24 4:09 PM, Josh Poimboeuf wrote:
> The barrier_nospec() after the array bounds check is overkill and
> painfully slow for arches which implement it.
>
> Furthermore, most arches don't implement it, so they remain exposed to
> Spectre v1 (which can affect pretty much any CPU with branch
> prediction).
>
> Instead, clamp the user pointer to a valid range so it's guaranteed to
> be a valid array index even when the bounds check mispredicts.
It's a cdrom, and media change detection to be more specific. I really
don't think anyone would care about performance here, it's not even
a hot path for a cdrom driver. That said, I don't disagree with
the change, just don't think it'll make one iota of difference
in the real world.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
2024-10-18 0:33 ` Jens Axboe
@ 2024-10-18 0:52 ` Josh Poimboeuf
2024-10-18 1:10 ` Jens Axboe
0 siblings, 1 reply; 6+ messages in thread
From: Josh Poimboeuf @ 2024-10-18 0:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: Phillip Potter, linux-kernel, Jordy Zomer
On Thu, Oct 17, 2024 at 06:33:24PM -0600, Jens Axboe wrote:
> On 10/17/24 4:09 PM, Josh Poimboeuf wrote:
> > The barrier_nospec() after the array bounds check is overkill and
> > painfully slow for arches which implement it.
> >
> > Furthermore, most arches don't implement it, so they remain exposed to
> > Spectre v1 (which can affect pretty much any CPU with branch
> > prediction).
> >
> > Instead, clamp the user pointer to a valid range so it's guaranteed to
> > be a valid array index even when the bounds check mispredicts.
>
> It's a cdrom, and media change detection to be more specific. I really
> don't think anyone would care about performance here, it's not even
> a hot path for a cdrom driver. That said, I don't disagree with
> the change, just don't think it'll make one iota of difference
> in the real world.
Fair, though it's also about hardening as barrier_nospec() is only
implemented by x86 and powerpc (see 2nd paragraph). Most/all arches are
affected by Spectre v1.
--
Josh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
2024-10-18 0:52 ` Josh Poimboeuf
@ 2024-10-18 1:10 ` Jens Axboe
0 siblings, 0 replies; 6+ messages in thread
From: Jens Axboe @ 2024-10-18 1:10 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Phillip Potter, linux-kernel, Jordy Zomer
On 10/17/24 6:52 PM, Josh Poimboeuf wrote:
> On Thu, Oct 17, 2024 at 06:33:24PM -0600, Jens Axboe wrote:
>> On 10/17/24 4:09 PM, Josh Poimboeuf wrote:
>>> The barrier_nospec() after the array bounds check is overkill and
>>> painfully slow for arches which implement it.
>>>
>>> Furthermore, most arches don't implement it, so they remain exposed to
>>> Spectre v1 (which can affect pretty much any CPU with branch
>>> prediction).
>>>
>>> Instead, clamp the user pointer to a valid range so it's guaranteed to
>>> be a valid array index even when the bounds check mispredicts.
>>
>> It's a cdrom, and media change detection to be more specific. I really
>> don't think anyone would care about performance here, it's not even
>> a hot path for a cdrom driver. That said, I don't disagree with
>> the change, just don't think it'll make one iota of difference
>> in the real world.
>
> Fair, though it's also about hardening as barrier_nospec() is only
> implemented by x86 and powerpc (see 2nd paragraph). Most/all arches are
> affected by Spectre v1.
Yep agree, if we don't have full arch coverage, then that's a better
reason for getting it included rather than performance reasons.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
2024-10-17 22:09 [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed() Josh Poimboeuf
2024-10-18 0:33 ` Jens Axboe
@ 2024-10-18 1:47 ` Jens Axboe
2024-10-18 10:31 ` Phillip Potter
1 sibling, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2024-10-18 1:47 UTC (permalink / raw)
To: Phillip Potter, Josh Poimboeuf; +Cc: linux-kernel, Jordy Zomer
On Thu, 17 Oct 2024 15:09:02 -0700, Josh Poimboeuf wrote:
> The barrier_nospec() after the array bounds check is overkill and
> painfully slow for arches which implement it.
>
> Furthermore, most arches don't implement it, so they remain exposed to
> Spectre v1 (which can affect pretty much any CPU with branch
> prediction).
>
> [...]
Applied, thanks!
[1/1] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
commit: b0bf1afde7c34698cf61422fa8ee60e690dc25c3
Best regards,
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
2024-10-18 1:47 ` Jens Axboe
@ 2024-10-18 10:31 ` Phillip Potter
0 siblings, 0 replies; 6+ messages in thread
From: Phillip Potter @ 2024-10-18 10:31 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel, Jordy Zomer, Josh Poimboeuf
On Thu, Oct 17, 2024 at 07:47:31PM -0600, Jens Axboe wrote:
>
> On Thu, 17 Oct 2024 15:09:02 -0700, Josh Poimboeuf wrote:
> > The barrier_nospec() after the array bounds check is overkill and
> > painfully slow for arches which implement it.
> >
> > Furthermore, most arches don't implement it, so they remain exposed to
> > Spectre v1 (which can affect pretty much any CPU with branch
> > prediction).
> >
> > [...]
>
> Applied, thanks!
>
> [1/1] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()
> commit: b0bf1afde7c34698cf61422fa8ee60e690dc25c3
>
> Best regards,
> --
> Jens Axboe
>
>
>
Sorry for lack of reply, this conversation took place in the early hours
for my timezone and thus I was unconscious :-)
Change sounds good to me for the aforementioned reasons.
Regards,
Phil
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-10-18 10:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-17 22:09 [PATCH] cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed() Josh Poimboeuf
2024-10-18 0:33 ` Jens Axboe
2024-10-18 0:52 ` Josh Poimboeuf
2024-10-18 1:10 ` Jens Axboe
2024-10-18 1:47 ` Jens Axboe
2024-10-18 10:31 ` Phillip Potter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox