* Linus Torvalds wrote:
> On Mon, Mar 9, 2015 at 9:55 AM, Borislav Petkov wrote:
> > On Mon, Mar 09, 2015 at 09:49:42AM -0700, Linus Torvalds wrote:
> >>
> >> I don't remember when it was open-coded, and I never created a git
> >> archive of all the old tar-files from before BK, so it's not tri
On Mon, Mar 09, 2015 at 10:12:46AM -0700, Linus Torvalds wrote:
> On Mon, Mar 9, 2015 at 9:55 AM, Borislav Petkov wrote:
> > On Mon, Mar 09, 2015 at 09:49:42AM -0700, Linus Torvalds wrote:
> >>
> >> I don't remember when it was open-coded, and I never created a git
> >> archive of all the old
On Mon, Mar 9, 2015 at 9:55 AM, Borislav Petkov wrote:
> On Mon, Mar 09, 2015 at 09:49:42AM -0700, Linus Torvalds wrote:
>>
>> I don't remember when it was open-coded, and I never created a git
>> archive of all the old tar-files from before BK, so it's not trivial
>> to check ;(
>
> This maybe:
>
On Mon, Mar 09, 2015 at 09:49:42AM -0700, Linus Torvalds wrote:
> On Mon, Mar 9, 2015 at 9:42 AM, Ingo Molnar wrote:
> >
> > Check out the first released version:
>
> It continued doing so at *least* until 1.0, so for several years.
>
> I don't remember when it was open-coded, and I never create
On Mon, Mar 9, 2015 at 9:42 AM, Ingo Molnar wrote:
>
> Check out the first released version:
It continued doing so at *least* until 1.0, so for several years.
I don't remember when it was open-coded, and I never created a git
archive of all the old tar-files from before BK, so it's not trivial
t
* Denys Vlasenko wrote:
> On Mon, Mar 9, 2015 at 12:46 PM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> >> */
> >> >> unsigned longstack[64];
> >> >>
> >> >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
> >> >
> >> >
> >> > Seems to b
On Mon, Mar 9, 2015 at 5:04 AM, Denys Vlasenko wrote:
>
> IIRC task gates weren't used in Linux at first, and now they are
> only used for double fault handler -
Actually, historical note: the TSS was very much used for task
switching originally. Not only was it a "play with how 386 works" test
v
On Mon, Mar 9, 2015 at 3:00 PM, Andy Lutomirski wrote:
>> I'm preparing a patch which does this:
>>
>> btl $X86_EFLAGS_VM_BIT,PT_EFLAGS(%esp)
>> jc restore_nocheck # VM set, not it
>> testb $3,PT_CS(%esp)
>> jz restore_nocheck # CPL0,
On Mon, Mar 9, 2015 at 6:44 AM, Denys Vlasenko wrote:
> On Mon, Mar 9, 2015 at 2:35 PM, Andy Lutomirski wrote:
>>> Apparently, code which uses this still exists, here
>>> (current git):
>>>
>>> restore_all:
>>> TRACE_IRQS_IRET
>>> restore_all_notrace:
>>> #ifdef CONFIG_X86_ESPFIX32
>>>
On Mon, Mar 9, 2015 at 2:35 PM, Andy Lutomirski wrote:
>> Apparently, code which uses this still exists, here
>> (current git):
>>
>> restore_all:
>> TRACE_IRQS_IRET
>> restore_all_notrace:
>> #ifdef CONFIG_X86_ESPFIX32
>> movl PT_EFLAGS(%esp), %eax # mix EFLAGS, SS and CS
>>
On Mon, Mar 9, 2015 at 5:55 AM, Denys Vlasenko wrote:
> On Sun, Mar 8, 2015 at 8:41 PM, Andy Lutomirski wrote:
>>> It seems to be true that 32-bit x86 always has two unused words
>>> beyond "struct pt_regs" on stack during syscalls.
>>>
>>> IOW: tss.sp0 is *not* set at the very end of the stack o
On Mar 9, 2015 7:46 AM, "Ingo Molnar" wrote:
>
>
> * Andy Lutomirski wrote:
>
> > >> */
> > >> unsigned longstack[64];
> > >>
> > >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
> > >
> > >
> > > Seems to be unused: I commented it out on "defconfig" bui
On Sun, Mar 8, 2015 at 3:13 PM, Denys Vlasenko wrote:
> On Sat, Mar 7, 2015 at 1:33 AM, Andy Lutomirski wrote:
>> On Fri, Mar 6, 2015 at 3:30 PM, Fengguang Wu wrote:
>>> Greetings,
>>>
>>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>>
>>> git://git.kernel.org/pub/
On Sun, Mar 8, 2015 at 8:41 PM, Andy Lutomirski wrote:
>> It seems to be true that 32-bit x86 always has two unused words
>> beyond "struct pt_regs" on stack during syscalls.
>>
>> IOW: tss.sp0 is *not* set at the very end of the stack on 32-bit.
>
> So maybe the idea is that, if we end up using s
On Mon, Mar 9, 2015 at 12:46 PM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> >> */
>> >> unsigned longstack[64];
>> >>
>> >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
>> >
>> >
>> > Seems to be unused: I commented it out on "defconfig" build
* Andy Lutomirski wrote:
> >> */
> >> unsigned longstack[64];
> >>
> >> Last I checked, 0x100 != 64. Also, wow, this is kind of disgusting. :)
> >
> >
> > Seems to be unused: I commented it out on "defconfig" build
> > and got no build errors.
>
> It's used. On 32-bit, NMIs d
On Sun, Mar 8, 2015 at 8:49 PM, Denys Vlasenko wrote:
> On Sun, Mar 8, 2015 at 8:13 PM, Denys Vlasenko
> wrote:
>>> /*
>>> * The below -8 is to reserve 8 bytes on top of the ring0 stack.
>>> * This is necessary to guarantee that the entire "struct pt_regs"
>>> * is accessible even if the CPU
On Sun, Mar 8, 2015 at 8:41 PM, Andy Lutomirski wrote:
>>> 4. Not directly related, but the 32-bit tss_struct contains this gem:
>>>
>>> /*
>>> * .. and then another 0x100 bytes for the emergency kernel stack:
>>> */
>>> unsigned longstack[64];
>>>
>>> Last I checked, 0x1
On Sun, Mar 8, 2015 at 12:49 PM, Denys Vlasenko
wrote:
> On Sun, Mar 8, 2015 at 8:13 PM, Denys Vlasenko
> wrote:
>>> /*
>>> * The below -8 is to reserve 8 bytes on top of the ring0 stack.
>>> * This is necessary to guarantee that the entire "struct pt_regs"
>>> * is accessible even if the CPU
On Sun, Mar 8, 2015 at 8:13 PM, Denys Vlasenko wrote:
>> /*
>> * The below -8 is to reserve 8 bytes on top of the ring0 stack.
>> * This is necessary to guarantee that the entire "struct pt_regs"
>> * is accessible even if the CPU haven't stored the SS/ESP registers
>> * on the stack (interrup
On Sun, Mar 8, 2015 at 12:13 PM, Denys Vlasenko
wrote:
> On Sat, Mar 7, 2015 at 1:33 AM, Andy Lutomirski wrote:
>> On Fri, Mar 6, 2015 at 3:30 PM, Fengguang Wu wrote:
>>> Greetings,
>>>
>>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>>
>>> git://git.kernel.org/pub
On Sat, Mar 7, 2015 at 1:33 AM, Andy Lutomirski wrote:
> On Fri, Mar 6, 2015 at 3:30 PM, Fengguang Wu wrote:
>> Greetings,
>>
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
>>
>> commit 75182b163
On Fri, Mar 6, 2015 at 3:30 PM, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
>
> commit 75182b1632a89f12540baa1806a7c5c180db620c
> Author: Andy Lutomirski
>
23 matches
Mail list logo