Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1347967 > unrolled thread

[RFC PATCH] x86: Make sure verify_cpu has a good stack

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 12:30 +0100
    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 17:20 +0100
      Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Mika Penttilä <mika.penttila@nextfour.com> - 2016-03-02 17:40 +0100
        Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 18:00 +0100
          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Mika Penttilä <mika.penttila@nextfour.com> - 2016-03-02 18:50 +0100
    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Mika Penttilä <mika.penttila@nextfour.com> - 2016-03-02 17:20 +0100
    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 17:30 +0100
      Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 19:00 +0100
        Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 19:20 +0100
          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 19:30 +0100
          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 19:40 +0100
            Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 21:00 +0100
              Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 21:50 +0100
              Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 22:40 +0100
                Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 22:50 +0100
                  Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 23:00 +0100
                    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 23:20 +0100
                      Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 23:30 +0100
                        Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-02 23:40 +0100
                          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 23:50 +0100
                          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Yinghai Lu <yinghai@kernel.org> - 2016-03-03 01:20 +0100
                            Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Yinghai Lu <yinghai@kernel.org> - 2016-03-03 02:10 +0100
                              Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Yinghai Lu <yinghai@kernel.org> - 2016-03-03 04:00 +0100
                          Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-03 13:30 +0100
                            Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-03 16:30 +0100
                              Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-03 17:40 +0100
                                Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-03 21:30 +0100
                                  Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-03 22:00 +0100
                                    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack "H. Peter Anvin" <hpa@zytor.com> - 2016-03-03 22:30 +0100
                                      Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-03 22:40 +0100
                            Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Yinghai Lu <yinghai@kernel.org> - 2016-03-04 02:20 +0100
                            Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Yinghai Lu <yinghai@kernel.org> - 2016-03-04 03:30 +0100
                    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Borislav Petkov <bp@alien8.de> - 2016-03-02 23:20 +0100
    Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack Brian Gerst <brgerst@gmail.com> - 2016-03-02 17:30 +0100

Page 1 of 2  [1] 2  Next page →

#1347967 — [RFC PATCH] x86: Make sure verify_cpu has a good stack

From: Borislav Petkov <bp@suse.de>

04633df0c43d ("x86/cpu: Call verify_cpu() after having entered long mode too")
added the call to verify_cpu() for sanitizing CPU configuration.

The latter uses the stack minimally and it can happen that we land in
startup_64() directly from a 64-bit bootloader. Then we want to use our
own, known good stack.

Do that.

APs don't need this as the trampoline sets up a stack for them.

Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kernel/head_64.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 22fbf9df61bb..d60a044c2fdc 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -64,6 +64,10 @@ startup_64:
 	 * tables and then reload them.
 	 */
 
+	/* Setup a stack for verify_cpu */
+	movq    stack_start - __START_KERNEL_map, %rsp
+	subq	$__START_KERNEL_map, %rsp
+
 	/* Sanitize CPU configuration */
 	call verify_cpu
 
-- 
2.3.5

[toc] | [next] | [standalone]

#1348289

On Wed, Mar 02, 2016 at 05:55:14PM +0200, Mika Penttilä wrote:
> > +	/* Setup a stack for verify_cpu */
> > +	movq    stack_start - __START_KERNEL_map, %rsp
> > +	subq	$__START_KERNEL_map, %rsp
> > +
>
> You subtract __START_KERNEL_map twice ?

Yes. That's not very obvious and it took me a while. I probably should
add a comment.

Want to stare at it a little bit more and try to figure it out or should
I explain?

:-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348310

On 02.03.2016 18:15, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 05:55:14PM +0200, Mika Penttilä wrote:
>>> +	/* Setup a stack for verify_cpu */
>>> +	movq    stack_start - __START_KERNEL_map, %rsp
>>> +	subq	$__START_KERNEL_map, %rsp
>>> +
>> You subtract __START_KERNEL_map twice ?
> Yes. That's not very obvious and it took me a while. I probably should
> add a comment.
>
> Want to stare at it a little bit more and try to figure it out or should
> I explain?
>
> :-)
>

I actually looked at it a while too...

The
  movq stack_start - __START_KERNEL_map, %rsp

turns into (objdump disassembly)

  mov    0x0,%rsp

with relocation
0000000000000004 R_X86_64_32S      stack_start+0x0000000080000000

Now stack_start is at ffffffff81ef3380, so the relocation gives 1ef3380 which would be correct, so why the
second subq ?

You may explain :)

--Mika

[toc] | [prev] | [next] | [standalone]

#1348330

On Wed, Mar 02, 2016 at 06:38:15PM +0200, Mika Penttilä wrote:
> I actually looked at it a while too...
> 
> The
>   movq stack_start - __START_KERNEL_map, %rsp
> 
> turns into (objdump disassembly)
> 
>   mov    0x0,%rsp
> 
> with relocation
> 0000000000000004 R_X86_64_32S      stack_start+0x0000000080000000
> 
> Now stack_start is at ffffffff81ef3380, so the relocation gives 1ef3380 which would be correct, so why the
> second subq ?
> 
> You may explain :)

Here it is :-)

$ readelf -a vmlinux | grep stack_start
 70526: ffffffff81cbabf8     0 NOTYPE  GLOBAL DEFAULT   14 stack_start

0xffffffff81cbabf8 - __START_KERNEL_map =
0xffffffff81cbabf8 - 0xffffffff80000000 =
0x1cbabf8

(gdb) x/x 0x1cbabf8
0x1cbabf8:      0xffffffff81c03ff8

(You don't need gdb for that - you can hexdump or objdump vmlinux).

Now stack_start is:

        GLOBAL(stack_start)
        .quad  init_thread_union+THREAD_SIZE-8

which is

$ readelf -a vmlinux | grep init_thread_union
 82491: ffffffff81c00000 16384 OBJECT  GLOBAL DEFAULT   14 init_thread_union

so init_thread_union+THREAD_SIZE-8 = 0xffffffff81c00000 + 4*4096-8 = 0xffffffff81c03ff8

So you have to subtract __START_KERNEL_map again because it has there a
virtual address and we haven't enabled paging yet:

0xffffffff81c03ff8 - 0xffffffff80000000 = 0x1c03ff8.

Makes sense?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348360

On 02.03.2016 18:55, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 06:38:15PM +0200, Mika Penttilä wrote:
>> I actually looked at it a while too...
>>
>> The
>>   movq stack_start - __START_KERNEL_map, %rsp
>>
>> turns into (objdump disassembly)
>>
>>   mov    0x0,%rsp
>>
>> with relocation
>> 0000000000000004 R_X86_64_32S      stack_start+0x0000000080000000
>>
>> Now stack_start is at ffffffff81ef3380, so the relocation gives 1ef3380 which would be correct, so why the
>> second subq ?
>>
>> You may explain :)
> Here it is :-)
>
> $ readelf -a vmlinux | grep stack_start
>  70526: ffffffff81cbabf8     0 NOTYPE  GLOBAL DEFAULT   14 stack_start
>
> 0xffffffff81cbabf8 - __START_KERNEL_map =
> 0xffffffff81cbabf8 - 0xffffffff80000000 =
> 0x1cbabf8
>
> (gdb) x/x 0x1cbabf8
> 0x1cbabf8:      0xffffffff81c03ff8
>
> (You don't need gdb for that - you can hexdump or objdump vmlinux).
>
> Now stack_start is:
>
>         GLOBAL(stack_start)
>         .quad  init_thread_union+THREAD_SIZE-8
>
> which is
>
> $ readelf -a vmlinux | grep init_thread_union
>  82491: ffffffff81c00000 16384 OBJECT  GLOBAL DEFAULT   14 init_thread_union
>
> so init_thread_union+THREAD_SIZE-8 = 0xffffffff81c00000 + 4*4096-8 = 0xffffffff81c03ff8
>
> So you have to subtract __START_KERNEL_map again because it has there a
> virtual address and we haven't enabled paging yet:
>
> 0xffffffff81c03ff8 - 0xffffffff80000000 = 0x1c03ff8.
>
> Makes sense?
>
Ah missed completely that stack_start is effectively a pointer to stack..

Thanks,
Mika

[toc] | [prev] | [next] | [standalone]

#1348292

On 02.03.2016 13:20, Borislav Petkov wrote:
> From: Borislav Petkov <bp@suse.de>
>
> 04633df0c43d ("x86/cpu: Call verify_cpu() after having entered long mode too")
> added the call to verify_cpu() for sanitizing CPU configuration.
>
> The latter uses the stack minimally and it can happen that we land in
> startup_64() directly from a 64-bit bootloader. Then we want to use our
> own, known good stack.
>
> Do that.
>
> APs don't need this as the trampoline sets up a stack for them.
>
> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
>  arch/x86/kernel/head_64.S | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 22fbf9df61bb..d60a044c2fdc 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -64,6 +64,10 @@ startup_64:
>  	 * tables and then reload them.
>  	 */
>  
> +	/* Setup a stack for verify_cpu */
> +	movq    stack_start - __START_KERNEL_map, %rsp
> +	subq	$__START_KERNEL_map, %rsp
> +

 
You subtract __START_KERNEL_map twice ?

--Mika

[toc] | [prev] | [next] | [standalone]

#1348299

On Wed, Mar 02, 2016 at 11:22:30AM -0500, Brian Gerst wrote:
> This should be: movq stack_start(%rip), %rsp

No it wouldn't. That doesn't work.

> > +       subq    $__START_KERNEL_map, %rsp
> 
> It would be better to add the offset to the initializer for
> stack_start instead of adjusting it at runtime.  That would require
> moving the existing load of stack_start from the common path to the
> secondary startup,

This is the BSP we're talking about - no secondary startup. We want to run
verify_cpu as early as possible.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348363

On March 2, 2016 8:25:30 AM PST, Borislav Petkov <bp@alien8.de> wrote:
>On Wed, Mar 02, 2016 at 11:22:30AM -0500, Brian Gerst wrote:
>> This should be: movq stack_start(%rip), %rsp
>
>No it wouldn't. That doesn't work.
>
>> > +       subq    $__START_KERNEL_map, %rsp
>> 
>> It would be better to add the offset to the initializer for
>> stack_start instead of adjusting it at runtime.  That would require
>> moving the existing load of stack_start from the common path to the
>> secondary startup,
>
>This is the BSP we're talking about - no secondary startup. We want to
>run
>verify_cpu as early as possible.

Please explain why we can't use rip-relative addressing in some form...
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [next] | [standalone]

#1348372

On Wed, Mar 02, 2016 at 09:53:28AM -0800, H. Peter Anvin wrote:
> Please explain why we can't use rip-relative addressing in some form...

We *can* do almost what Brian suggested:

        movq    stack_start(%rip), %rsp
        subq    $__START_KERNEL_map, %rsp

But we still have to subtract __START_KERNEL_map.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348380

On March 2, 2016 10:15:56 AM PST, Borislav Petkov <bp@alien8.de> wrote:
>On Wed, Mar 02, 2016 at 09:53:28AM -0800, H. Peter Anvin wrote:
>> Please explain why we can't use rip-relative addressing in some
>form...
>
>We *can* do almost what Brian suggested:
>
>        movq    stack_start(%rip), %rsp
>        subq    $__START_KERNEL_map, %rsp
>
>But we still have to subtract __START_KERNEL_map.

Obviously.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [next] | [standalone]

#1348393

On 03/02/16 10:15, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 09:53:28AM -0800, H. Peter Anvin wrote:
>> Please explain why we can't use rip-relative addressing in some form...
> 
> We *can* do almost what Brian suggested:
> 
>         movq    stack_start(%rip), %rsp
>         subq    $__START_KERNEL_map, %rsp
> 
> But we still have to subtract __START_KERNEL_map.
> 

Well, we definitely should use %rip-relative addressing if we can.

However, even so I believe this breaks if the kernel is loaded anywhere
but its default load address.  I think we need to do something like:

	movq	stack_start(%rip), %rax
	leaq	__START_KERNEL_map(%rip), %rdx
	subq	%rdx, %rax
	movq	%rax, %rsp

The use of temporary registers avoids clobbering a valid stack pointer
for even a single instruction if we are given one.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1348432

On Wed, Mar 02, 2016 at 10:39:05AM -0800, H. Peter Anvin wrote:
> Well, we definitely should use %rip-relative addressing if we can.

Right you are.

> However, even so I believe this breaks if the kernel is loaded anywhere
> but its default load address.  I think we need to do something like:
> 
> 	movq	stack_start(%rip), %rax
> 	leaq	__START_KERNEL_map(%rip), %rdx
> 	subq	%rdx, %rax
> 	movq	%rax, %rsp
> 
> The use of temporary registers avoids clobbering a valid stack pointer
> for even a single instruction if we are given one.

Yeah, we should be prudent and make this as sturdy as possible. I did this:

CONFIG_PHYSICAL_START=0x100beef

and it aligned startup_64 up to ffffffff82000000. It seems to boot fine
in kvm. But better safe than sorry.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348470

On Wed, Mar 02, 2016 at 08:50:53PM +0100, Borislav Petkov wrote:
> But better safe than sorry.

I got this, it looks good when I'm single-stepping through it with gdb
and it boots fine in kvm. I'll run it on baremetal tomorrow:

        /*
         * Setup stack for verify_cpu(): make sure we don't clobber a valid
         * stack pointer by using temporary registers.
         */
        movq    stack_start(%rip), %rax
        movq    $__START_KERNEL_map, %rdx
        subq    %rdx, %rax
        movq    %rax, %rsp

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348486

On 03/02/16 11:50, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 10:39:05AM -0800, H. Peter Anvin wrote:
>> Well, we definitely should use %rip-relative addressing if we can.
> 
> Right you are.
> 
>> However, even so I believe this breaks if the kernel is loaded anywhere
>> but its default load address.  I think we need to do something like:
>>
>> 	movq	stack_start(%rip), %rax
>> 	leaq	__START_KERNEL_map(%rip), %rdx
>> 	subq	%rdx, %rax
>> 	movq	%rax, %rsp
>>
>> The use of temporary registers avoids clobbering a valid stack pointer
>> for even a single instruction if we are given one.
> 
> Yeah, we should be prudent and make this as sturdy as possible. I did this:
> 
> CONFIG_PHYSICAL_START=0x100beef
> 
> and it aligned startup_64 up to ffffffff82000000. It seems to boot fine
> in kvm. But better safe than sorry.
> 

You're not actually testing anything as the real issue is what happens
with a relocating bootloader.  That's okay; I think we can be pretty
sure the above works by inspection.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1348487

On Wed, Mar 02, 2016 at 01:35:09PM -0800, H. Peter Anvin wrote:
> You're not actually testing anything as the real issue is what happens
> with a relocating bootloader.

Hmm, how would that relocation happen so that va - __START_KERNEL_map
doesn't give pa?

Or do you mean something else with "relocating bootloader"? Do you know
of one which does that?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348494

On 03/02/16 13:46, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 01:35:09PM -0800, H. Peter Anvin wrote:
>> You're not actually testing anything as the real issue is what happens
>> with a relocating bootloader.
> 
> Hmm, how would that relocation happen so that va - __START_KERNEL_map
> doesn't give pa?
> 
> Or do you mean something else with "relocating bootloader"? Do you know
> of one which does that?
> 

A relocating bootloader is one that doesn't load the kernel at
CONFIG_PHYSICAL_ADDRESS.  The EFI stub is one example.

__START_KERNEL_map is not relocated.  On x86-64 we do relocation by
pointing the page tables at a different address.

So I really think we need this to be a leaq, so we take a nonstandard
load address into consideration.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1348559

On 03/02/16 14:09, Borislav Petkov wrote:
> On Wed, Mar 02, 2016 at 01:54:50PM -0800, H. Peter Anvin wrote:
>> A relocating bootloader is one that doesn't load the kernel at
>> CONFIG_PHYSICAL_ADDRESS.  The EFI stub is one example.
>>
>> __START_KERNEL_map is not relocated.  On x86-64 we do relocation by
>> pointing the page tables at a different address.
>>
>> So I really think we need this to be a leaq, so we take a nonstandard
>> load address into consideration.
> 
> Hmm, but __START_KERNEL_map is a simple macro:
> 
> #define __START_KERNEL_map      _AC(0xffffffff80000000, UL)

That should not be a problem.
> 
> Ok, I think you want to do something like this for stack_start too:
> 
>         /*
>          * Compute the delta between the address I am compiled to run at and the
>          * address I am actually running at.
>          */
>         leaq    _text(%rip), %rbp
>         subq    $_text - __START_KERNEL_map, %rbp
> 	...
> 
> in the normal case %rbp is 0, of course.
> 

Not sure if we need a reference to _text here.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1348570

On Wed, Mar 02, 2016 at 02:11:51PM -0800, H. Peter Anvin wrote:
> Not sure if we need a reference to _text here.

Ah, so stack_start is in .ref.data, I guess we can add a __ref_data
marker in vmlinux.lds.S to denote the start of the .ref.data section and
use that for calculating the delta...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1348576

On March 2, 2016 2:28:42 PM PST, Borislav Petkov <bp@alien8.de> wrote:
>On Wed, Mar 02, 2016 at 02:11:51PM -0800, H. Peter Anvin wrote:
>> Not sure if we need a reference to _text here.
>
>Ah, so stack_start is in .ref.data, I guess we can add a __ref_data
>marker in vmlinux.lds.S to denote the start of the .ref.data section
>and
>use that for calculating the delta...

I'm trying to think of any reason why we couldn't simply have a symbol at the top of the initial stack?  Then a simple leaq would suffice; this is for the BSP after all.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [next] | [standalone]

#1348581

On Wed, Mar 02, 2016 at 02:32:54PM -0800, H. Peter Anvin wrote:
> I'm trying to think of any reason why we couldn't simply have a symbol
> at the top of the initial stack? Then a simple leaq would suffice;
> this is for the BSP after all.

That should be simpler. And we do games like that already in the trampoline:

        # Setup stack
        movl    $rm_stack_end, %esp

...

GLOBAL(rm_stack)
        .space  2048
GLOBAL(rm_stack_end)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web