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


Groups > linux.kernel > #1298318

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

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
Date 2015-12-27 03:20 +0100
Message-ID <qK96a-F3-3@gated-at.bofh.it> (permalink)
References (2 earlier) <qJzcm-33x-3@gated-at.bofh.it> <qJGQx-84B-1@gated-at.bofh.it> <qJUqt-8ap-7@gated-at.bofh.it> <qJYu6-2cC-21@gated-at.bofh.it> <qK8Wu-BU-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck <tony.luck@gmail.com> wrote:
> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" <bp@alien8.de> wrote:
>>> Andy, why is that? It makes the exception handling much simpler this way...
>>>
>>
>> I like the idea of moving more logic into C, but I don't like
>> splitting the logic across files and adding nasty special cases like
>> this.
>>
>> But what if we generalized it?  An extable entry gives a fault IP and
>> a landing pad IP.  Surely we can squeeze a flag bit in there.
>
> The clever squeezers have already been here. Instead of a pair
> of 64-bit values for fault_ip and fixup_ip they managed with a pair
> of 32-bit values that are each the relative offset of the desired address
> from the table location itself.
>
> 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.
>
> Or we could direct the new fixups into a .fixup2 ELF section and put
> begin/end labels around that ... so we could check the address of the
> fixup to see whether it is a legacy or new format entry.
>

Either of those sounds good to me.

>> set the bit, you get an extended extable entry.  Instead of storing a
>> landing pad, it stores a pointer to a handler descriptor:
>>
>> struct extable_handler {
>>   bool (*handler)(struct pt_regs *, struct extable_handler *, ...):
>> };
>>
>> handler returns true if it handled the error and false if it didn't.
>
> It may be had to call that from the machine check handler ... the
> beauty of just patching the IP and returning from the handler was
> that it got us out of machine check context.

Your handler will need to know that it's in machine check context :)
In most cases (e.g. yours), the handler should just modify regs and
return.

>
>> The "..." encodes the fault number, error code, cr2, etc.  Maybe it
>> would be "unsigned long exception, const struct extable_info *info"
>> where extable_info contains a union?  I really wish C would grow up
>> and learn about union types.
>
> All this is made more difficult because the h/w doesn't give us
> all the things we might want to know (e.g. the virtual address).
> We just have a physical address (which may be missing some
> low order bits).

True.  I'm afraid that nothing I suggest can possibly help you there.

Anyhow, this could be a decent signature:

bool (*handler)(struct pt_regs *, struct extable_handler *, unsigned
int exception, unsigned long error_code, unsigned long extra):

If exception is X86_TRAP_PF, then extra is CR2.  If exception is
X86_TRAP_MC, then extra is however much of the PA you know.

--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/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[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

csiph-web