Re: First post! Regarding transition from int 0x80 to syscall?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

You forgot to cc: to the list previously, I am afraid :)

On Sat, Aug 14, 2010 at 18:16, javad karabi <snkcld1@xxxxxxxxx> wrote:
> But, I dont really have my own computer at home, so I have to get a VPS
> online.

as long as you don't hack somebody else system and get into their
shell access just for your kernel adventure, I think it's ok :D

> But I can boot in to my own kernel, so, its fine...
> I am not trying to code for AMD specific arch, however, I am trying to learn
> coding for amd64 / x86-64.
> Essentially, I dont want to learn the 32bit architecture if the 64 bit is
> the way of the future.

I'm ok with that, but certainly it would be easier if we know about 32
bit arch first, right? Since actually large part of 64 bit arch (both
IA 64 and AMD64) are based on 32 bit.....

> Essentially, whats the point of learning int 0x80 for system call, whenever
> the future is syscall?
> Am I right?

Without claiming that I am an expert about it, I think both int x80h
and syscall are about the same, trigerring exception and doing switch
from user mode and kernel mode....the difference is in the detail...

> Of course, learning architecture neutral components is always good to know,
> so I will definitely look into the
> "jump to vsyscall page". Could you elaborate on that?

Perhaps this page could explain to you better http://lwn.net/Articles/30258/

But in essence, it's a VDSO (Virtual Dynamic Shared Object--a soooo
techie term...a "virtual library file" would be easier to understand I
guess.

So you jump to it, which is usually mapped at such high virtual
address, put certain values in registers first..and this page will
decide, whether it will be translated as int 80h, or syscall/sysenter.

I hope my memory still serve  me well :D

> Regarding Xen, I think it is interfering with my kernel hacking.
> I booted into a kernel which had my system call sys_snkcld in the
> system_call_table_32.S file (I believe thats the name...),
> then, created my function, which is essentially the following:
> DEFINE_SYSCALL0(snkcld)
> {
> return 4;
> }

This syscall is already assigned syscall number, right?

> However, I use inline asm in user space to do the following:
> mov 338, %rax
> sysenter
> Then, I use gdb to find the value of rax after sysenter.
> In all cases, the value of rax was always -1,  which I believe is
> "permission denied".

Is your Xen VPS operates in paravirtualized mode? or full virtualization mode?

There is a chance it's the first...thus the guest kernel is actually
doing a .....uhm, crap I forgot the name....hypercall. It's actually a
jmp/call to the hypervisor to do the "syscall".

So, maybe...just maybe....your "syscall" is intercepted by the
hypervisor..but it replied "s**t, it's not in my defined hypercall
table...get back!"

> Also, regarding syscall being faster because of doing other things in
> advance...
> How does the opcode know the location in memory of the kernel stack for the
> task?

Not sure, so I think you need to research it by your own. But i
believe it's not predetermined..

> Also, and this is one of my biggest questions... The system call number is
> placed in rax, but, how does syscall know
> the location of the system call table? The call number would have to be
> multiplied by... I believe 8... Then added to
> the base address of the system call table to determine the address of the
> system call handler.
> From what I understand, the dispatcher would look into the eax register,
> then multiply that in x86.
> But, if its an opcode which is doing this... how does the opcode know the
> address of the system call table?

It's the job of the interrupt number 80 handler...or sysenter/sysycall
handler....you do remember about how interrupt is handled in Intel
arch, right?

>  Thank you for your help. It means alot.

No problem..I am sorry if I cause more noise than help :D

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux