On Sat, Apr 04, 2015 at 12:29:22PM +0200, Borislav Petkov wrote:
> On Sat, Apr 04, 2015 at 12:11:55PM +0200, Quentin Casasnovas wrote:
> > So I'm not claiming I've spent the time to fully understand this macro but
> > it looks like it's doing the right thing on my dummy tests:
> >
> > http://pas
On Sat, Apr 04, 2015 at 12:11:55PM +0200, Quentin Casasnovas wrote:
> So I'm not claiming I've spent the time to fully understand this macro but
> it looks like it's doing the right thing on my dummy tests:
>
> http://pastebin.com/DDhtZQgX
Cool, I'll play with it a bit when I get back.
> Did y
On Sat, Apr 04, 2015 at 11:25:36AM +0200, Borislav Petkov wrote:
> On Sat, Apr 04, 2015 at 10:36:11AM +0200, Quentin Casasnovas wrote:
> > Since all of these are compile time constants, could we not use the safe
> > variant on that same page? Not that I'm too worried about the signed right
> > shi
On Sat, Apr 04, 2015 at 10:36:11AM +0200, Quentin Casasnovas wrote:
> Since all of these are compile time constants, could we not use the safe
> variant on that same page? Not that I'm too worried about the signed right
> shift but heh that would be portable and should not impact performance
> any
On Sat, Apr 04, 2015 at 09:34:54AM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 10:42:17PM +0200, Quentin Casasnovas wrote:
> > If you're happy with the extra padding in such cases then your second
> > approach looks okay to me. But IMO, even if taking the '.if' directive
> > approach i
On Fri, Apr 03, 2015 at 10:42:17PM +0200, Quentin Casasnovas wrote:
> If you're happy with the extra padding in such cases then your second
> approach looks okay to me. But IMO, even if taking the '.if' directive
> approach is certainly bigger LOC-wise, it should be much easier to review
> in a ru
On Fri, Apr 03, 2015 at 07:48:24PM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote:
> > > Basically, the idea was:
> > >
> > > .skip len(repl1) - len(orig), 0x90
> > > .skip len(repl2) - len(repl1), 0x90
> > >
> > > BUT!, for some reason I change
On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote:
> > Basically, the idea was:
> >
> > .skip len(repl1) - len(orig), 0x90
> > .skip len(repl2) - len(repl1), 0x90
> >
> > BUT!, for some reason I changed it to what's there now and I can't
> > remember why anymore.
>
> I think it
On Fri, Apr 03, 2015 at 07:06:25PM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 05:40:55PM +0200, Quentin Casasnovas wrote:
> > So yeah I still think we're not properly padding, if you take my earlier
> > example where repl2 = 5 bytes, repl1 = 4 bytes and orin_insn = 3.
> >
> > I'll let
On Fri, Apr 03, 2015 at 05:40:55PM +0200, Quentin Casasnovas wrote:
> So yeah I still think we're not properly padding, if you take my earlier
> example where repl2 = 5 bytes, repl1 = 4 bytes and orin_insn = 3.
>
> I'll let you re-read my original mail and come back to me to tell me what'd
> I rea
On Fri, Apr 03, 2015 at 05:23:24PM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 04:14:26PM +0200, Quentin Casasnovas wrote:
> > > This is obviously completely un-tested and not even compiled! :)
> > >
> >
> > Told you!
>
> :-)
>
> So all clear or we need to do more discussing?
>
> B
On Fri, Apr 03, 2015 at 04:14:26PM +0200, Quentin Casasnovas wrote:
> > This is obviously completely un-tested and not even compiled! :)
> >
>
> Told you!
:-)
So all clear or we need to do more discussing?
Basically, the .skip is supposed to add 0x90 only when the evaluated
expression is true
On Fri, Apr 03, 2015 at 04:06:30PM +0200, Quentin Casasnovas wrote:
> On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote:
> > On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote:
> > > I've tried compiling this on top of v4.0-rc5 and I get a compile error
> > > because a
On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote:
> On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote:
> > I've tried compiling this on top of v4.0-rc5 and I get a compile error
> > because alt_end_marker isn't defined. Which other patches should I take to
> > test
On Thu, Apr 02, 2015 at 06:33:40PM +0200, Quentin Casasnovas wrote:
> I would personnaly add it to the non _booting() variants as well to make
> sure the alternative instructions _are_ applied, since otherwise that would
> probably cause random failures to restore the xsaveopt/xsaves context
> prev
On Thu, Apr 02, 2015 at 06:12:59PM +0200, Borislav Petkov wrote:
> On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote:
> > FWIW I think this looks much nicer! I have a couple of comments though,
> > apologies in advance if they aren't relevant :)
>
> No worries, I very much apprec
On Thu, Apr 02, 2015 at 05:52:10PM +0200, Quentin Casasnovas wrote:
> FWIW I think this looks much nicer! I have a couple of comments though,
> apologies in advance if they aren't relevant :)
No worries, I very much appreciate the looking at. :)
> I thought the SYSTEM_BOOTING checks were present
On Thu, Apr 02, 2015 at 03:11:22PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Previously, we did call an XSAVE/XRSTOR variant through alternatives
> and did potential exception handling resulting from the instruction
> execution in a second inline asm. Which was misleading and erro
From: Borislav Petkov
Previously, we did call an XSAVE/XRSTOR variant through alternatives
and did potential exception handling resulting from the instruction
execution in a second inline asm. Which was misleading and error prone,
see
06c8173eb92b ("x86/fpu/xsaves: Fix improper uses of __ex_ta
19 matches
Mail list logo
