On February 25, 2017 11:38:44 AM PST, Borislav Petkov wrote:
>On Sat, Feb 25, 2017 at 09:55:45AM -0800, h...@zytor.com wrote:
>> You mean like the INT instruction?
>
>Right, you mentioned reusing INT $9 upthread.
>
>That doesn't have the additional info in the immed8 - it is the vector
>in this ca
On Sat, Feb 25, 2017 at 12:04:18PM -0800, h...@zytor.com wrote:
> Note that once you have a trap you can create an immediate yourself,
> the CPU doesn't need to do it for you, unless you really care about
> latency (reading the instruction steam can be kind of expensive,
> although it is quite a bi
On Sat, Feb 25, 2017 at 09:55:45AM -0800, h...@zytor.com wrote:
> You mean like the INT instruction?
Right, you mentioned reusing INT $9 upthread.
That doesn't have the additional info in the immed8 - it is the vector
in this case. But that's not really important for our usage.
In any case, the
On February 25, 2017 2:38:08 AM PST, Borislav Petkov wrote:
>On Fri, Feb 24, 2017 at 11:41:33AM +0100, Peter Zijlstra wrote:
>> So yes, its tricky but it could be done. A new single byte #UD
>> instruction would be much nicer though.
>
>Btw, if we did a new insn which means new functionality inste
On Fri, Feb 24, 2017 at 11:41:33AM +0100, Peter Zijlstra wrote:
> So yes, its tricky but it could be done. A new single byte #UD
> instruction would be much nicer though.
Btw, if we did a new insn which means new functionality instead of
"stealing" an invalid one, we would have to have a fallback
On Fri, Feb 24, 2017 at 01:53:27AM -0800, H. Peter Anvin wrote:
> On 02/24/17 01:15, Ingo Molnar wrote:
> >
> > * h...@zytor.com wrote:
> >
> >> Incidentally, as an alternative to a #UD, int $9 could be an alternative
> >> (exception vector 9 was discontinued with the 486.)
> >
> > With thousa
On 02/24/17 01:46, Borislav Petkov wrote:
> On Fri, Feb 24, 2017 at 10:15:37AM +0100, Ingo Molnar wrote:
>> With thousands of call sites a one byte opcode would be preferred, that's
>> why INT3
>> is so nice.
>
> ICEBP is also a single-byte: F1. And should be pretty unused :)
>
That would make
On Fri, Feb 24, 2017 at 10:15:37AM +0100, Ingo Molnar wrote:
> With thousands of call sites a one byte opcode would be preferred, that's why
> INT3
> is so nice.
ICEBP is also a single-byte: F1. And should be pretty unused :)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
On February 24, 2017 12:31:15 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
>> The only high level question is whether we trust the trap machinery
>to generate
>> WARN_ON()s. I believe we do.
>>
>> BTW.: why not use INT3 instead of all these weird #
* h...@zytor.com wrote:
> Incidentally, as an alternative to a #UD, int $9 could be an alternative
> (exception vector 9 was discontinued with the 486.)
With thousands of call sites a one byte opcode would be preferred, that's why
INT3
is so nice.
Thanks,
Ingo
On February 24, 2017 12:31:15 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
>> The only high level question is whether we trust the trap machinery
>to generate
>> WARN_ON()s. I believe we do.
>>
>> BTW.: why not use INT3 instead of all these weird #
On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
> The only high level question is whether we trust the trap machinery to
> generate
> WARN_ON()s. I believe we do.
>
> BTW.: why not use INT3 instead of all these weird #UD opcodes? It's a single
> byte
> opcode and we can do a quick
* Peter Zijlstra wrote:
> 0016 :
> 16: 55 push %rbp
> 17: 8b 16 mov(%rsi),%edx
> 19: 41 83 c8 ff or $0x,%r8d
> 1d: 48 89 e5mov%rsp,%rbp
> 20: 85 d2 test %e
On Thu, Feb 23, 2017 at 07:32:07AM -0800, h...@zytor.com wrote:
> Well, once you are using invalid instructions, it depends not on
> what the CPU decodes but what your own handler expects. Consider
> Microsoft's use of C4 C4 /ib as a meta-instruction (called BOP, "BIOS
> operation")... that format
On February 23, 2017 7:23:09 AM PST, Peter Zijlstra
wrote:
>On Thu, Feb 23, 2017 at 07:09:05AM -0800, h...@zytor.com wrote:
>> Well, it only matters if the instruction extends past a segment
>> boundary or page. However, the CPU instruction decoder will consume
>a
>> modrm for UD1, and so using
On Thu, Feb 23, 2017 at 07:09:05AM -0800, h...@zytor.com wrote:
> Well, it only matters if the instruction extends past a segment
> boundary or page. However, the CPU instruction decoder will consume a
> modrm for UD1, and so using just the two opcode bytes may cause a #PF
> or #GP when a #UD was
On February 23, 2017 6:09:29 AM PST, Peter Zijlstra
wrote:
>On Thu, Feb 23, 2017 at 02:28:13PM +0100, Peter Zijlstra wrote:
>> + * Since various instruction decoders disagree on the length of UD1,
>> + * we cannot use it either. So use UD0 for WARN.
>> + *
>> + * (binutils knows about "ud1" but {
On Thu, Feb 23, 2017 at 06:14:45AM -0800, Arjan van de Ven wrote:
> On 2/23/2017 5:28 AM, Peter Zijlstra wrote:
> >
> >By using "UD0" for WARNs we remove the function call and its possible
> >__FILE__ and __LINE__ immediate arguments from the instruction stream.
> >
> >Total image size will not cha
On Thu, Feb 23, 2017 at 03:09:29PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 23, 2017 at 02:28:13PM +0100, Peter Zijlstra wrote:
> > + * Since various instruction decoders disagree on the length of UD1,
> > + * we cannot use it either. So use UD0 for WARN.
> > + *
> > + * (binutils knows about "ud
On Thu, Feb 23, 2017 at 08:12:32AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 23, 2017 at 02:28:13PM +0100, Peter Zijlstra wrote:
> > +/*
> > + * Only UD2 is defined in the Intel SDM and AMD64 docs,
> > + * but the interweb provided UD0 and UD1:
> > + *
> > + * https://groups.google.com/forum/#!t
On Thu, Feb 23, 2017 at 08:12:32AM -0600, Josh Poimboeuf wrote:
> I guess AMD64 and hypervisors don't need to know about it, since if they
So the insns are mentioned in AMD's APMv2, in the instruction tables at
the end. Just not fully documented like UD2.
--
Regards/Gruss,
Boris.
Good maili
On 2/23/2017 5:28 AM, Peter Zijlstra wrote:
By using "UD0" for WARNs we remove the function call and its possible
__FILE__ and __LINE__ immediate arguments from the instruction stream.
Total image size will not change much, what we win in the instruction
stream we'll loose because of the __bug_
On Thu, Feb 23, 2017 at 02:28:13PM +0100, Peter Zijlstra wrote:
> +/*
> + * Only UD2 is defined in the Intel SDM and AMD64 docs,
> + * but the interweb provided UD0 and UD1:
> + *
> + * https://groups.google.com/forum/#!topic/alt.os.assembly/_rS4L0fnqGE
FYI, the latest Intel SDM does have UD0 an
On Thu, Feb 23, 2017 at 02:28:13PM +0100, Peter Zijlstra wrote:
> + * Since various instruction decoders disagree on the length of UD1,
> + * we cannot use it either. So use UD0 for WARN.
> + *
> + * (binutils knows about "ud1" but {en,de}codes it as 2 bytes, whereas
> + * our kernel decoder think
By using "UD0" for WARNs we remove the function call and its possible
__FILE__ and __LINE__ immediate arguments from the instruction stream.
Total image size will not change much, what we win in the instruction
stream we'll loose because of the __bug_table entries. Still, saves on
I$ footprint an
25 matches
Mail list logo
