On Thu, Feb 9, 2017 at 2:27 AM, Peter Zijlstra wrote:
> On Wed, Feb 08, 2017 at 01:20:26PM -0800, Kees Cook wrote:
>
>> Ooooh, that is intense. And the trampolines (EX_REG_HANDLERs) are all
>> just there to catch whatever register gcc decides to stuff the value
>> into? *cover face* Sure, okay. :)
On Wed, Feb 08, 2017 at 01:20:26PM -0800, Kees Cook wrote:
> Ooooh, that is intense. And the trampolines (EX_REG_HANDLERs) are all
> just there to catch whatever register gcc decides to stuff the value
> into? *cover face* Sure, okay. :)
Right, they shouldn't be big functions, but barring whole p
On Wed, Feb 8, 2017 at 1:12 AM, Peter Zijlstra wrote:
> On Tue, Feb 07, 2017 at 05:55:42PM +, Mark Rutland wrote:
>> On Tue, Feb 07, 2017 at 06:30:36PM +0100, Peter Zijlstra wrote:
>> > On Tue, Feb 07, 2017 at 04:03:01PM +, Mark Rutland wrote:
>> > > For x86 it's a little painful due to '%
On Wed, Feb 08, 2017 at 10:12:50AM +0100, Peter Zijlstra wrote:
> On x86 have have __ex_table and __bug_table. The former is used for all
> sorts of things, including fixing up faults.
>
> Now, our struct exception_table_entry has a third field used to specify
> a handler, see commit:
>
> 548acf
On Wed, Feb 08, 2017 at 10:12:50AM +0100, Peter Zijlstra wrote:
> Something like:
>
> #define EX_REG_HANDLER(_reg) \
> bool ex_handler_value_##_reg(const struct exception_table_entry *fixup, \
> struct pt_regs *regs, int trapnr) \
> {
On Tue, Feb 07, 2017 at 05:55:42PM +, Mark Rutland wrote:
> On Tue, Feb 07, 2017 at 06:30:36PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 07, 2017 at 04:03:01PM +, Mark Rutland wrote:
> > > For x86 it's a little painful due to '%' in the register names, but it
> > > looks
> > > possible.
On Tue, Feb 07, 2017 at 06:30:36PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 07, 2017 at 04:03:01PM +, Mark Rutland wrote:
> > For x86 it's a little painful due to '%' in the register names, but it looks
> > possible. The below appears to do the mangling correctly (then screams due
> > to
> >
On Tue, Feb 07, 2017 at 04:03:01PM +, Mark Rutland wrote:
> For x86 it's a little painful due to '%' in the register names, but it looks
> possible. The below appears to do the mangling correctly (then screams due to
> the mangled result being nonexistent).
> asm(
> " .macro reg_to_offset
On Tue, Feb 07, 2017 at 04:07:37PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 07, 2017 at 01:50:20PM +, Mark Rutland wrote:
> > > Right something along those lines. (a) will need GCC help, and (b) would
> > > be kernel-arch specific. So this isn't something we can quickly do.
> >
> > I agree t
On Tue, Feb 07, 2017 at 01:50:20PM +, Mark Rutland wrote:
> > Right something along those lines. (a) will need GCC help, and (b) would
> > be kernel-arch specific. So this isn't something we can quickly do.
>
> I agree this isn't something that can be hacked together quickly, and
> certainly s
On Tue, Feb 07, 2017 at 01:36:30PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 07, 2017 at 11:10:12AM +, Mark Rutland wrote:
> > On Tue, Feb 07, 2017 at 09:34:05AM +0100, Peter Zijlstra wrote:
> > > On Mon, Feb 06, 2017 at 08:54:38AM -0800, Kees Cook wrote:
> > > > >
> > > > > Like I wrote, idea
On Tue, Feb 07, 2017 at 11:10:12AM +, Mark Rutland wrote:
> On Tue, Feb 07, 2017 at 09:34:05AM +0100, Peter Zijlstra wrote:
> > On Mon, Feb 06, 2017 at 08:54:38AM -0800, Kees Cook wrote:
> > > >
> > > > Like I wrote, ideally we'd end up using something like the x86 exception
> > > > table with
On Tue, Feb 07, 2017 at 09:34:05AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 06, 2017 at 08:54:38AM -0800, Kees Cook wrote:
> > >
> > > Like I wrote, ideally we'd end up using something like the x86 exception
> > > table with a custom handler. Just no idea how to pull that off without
> > > doing
On Mon, Feb 06, 2017 at 08:54:38AM -0800, Kees Cook wrote:
> >
> > Like I wrote, ideally we'd end up using something like the x86 exception
> > table with a custom handler. Just no idea how to pull that off without
> > doing a full blown arch specific implementation, so I didn't go there
> > quite
On Mon, Feb 6, 2017 at 12:57 AM, Peter Zijlstra wrote:
> On Sun, Feb 05, 2017 at 03:33:36PM -0800, Kees Cook wrote:
>> On Sun, Feb 5, 2017 at 7:40 AM, Peter Zijlstra wrote:
>> > On Fri, Feb 03, 2017 at 03:26:52PM -0800, Kees Cook wrote:
>> >> This converts from WARN_ON() to CHECK_DATA_CORRUPTION(
On Sun, Feb 05, 2017 at 03:33:36PM -0800, Kees Cook wrote:
> On Sun, Feb 5, 2017 at 7:40 AM, Peter Zijlstra wrote:
> > On Fri, Feb 03, 2017 at 03:26:52PM -0800, Kees Cook wrote:
> >> This converts from WARN_ON() to CHECK_DATA_CORRUPTION() in the
> >> CONFIG_DEBUG_REFCOUNT case. Additionally moves
On Sun, Feb 5, 2017 at 7:40 AM, Peter Zijlstra wrote:
> On Fri, Feb 03, 2017 at 03:26:52PM -0800, Kees Cook wrote:
>> This converts from WARN_ON() to CHECK_DATA_CORRUPTION() in the
>> CONFIG_DEBUG_REFCOUNT case. Additionally moves refcount_t sanity check
>> conditionals into regular function flow.
On Fri, Feb 03, 2017 at 03:26:52PM -0800, Kees Cook wrote:
> This converts from WARN_ON() to CHECK_DATA_CORRUPTION() in the
> CONFIG_DEBUG_REFCOUNT case. Additionally moves refcount_t sanity check
> conditionals into regular function flow. Since CHECK_DATA_CORRUPTION()
> is marked __much_check, we
This converts from WARN_ON() to CHECK_DATA_CORRUPTION() in the
CONFIG_DEBUG_REFCOUNT case. Additionally moves refcount_t sanity check
conditionals into regular function flow. Since CHECK_DATA_CORRUPTION()
is marked __much_check, we override few cases where the failure has
already been handled but w
19 matches
Mail list logo
