On Mon, Nov 21, 2016 at 1:21 PM, Linus Torvalds
wrote:
> On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
>> On 11/21/16 10:00, Linus Torvalds wrote:
>>>
>>> I'd much rather we go back to just making the "cs" entry explicitly
>>> 16-bit, and
On Mon, Nov 21, 2016 at 1:21 PM, Linus Torvalds
wrote:
> On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
>> On 11/21/16 10:00, Linus Torvalds wrote:
>>>
>>> I'd much rather we go back to just making the "cs" entry explicitly
>>> 16-bit, and have a separate padding entry, the way we used
* Andy Lutomirski wrote:
> The SDM says:
>
> If the source operand is an immediate of size less than the operand size, a
> sign-extended value is pushed on the stack. If the source operand is a
> segment
> register (16 bits) and the operand size is 64-bits, a zero-
* Andy Lutomirski wrote:
> The SDM says:
>
> If the source operand is an immediate of size less than the operand size, a
> sign-extended value is pushed on the stack. If the source operand is a
> segment
> register (16 bits) and the operand size is 64-bits, a zero- extended value is
>
On Tue, Nov 22, 2016 at 12:30 AM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
>> >
>> > So I have applied your fix that addresses the worst fallout directly:
>> >
>> >
On Tue, Nov 22, 2016 at 12:30 AM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
>> >
>> > So I have applied your fix that addresses the worst fallout directly:
>> >
>> > fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
>> >
* Linus Torvalds wrote:
> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
> >
> > So I have applied your fix that addresses the worst fallout directly:
> >
> > fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
> >
* Linus Torvalds wrote:
> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
> >
> > So I have applied your fix that addresses the worst fallout directly:
> >
> > fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
> > early_fixup_exception()
> >
> > ... but otherwise we might be
On Mon, Nov 21, 2016 at 2:17 PM, wrote:
>
> Now, segment loads have always ignored the top 32 bits; it's an issue when
> examined by other kinds of code.
Yes. Particularly ptrace and signal information copying. Need to make
sure those things don't look at (or expose) high bits
On Mon, Nov 21, 2016 at 2:17 PM, wrote:
>
> Now, segment loads have always ignored the top 32 bits; it's an issue when
> examined by other kinds of code.
Yes. Particularly ptrace and signal information copying. Need to make
sure those things don't look at (or expose) high bits that may be
On November 21, 2016 1:21:35 PM PST, Linus Torvalds
wrote:
>On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
>> On 11/21/16 10:00, Linus Torvalds wrote:
>>>
>>> I'd much rather we go back to just making the "cs" entry explicitly
>>> 16-bit,
On November 21, 2016 1:21:35 PM PST, Linus Torvalds
wrote:
>On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
>> On 11/21/16 10:00, Linus Torvalds wrote:
>>>
>>> I'd much rather we go back to just making the "cs" entry explicitly
>>> 16-bit, and have a separate padding entry, the way we
On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
> On 11/21/16 10:00, Linus Torvalds wrote:
>>
>> I'd much rather we go back to just making the "cs" entry explicitly
>> 16-bit, and have a separate padding entry, the way we used to long
>> long ago.
>>
>
> I would agree 100%
On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
> On 11/21/16 10:00, Linus Torvalds wrote:
>>
>> I'd much rather we go back to just making the "cs" entry explicitly
>> 16-bit, and have a separate padding entry, the way we used to long
>> long ago.
>>
>
> I would agree 100% with this.
We
On 11/21/16 10:00, Linus Torvalds wrote:
>
> Ugh.
>
> I'd much rather we go back to just making the "cs" entry explicitly
> 16-bit, and have a separate padding entry, the way we used to long
> long ago.
>
I would agree 100% with this.
-hpa
On 11/21/16 10:00, Linus Torvalds wrote:
>
> Ugh.
>
> I'd much rather we go back to just making the "cs" entry explicitly
> 16-bit, and have a separate padding entry, the way we used to long
> long ago.
>
I would agree 100% with this.
-hpa
On Mon, Nov 21, 2016 at 7:58 AM, H. Peter Anvin wrote:
> On 11/20/16 20:54, h...@zytor.com wrote:
>>
>> I believe i686+ writes zero, older CPUs leave unchanged.
>
> I should point out that, at least from my memory, the same applies to
> instructions like "movl ". I can't even
On Mon, Nov 21, 2016 at 7:58 AM, H. Peter Anvin wrote:
> On 11/20/16 20:54, h...@zytor.com wrote:
>>
>> I believe i686+ writes zero, older CPUs leave unchanged.
>
> I should point out that, at least from my memory, the same applies to
> instructions like "movl ". I can't even remember for sure
On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
>
> So I have applied your fix that addresses the worst fallout directly:
>
> fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
> early_fixup_exception()
>
> ... but otherwise we might be better off zeroing out the
On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote:
>
> So I have applied your fix that addresses the worst fallout directly:
>
> fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
> early_fixup_exception()
>
> ... but otherwise we might be better off zeroing out the high bits of segment
On 11/20/16 20:54, h...@zytor.com wrote:
>
> I believe i686+ writes zero, older CPUs leave unchanged.
>
I should point out that, at least from my memory, the same applies to
instructions like "movl ". I can't even remember for sure how the
behavior differs between "movl ," and "movl ,";
I'd
On 11/20/16 20:54, h...@zytor.com wrote:
>
> I believe i686+ writes zero, older CPUs leave unchanged.
>
I should point out that, at least from my memory, the same applies to
instructions like "movl ". I can't even remember for sure how the
behavior differs between "movl ," and "movl ,";
I'd
* Andy Lutomirski wrote:
> On Sat, Nov 19, 2016 at 6:11 PM, Brian Gerst wrote:
> > On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
> >> This is a question for the old-timers here, since I can't find
> >> anything resembling an
* Andy Lutomirski wrote:
> On Sat, Nov 19, 2016 at 6:11 PM, Brian Gerst wrote:
> > On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
> >> This is a question for the old-timers here, since I can't find
> >> anything resembling an answer in the SDM.
> >>
> >> Suppose an exception happens
On November 19, 2016 5:52:57 PM PST, Andy Lutomirski wrote:
>This is a question for the old-timers here, since I can't find
>anything resembling an answer in the SDM.
>
>Suppose an exception happens (#UD in this case, but I assume it
>doesn't really matter). We're not in long
On November 19, 2016 5:52:57 PM PST, Andy Lutomirski wrote:
>This is a question for the old-timers here, since I can't find
>anything resembling an answer in the SDM.
>
>Suppose an exception happens (#UD in this case, but I assume it
>doesn't really matter). We're not in long mode, and the IDT
On Sat, Nov 19, 2016 at 6:11 PM, Brian Gerst wrote:
> On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
>> This is a question for the old-timers here, since I can't find
>> anything resembling an answer in the SDM.
>>
>> Suppose an exception happens (#UD
On Sat, Nov 19, 2016 at 6:11 PM, Brian Gerst wrote:
> On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
>> This is a question for the old-timers here, since I can't find
>> anything resembling an answer in the SDM.
>>
>> Suppose an exception happens (#UD in this case, but I assume it
>>
On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
> This is a question for the old-timers here, since I can't find
> anything resembling an answer in the SDM.
>
> Suppose an exception happens (#UD in this case, but I assume it
> doesn't really matter). We're not in long
On Sat, Nov 19, 2016 at 8:52 PM, Andy Lutomirski wrote:
> This is a question for the old-timers here, since I can't find
> anything resembling an answer in the SDM.
>
> Suppose an exception happens (#UD in this case, but I assume it
> doesn't really matter). We're not in long mode, and the IDT
This is a question for the old-timers here, since I can't find
anything resembling an answer in the SDM.
Suppose an exception happens (#UD in this case, but I assume it
doesn't really matter). We're not in long mode, and the IDT is set up
to deliver to a normal 32-bit kernel code segment. We're
This is a question for the old-timers here, since I can't find
anything resembling an answer in the SDM.
Suppose an exception happens (#UD in this case, but I assume it
doesn't really matter). We're not in long mode, and the IDT is set up
to deliver to a normal 32-bit kernel code segment. We're
32 matches
Mail list logo