All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: bigeasy@linutronix.de, marc.zyngier@arm.com,
	gregkh@linuxfoundation.org, yj.chiang@mediatek.com,
	peterx@redhat.com, linux-kernel@vger.kernel.org, rppt@kernel.org,
	akpm@linux-foundation.org, walken@google.com, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: mm: harden branch predictor before opening interrupts during fault
Date: Tue, 26 Jan 2021 15:29:16 +0000	[thread overview]
Message-ID: <20210126152916.GJ1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210126150150.13905-1-lecopzer.chen@mediatek.com>

On Tue, Jan 26, 2021 at 11:01:50PM +0800, Lecopzer Chen wrote:
> > On 2021-01-26 10:59:32 [+0000], Russell King - ARM Linux admin wrote:
> > > On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> > > > Hi all,
> > > > 
> > > > I don't see any fix for this issue now(maybe I missed it..?),
> > > > could we fix this if there is better solution?
> > > > This issue exists almost two years.
> > > 
> > > I don't think anyone provided an acceptable patch.
> > > 
> > > The first patch moved the hardening out of the translation/section
> > > fault handling. Since the kernel is mapped with sections, these
> > > are above TASK_SIZE, and the whole point of the branch prediction
> > > hardening is to prevent the prediction in the kernel being exploited,
> > > missing the hardening effectively makes the mitigation useless.
> > > 
> > > The discussion in February 2019 never concluded from what I can see.
> > 
> > My memory is that I never got a reply which I understood.
> > Let me try again this week with the information above.
> 
> 
> NOTE:
> Before sending this mail, I had searched the relative threads and
> there are two solutions in general:
>     1. Add get_pcpu()/put_cpu() https://lkml.org/lkml/2019/6/3/426
>        Reject by Marc:
>        > The right fix would be to move the call to a point where we haven't
>        > enabled preemption yet.
> 
>     2. Move out like the patch from Sebastian:
>        This seems follow the concept of 1.
>        (move the call to a point where we haven't enabled preemption yet).
>        But I can't find any reply in the thread.
> 
> Now the CONFIG_HARDEN_BRANCH_PREDICTOR has already backported to LTS,
> and after upgrading ARM CONFIG_CPU_V7 products to latest LTS, the
> CONFIG_HARDEN_BRANCH_PREDICTOR will be default y and this issue makes
> our devices panic and we have to either disable HARDEN_BRANCH_PREDICTOR
> or hack in-house to avoid the kernel panic.

It does _not_ cause the kernel to panic, ever. A kernel panic takes
out the system. This is not the case here.

It merely causes a noisy message to be emitted in the kernel log, and
the system survives. That is way more preferable than breaking the
effect of branch predictor hardening.

If it is taking out your kernel with a real panic, then there is
something wrong elsewhere - and this is _not_ something that should
be happening during normal system operation.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: marc.zyngier@arm.com, gregkh@linuxfoundation.org,
	bigeasy@linutronix.de, linux-kernel@vger.kernel.org,
	peterx@redhat.com, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org,
	walken@google.com, yj.chiang@mediatek.com, rppt@kernel.org
Subject: Re: [PATCH] ARM: mm: harden branch predictor before opening interrupts during fault
Date: Tue, 26 Jan 2021 15:29:16 +0000	[thread overview]
Message-ID: <20210126152916.GJ1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210126150150.13905-1-lecopzer.chen@mediatek.com>

On Tue, Jan 26, 2021 at 11:01:50PM +0800, Lecopzer Chen wrote:
> > On 2021-01-26 10:59:32 [+0000], Russell King - ARM Linux admin wrote:
> > > On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> > > > Hi all,
> > > > 
> > > > I don't see any fix for this issue now(maybe I missed it..?),
> > > > could we fix this if there is better solution?
> > > > This issue exists almost two years.
> > > 
> > > I don't think anyone provided an acceptable patch.
> > > 
> > > The first patch moved the hardening out of the translation/section
> > > fault handling. Since the kernel is mapped with sections, these
> > > are above TASK_SIZE, and the whole point of the branch prediction
> > > hardening is to prevent the prediction in the kernel being exploited,
> > > missing the hardening effectively makes the mitigation useless.
> > > 
> > > The discussion in February 2019 never concluded from what I can see.
> > 
> > My memory is that I never got a reply which I understood.
> > Let me try again this week with the information above.
> 
> 
> NOTE:
> Before sending this mail, I had searched the relative threads and
> there are two solutions in general:
>     1. Add get_pcpu()/put_cpu() https://lkml.org/lkml/2019/6/3/426
>        Reject by Marc:
>        > The right fix would be to move the call to a point where we haven't
>        > enabled preemption yet.
> 
>     2. Move out like the patch from Sebastian:
>        This seems follow the concept of 1.
>        (move the call to a point where we haven't enabled preemption yet).
>        But I can't find any reply in the thread.
> 
> Now the CONFIG_HARDEN_BRANCH_PREDICTOR has already backported to LTS,
> and after upgrading ARM CONFIG_CPU_V7 products to latest LTS, the
> CONFIG_HARDEN_BRANCH_PREDICTOR will be default y and this issue makes
> our devices panic and we have to either disable HARDEN_BRANCH_PREDICTOR
> or hack in-house to avoid the kernel panic.

It does _not_ cause the kernel to panic, ever. A kernel panic takes
out the system. This is not the case here.

It merely causes a noisy message to be emitted in the kernel log, and
the system survives. That is way more preferable than breaking the
effect of branch predictor hardening.

If it is taking out your kernel with a real panic, then there is
something wrong elsewhere - and this is _not_ something that should
be happening during normal system operation.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-26 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03  9:27 [PATCH] ARM: mm: harden branch predictor before opening interrupts during fault Lecopzer Chen
2020-12-03  9:27 ` Lecopzer Chen
2021-01-26  9:17 ` Lecopzer Chen
2021-01-26  9:17   ` Lecopzer Chen
2021-01-26 10:59   ` Russell King - ARM Linux admin
2021-01-26 10:59     ` Russell King - ARM Linux admin
2021-01-26 11:07     ` Sebastian Andrzej Siewior
2021-01-26 11:07       ` Sebastian Andrzej Siewior
2021-01-26 15:01       ` Lecopzer Chen
2021-01-26 15:01         ` Lecopzer Chen
2021-01-26 15:29         ` Russell King - ARM Linux admin [this message]
2021-01-26 15:29           ` Russell King - ARM Linux admin
2021-01-26 16:03           ` Lecopzer Chen
2021-01-26 16:03             ` Lecopzer Chen
  -- strict thread matches above, loose matches on Subject: below --
2019-03-19 20:32 Sebastian Andrzej Siewior
2019-04-15 11:08 ` Sebastian Andrzej Siewior

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=20210126152916.GJ1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=lecopzer.chen@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=peterx@redhat.com \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=walken@google.com \
    --cc=yj.chiang@mediatek.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.