On Tue, Feb 9, 2021 at 10:26 AM Andy Lutomirski wrote:
> >
> > Anything else would just be insanely complicated, I feel.
>
> The other model is “don’t do that then.”
Hmm. I guess all the code that does int3 patching could just be taught
to always go to the next instruction instead.
I don't
> On Feb 9, 2021, at 10:09 AM, Linus Torvalds
> wrote:
>
> On Tue, Feb 9, 2021 at 8:55 AM Andy Lutomirski wrote:
>>
>> Or we hack up #CP to handle this case. I don’t quite know how I feel about
>> this.
>
> I think that's the sane model - if we've replaced the instruction with
> 'int3',
On Tue, Feb 9, 2021 at 8:55 AM Andy Lutomirski wrote:
>
> Or we hack up #CP to handle this case. I don’t quite know how I feel about
> this.
I think that's the sane model - if we've replaced the instruction with
'int3', and we end up getting #CP due to that, just do the #BP
handling.
Anything
> On Feb 9, 2021, at 8:45 AM, Alexei Starovoitov
> wrote:
>
> On Tue, Feb 9, 2021 at 6:49 AM Steven Rostedt wrote:
>>
>>> On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
>>> Miroslav Benes wrote:
>>>
>>> powerpc has this
>>>
>>> static inline unsigned long klp_get_ftrace_location(unsigned long
On Tue, Feb 9, 2021 at 6:49 AM Steven Rostedt wrote:
>
> On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
> Miroslav Benes wrote:
>
> > powerpc has this
> >
> > static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
> > {
> > /*
> > * Live patch works only with
On Tue, 9 Feb 2021, Steven Rostedt wrote:
> On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
> Miroslav Benes wrote:
>
> > powerpc has this
> >
> > static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
> >
> > {
On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
Miroslav Benes wrote:
> powerpc has this
>
> static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
>
> {
>
On Mon, 8 Feb 2021, Steven Rostedt wrote:
> On Mon, 8 Feb 2021 16:47:05 +0100
> Peter Zijlstra wrote:
>
> > > /*
> > > * Convert a function address into the appropriate ftrace location.
> > > *
> > > * Usually this is just the address of the function, but on some
> > > architectures
> > >
On Mon, 8 Feb 2021 16:47:05 +0100
Peter Zijlstra wrote:
> > /*
> > * Convert a function address into the appropriate ftrace location.
> > *
> > * Usually this is just the address of the function, but on some
> > architectures
> > * it's more complicated so allow them to provide a custom
On 2/7/2021 2:35 PM, Dave Hansen wrote:
On 2/7/21 12:44 PM, Alexei Starovoitov wrote:
It probably is an item on some Intel manager's to-enable list. So far,
the CET enablement concentrates only on userspace but dhansen might know
more about future plans. CCed.
It's definitely on our radar to
On Mon, Feb 08, 2021 at 09:33:00AM -0600, Josh Poimboeuf wrote:
> On Mon, Feb 08, 2021 at 10:02:06AM -0500, Steven Rostedt wrote:
> > On Sun, 7 Feb 2021 16:45:40 -0600
> > Josh Poimboeuf wrote:
> >
> > > > I do suspect involved people should start thinking about how they want
> > > > to deal
On Mon, Feb 08, 2021 at 10:02:06AM -0500, Steven Rostedt wrote:
> On Sun, 7 Feb 2021 16:45:40 -0600
> Josh Poimboeuf wrote:
>
> > > I do suspect involved people should start thinking about how they want
> > > to deal with functions starting with
> > >
> > > endbr64
> > > call
On Sun, 7 Feb 2021 16:45:40 -0600
Josh Poimboeuf wrote:
> > I do suspect involved people should start thinking about how they want
> > to deal with functions starting with
> >
> > endbr64
> > call __fentry__
> >
> > instead of the call being at the very top of the function.
>
On Sun, Feb 07, 2021 at 10:31:32AM -0800, Andy Lutomirski wrote:
>
> > On Feb 7, 2021, at 10:19 AM, Dave Hansen wrote:
> >
> > On 2/7/21 9:58 AM, Borislav Petkov wrote:
> >>> On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> >>> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov
On Sun, Feb 07, 2021 at 10:15:49AM -0800, Linus Torvalds wrote:
> On Sun, Feb 7, 2021 at 9:58 AM Borislav Petkov wrote:
> >
> > It probably is an item on some Intel manager's to-enable list. So far,
> > the CET enablement concentrates only on userspace but dhansen might know
> > more about future
On 2/7/21 12:44 PM, Alexei Starovoitov wrote:
>>> It probably is an item on some Intel manager's to-enable list. So far,
>>> the CET enablement concentrates only on userspace but dhansen might know
>>> more about future plans. CCed.
>> It's definitely on our radar to look at after CET userspace.
>
On Sun, Feb 7, 2021 at 10:21 AM Dave Hansen wrote:
>
> On 2/7/21 9:58 AM, Borislav Petkov wrote:
> > On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> >> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
> >>> - Disable CET instrumentation in the kernel so that gcc doesn't
On Sun, Feb 7, 2021 at 10:32 AM Dave Hansen wrote:
>
> My understanding is that AMD has documented support for Shadow Stacks:
>
> https://www.amd.com/system/files/TechDocs/24592.pdf
>
> But has not yet released any documentation about IBT. IBT seems to be
> Intel-only, at least in the
On 2/7/21 10:15 AM, Linus Torvalds wrote:
> On Sun, Feb 7, 2021 at 9:58 AM Borislav Petkov wrote:
>> It probably is an item on some Intel manager's to-enable list. So far,
>> the CET enablement concentrates only on userspace but dhansen might know
>> more about future plans. CCed.
> I think the
> On Feb 7, 2021, at 10:19 AM, Dave Hansen wrote:
>
> On 2/7/21 9:58 AM, Borislav Petkov wrote:
>>> On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
>>> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
- Disable CET instrumentation in the kernel so that gcc doesn't
The pull request you sent on Sun, 7 Feb 2021 11:40:22 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_urgent_for_v5.11_rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e24f9c5f6e3127a0679d5ba5575a181b80f219c9
Thank you!
--
On 2/7/21 9:58 AM, Borislav Petkov wrote:
> On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
>> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
>>> - Disable CET instrumentation in the kernel so that gcc doesn't add
>>> ENDBR64 to kernel code and thus confuse tracing.
>> So
On Sun, Feb 7, 2021 at 9:58 AM Borislav Petkov wrote:
>
> It probably is an item on some Intel manager's to-enable list. So far,
> the CET enablement concentrates only on userspace but dhansen might know
> more about future plans. CCed.
I think the new Ryzen 5000 series also supports CET, but I
On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
> >
> > - Disable CET instrumentation in the kernel so that gcc doesn't add
> > ENDBR64 to kernel code and thus confuse tracing.
>
> So this is clearly the right thing to do
On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
>
> - Disable CET instrumentation in the kernel so that gcc doesn't add
> ENDBR64 to kernel code and thus confuse tracing.
So this is clearly the right thing to do for now, but I wonder if
people have a plan for actually enabling CET and
Hi Linus,
I hope this is the last batch of x86/urgent updates for this round.
Pls pull,
thx.
---
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
26 matches
Mail list logo
