Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1298045 > unrolled thread

[PATCHV4 0/3] Machine check recovery when kernel accesses poison

Back to article view | Back to linux.kernel

Contents

  [PATCHV4 0/3] Machine check recovery when kernel accesses poison Tony Luck <tony.luck@intel.com> - 2015-12-24 22:10 +0100
    [PATCHV4 2/3] x86, ras: Extend machine check recovery code to annotated  ring0 areas Tony Luck <tony.luck@intel.com> - 2015-12-24 22:20 +0100
    [PATCHV4 1/3] x86, ras: Add new infrastructure for machine check fixup  tables Tony Luck <tony.luck@intel.com> - 2015-12-24 22:20 +0100
    [PATCHV4 3/3] x86, ras: Add __mcsafe_copy() function to recover from  machine checks Tony Luck <tony.luck@intel.com> - 2015-12-24 22:20 +0100
      Re: [PATCHV4 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-24 22:50 +0100
        [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from  machine checks Tony Luck <tony.luck@intel.com> - 2015-12-25 01:20 +0100
          Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-25 13:00 +0100
            Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks "Luck, Tony" <tony.luck@intel.com> - 2015-12-25 21:10 +0100
              Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-26 11:40 +0100
                Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-26 16:00 +0100
                  Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Tony Luck <tony.luck@gmail.com> - 2015-12-27 03:10 +0100
                    Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 03:20 +0100
                      Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 03:20 +0100
                        Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Tony Luck <tony.luck@gmail.com> - 2015-12-27 08:00 +0100
                          Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-27 11:20 +0100
                            Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 13:30 +0100
                              Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks Boris Petkov <bp@alien8.de> - 2015-12-27 14:30 +0100
                                Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 14:30 +0100
                                  Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-27 14:40 +0100
                                    Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 14:50 +0100
                                    Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Dan Williams <dan.j.williams@intel.com> - 2015-12-28 03:50 +0100
                          Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-27 13:20 +0100
                            Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Tony Luck <tony.luck@gmail.com> - 2015-12-31 00:40 +0100
                              Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Tony Luck <tony.luck@gmail.com> - 2015-12-31 21:40 +0100
                                Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2015-12-31 22:30 +0100
                                Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Tony Luck <tony.luck@gmail.com> - 2016-01-01 23:30 +0100
                                  Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover  from machine checks Andy Lutomirski <luto@amacapital.net> - 2016-01-03 04:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1298498 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Sun, Dec 27, 2015 at 5:33 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Sun, Dec 27, 2015 at 05:25:45AM -0800, Andy Lutomirski wrote:
>> That could significantly bloat the kernel image.
>
> Yeah, we probably should build an allyesconfig and see how big
> __ex_table is and compute how much actually that bloat would be,
> because...
>
>> Anyway, the bit 31 game isn't so bad IMO because it's localized to the
>> extable macros and the extable reader, whereas the bit 63 thing is all
>> tangled up with the __mcsafe_copy thing, and that's just the first
>> user of a more general mechanism.
>>
>> Did you see this:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=strict_uaccess_fixups/patch_v1&id=16644d9460fc6531456cf510d5efc57f89e5cd34
>
> ... the problem this has is that you have 4 classes, AFAICT. And since
> we're talking about a generic mechanism, the moment the 4 classes are
> not enough, this new scheme fails.
>
> I'm just saying...
>
> 4 classes are probably more than enough but we don't know.

Then we add support for more than 4 when/if the time comes...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298362 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Sat, Dec 26, 2015 at 10:57 PM, Tony Luck <tony.luck@gmail.com> wrote:
> On Sat, Dec 26, 2015 at 6:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> We could make one of them 31-bits (since even an "allyesconfig" kernel
>>>> is still much smaller than a gigabyte) to free a bit for a flag. But there
>>>> are those external tools to pre-sort exception tables that would all
>>>> need to be fixed too.
>>
>> Wait, why?  The external tools sort by source address, and we'd
>> squeeze the flag into the target address, no?
>
> I was thinking that we'd need to recompute the fixup when we move
> the entry to its new sorted location. So that:
>
>  ex_fixup_addr(const struct exception_table_entry *x)
>  {
>           return (unsigned long)&x->fixup + x->fixup;
>  }
>
> will get the right value.  Maybe this would still work out
> if the fixup is a 31-bit value plus a flag, but the external
> tool thinks it is a 32-bit value?  I'd have to ponder that.

I think I can save you some pondering.  This old patch gives two flag
bits.  Feel free to borrow the patch, but you'll probably want to
change the _EXTABLE_CLASS_XYZ macros:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=strict_uaccess_fixups/patch_v1&id=16644d9460fc6531456cf510d5efc57f89e5cd34

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299540 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Sun, Dec 27, 2015 at 4:18 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> I think I can save you some pondering.  This old patch gives two flag
> bits.  Feel free to borrow the patch, but you'll probably want to
> change the _EXTABLE_CLASS_XYZ macros:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=strict_uaccess_fixups/patch_v1&id=16644d9460fc6531456cf510d5efc57f89e5cd34

Thanks!

I took that, and some of Boris's changes, and stirred it altogether at:

git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git mcsafev6

First commit is just your patch from above (patch wouldn't apply it
directly because of other nearby changes, but I think I didn't break
it)

Second commit pulls the core of fixup_exception() into separate
functions for each class

Third adds a new class that provides the fault number to the fixup
code in regs->ax.

Fourth is just a jumble of the rest .. needs to be split into two
parts (one for machine check handler, second to add __mcsafe_copy())

Fifth is just a hack because I clearly didn't understand what I was
doing in parts 2&3 because my new class shows up as '3' not '1'!

Andy: Can you explain the assembler/linker arithmetic for the class?

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299776 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Wed, Dec 30, 2015 at 3:32 PM, Tony Luck <tony.luck@gmail.com> wrote:
> Fifth is just a hack because I clearly didn't understand what I was
> doing in parts 2&3 because my new class shows up as '3' not '1'!
>
> Andy: Can you explain the assembler/linker arithmetic for the class?

Never mind ... figured it out.

The fixup entry in the extable is:

label - . + 0x2000000 - BIAS

The "label - ." part evaluates to a smallish negative value (because
the .fixup section is bundled in towards the end of .text, and the
ex_table section comes right after.

Then you add 0x20000000 to get a positive number, then *subtract*
the BIAS.  I'd picked BIAS = 0x40000000 thinking that would show
up directly in class bits. But 0x1ffff000 - 0x40000000 is 0xdffff000
so bits 31 & 31 are both set, and this is class3

I switched to BIAS 0xC0000000 ... and now I get class 1 entries
(bit31=0, bit30=1).

New patch series coming soon.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299781 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Jan 1, 2016 4:30 AM, "Tony Luck" <tony.luck@gmail.com> wrote:
>
> On Wed, Dec 30, 2015 at 3:32 PM, Tony Luck <tony.luck@gmail.com> wrote:
> > Fifth is just a hack because I clearly didn't understand what I was
> > doing in parts 2&3 because my new class shows up as '3' not '1'!
> >
> > Andy: Can you explain the assembler/linker arithmetic for the class?
>
> Never mind ... figured it out.
>
> The fixup entry in the extable is:
>
> label - . + 0x2000000 - BIAS
>
> The "label - ." part evaluates to a smallish negative value (because
> the .fixup section is bundled in towards the end of .text, and the
> ex_table section comes right after.
>
> Then you add 0x20000000 to get a positive number, then *subtract*
> the BIAS.  I'd picked BIAS = 0x40000000 thinking that would show
> up directly in class bits. But 0x1ffff000 - 0x40000000 is 0xdffff000
> so bits 31 & 31 are both set, and this is class3
>
> I switched to BIAS 0xC0000000 ... and now I get class 1 entries
> (bit31=0, bit30=1).
>
> New patch series coming soon.

That all sounds correct.

You could also just to s/UACCESS/INDIRECT/ or whatever and leave using
the next bit for whoever does the uaccess part, too.  After all,
introducing the "uaccess" class without actually implementing it isn't
very useful.

>
> -Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300002 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

Somehow this didn't get sent ... found it in the "Drafts" folder.  But
it's rubbish, skip to the
bottom.

On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck <tony.luck@gmail.com> wrote:
> I switched to BIAS 0xC0000000 ... and now I should get class 1 entries
> (bit31=0, bit30=1).
>
> New patch series coming soon.

Or not :-(

arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0x4): relocation truncated
to fit: R_X86_64_PC32 against `.fixup'
arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0xc): relocation truncated
to fit: R_X86_64_PC32 against `.fixup'
...

I guess it was something like this that made you do the 0x20000000 and
subtract the BIAS?

I have a bad feeling that we may not really have four classes, just three:

00: no funny arithmetic
10: BIAS = 0x80000000 ... doesn't trigger truncation warning because
sign bit is set
11: BIAS = 0x40000000 ... ditto
01: BIAS = ? ... Is there some magic value for BIAS that gets this?

--- end of Draft ... now to the real bit

Not sure why I was hung up on *subtracting* values to get the desired
class bits. Just
blindly copying the initial case from your patch?

If you can't get from A to B one way, try going around the other
direction. Subtracting
0xC0000000 is the same as adding 0x40000000 (when playing with u32 values).
That doesn't upset the linker.

I rebased:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git mcsafev6

still needs a little cleanup, but it all works, and seems to be a much
cleaner approach.  So clean that I wonder whether I really need
the CONFIG_MCE_KERNEL_RECOVERY any more?? The only
place it is used now is around the __mcsafe_copy()

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300169 — Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

On Fri, Jan 1, 2016 at 2:19 PM, Tony Luck <tony.luck@gmail.com> wrote:
> Somehow this didn't get sent ... found it in the "Drafts" folder.  But
> it's rubbish, skip to the
> bottom.
>
> On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck <tony.luck@gmail.com> wrote:
>> I switched to BIAS 0xC0000000 ... and now I should get class 1 entries
>> (bit31=0, bit30=1).
>>
>> New patch series coming soon.
>
> Or not :-(
>
> arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0x4): relocation truncated
> to fit: R_X86_64_PC32 against `.fixup'
> arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0xc): relocation truncated
> to fit: R_X86_64_PC32 against `.fixup'
> ...
>
> I guess it was something like this that made you do the 0x20000000 and
> subtract the BIAS?
>
> I have a bad feeling that we may not really have four classes, just three:
>
> 00: no funny arithmetic
> 10: BIAS = 0x80000000 ... doesn't trigger truncation warning because
> sign bit is set
> 11: BIAS = 0x40000000 ... ditto
> 01: BIAS = ? ... Is there some magic value for BIAS that gets this?
>
> --- end of Draft ... now to the real bit
>
> Not sure why I was hung up on *subtracting* values to get the desired
> class bits. Just
> blindly copying the initial case from your patch?
>
> If you can't get from A to B one way, try going around the other
> direction. Subtracting
> 0xC0000000 is the same as adding 0x40000000 (when playing with u32 values).
> That doesn't upset the linker.
>
> I rebased:
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git mcsafev6
>
> still needs a little cleanup, but it all works, and seems to be a much
> cleaner approach.  So clean that I wonder whether I really need
> the CONFIG_MCE_KERNEL_RECOVERY any more?? The only
> place it is used now is around the __mcsafe_copy()
>

Looks nice!

It might a bit clearer if you rename fix_class2 to fix_class_ex, etc,
and then use the C99 syntax for the table:

allclasses ... = {
  [EXTABLE_CLASS_WHATEVER >> 30] = fix_class_whatever,
  ...
};

you could try "[extable_class(EXTABLE_CLASS_WHATEVER)] = fix_class_whatever"

Maybe rename EXTABLE_CLASS_FAULT to EXTABLE_CLASS_FAULT_OR_MC?

I might still attack this code later to add the indirect fixup idea
rather than just returning the fault number in EAX.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web