From: george anzinger <george@mvista.com>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: Daniel Jacobowitz <dan@debian.org>,
Brian Gerst <bgerst@didntduck.org>,
Petr Vandrovec <VANDROVE@vc.cvut.cz>,
"Richard B. Johnson" <root@chaos.analogic.com>,
dvorak <dvorak@xs4all.nl>,
linux-kernel@vger.kernel.org
Subject: Re: Syscall changes registers beyond %eax, on linux-i386
Date: Fri, 20 Sep 2002 01:32:05 -0700 [thread overview]
Message-ID: <3D8ADD05.999E4A5C@mvista.com> (raw)
In-Reply-To: 15754.12963.763811.307755@kim.it.uu.se
Mikael Pettersson wrote:
>
> Daniel Jacobowitz writes:
> > That's not going to help. As Richard said, the memory in question
> > belongs to the called function. GCC knows this. It can freely modify
> > it. The fact that the value of the parameter is const is a
> > language-level, semantic thing. It doesn't say anything about the
> > const-ness of that memory. Only the ABI does.
>
> Does Linux/x86 even have a proper ABI document? I've never seen one.
> The closest I've seen would be the SVR4 i386 psABI, but it
> deliberately doesn't define the raw syscall interface, only the
> each-syscall-is-a-C-function one implemented by the C library,
> and that interface doesn't suffer from the current issue.
>
> IOW, the kernel may not be at fault if user-space code invokes int
> $0x80 directly and then sees clobbered registers.
Ah, that, indeed is the issue. As far as C is concerned,
the call is NOT a call, but a bit of asm. If the asm is
correctly written the problem goes away, not because the
register is not modified, but because C is on notice that it
MIGHT be modified and thus not to count on it.
As a practical matter, ebx is used to pass arg1 to the
kernel so it must be changed by the asm code, the further
listing of it beyond the third ":" in the asm inline, will
cause the compiler to not rely on it being further
modified. The same is true of all the registers used to
pass parameters. (These are: arg1 ebx, arg2 ecx, arg3 edx,
arg4 esi, arg5 edi, and arg6 ebp.)
So, is there a problem? Yes, neither the call stub macros
in asm/unistd.h nor those in glibc bother to list the used
registers beyond the third ":". And, if I understand this
right, the glibc code to save ebx in another register
suffers from the false assumption that THAT register can be
clobbered, but this is only true if C sees the code as a
function, not an inline asm, but most system calls in glibc
are coded as inline asm, not separate functions (not to be
confused with the C inline, which is a separate function).
At least that is how I see it. Comments?
-g
>
> /Mikael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2002-09-20 8:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-19 17:44 Syscall changes registers beyond %eax, on linux-i386 Petr Vandrovec
2002-09-19 18:04 ` Brian Gerst
2002-09-19 18:30 ` Richard Henderson
2002-09-19 18:51 ` Brian Gerst
2002-09-19 18:57 ` Richard Henderson
2002-09-19 19:40 ` Richard B. Johnson
2002-09-19 19:41 ` Richard Henderson
2002-09-19 19:53 ` Richard B. Johnson
2002-09-19 22:46 ` J.A. Magallon
2002-09-20 12:27 ` Richard B. Johnson
2002-09-20 17:16 ` Richard Henderson
2002-09-22 1:33 ` Pavel Machek
2002-09-23 13:11 ` Richard B. Johnson
2002-09-23 18:31 ` Pavel Machek
2002-09-19 19:18 ` Richard B. Johnson
2002-09-19 19:24 ` Daniel Jacobowitz
2002-09-19 20:25 ` Mikael Pettersson
2002-09-20 8:32 ` george anzinger [this message]
2002-09-21 6:19 ` Richard Henderson
2002-09-21 8:09 ` george anzinger
2002-09-21 15:08 ` Richard Henderson
2002-09-24 18:02 ` CHECKER bate: " george anzinger
-- strict thread matches above, loose matches on Subject: below --
2002-09-19 14:45 dvorak
2002-09-19 16:11 ` Richard B. Johnson
2002-09-19 17:09 ` Brian Gerst
2002-09-19 17:22 ` Richard B. Johnson
2002-09-19 17:51 ` Brian Gerst
2002-09-19 18:30 ` Richard B. Johnson
2002-09-19 17:59 ` dvorak
2002-09-19 18:32 ` Richard B. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D8ADD05.999E4A5C@mvista.com \
--to=george@mvista.com \
--cc=VANDROVE@vc.cvut.cz \
--cc=bgerst@didntduck.org \
--cc=dan@debian.org \
--cc=dvorak@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).