public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* What are the option for overriding system calls GNU libc calls?
@ 2022-09-22 12:31 Godmar Back
  2022-09-26 11:57 ` Adhemerval Zanella Netto
  0 siblings, 1 reply; 2+ messages in thread
From: Godmar Back @ 2022-09-22 12:31 UTC (permalink / raw)
  To: William Tambe via Libc-help

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

Hi,

I have a question. Say I wanted to override the `write()` system call in an
application so that when I compile and link it, my version of `write()` is
called by both the application program as well as by GNU libc, for
instance, from puts or printf.  To what extent is this supported?

I'm aware of the following options:
- (a) link statically. In this case, if I provide a strong definition of
`write()`, the application will pick it up. GNU libc, otoh, uses
`__write()`  Overriding `__write` with a strong definition works and gets
libc to call my __write.

- (b) link dynamically and use `LD_PRELOAD`. In this case, I can get the
application to call my `write`, but libc will continue to call `__write`; I
believe; I haven't tried if I can provide a __write and have libc pick up
on it since (I thought) that libc resolves these symbols internally or from
a dynamic library on its link chain.

In any event, my question is: is there a sanctioned or semi-sanctioned way
to override system calls for both the static and dynamic linking process?

 - Godmar

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: What are the option for overriding system calls GNU libc calls?
  2022-09-22 12:31 What are the option for overriding system calls GNU libc calls? Godmar Back
@ 2022-09-26 11:57 ` Adhemerval Zanella Netto
  0 siblings, 0 replies; 2+ messages in thread
From: Adhemerval Zanella Netto @ 2022-09-26 11:57 UTC (permalink / raw)
  To: Adhemerval Zanella via Libc-help



On 22/09/22 09:31, Godmar Back via Libc-help wrote:
> Hi,
> 
> I have a question. Say I wanted to override the `write()` system call in an
> application so that when I compile and link it, my version of `write()` is
> called by both the application program as well as by GNU libc, for
> instance, from puts or printf.  To what extent is this supported?
> 
> I'm aware of the following options:
> - (a) link statically. In this case, if I provide a strong definition of
> `write()`, the application will pick it up. GNU libc, otoh, uses
> `__write()`  Overriding `__write` with a strong definition works and gets
> libc to call my __write.
> 
> - (b) link dynamically and use `LD_PRELOAD`. In this case, I can get the
> application to call my `write`, but libc will continue to call `__write`; I
> believe; I haven't tried if I can provide a __write and have libc pick up
> on it since (I thought) that libc resolves these symbols internally or from
> a dynamic library on its link chain.

Unfortunately this is done intentionally and although the usual double underscore
is used on mot symbol, some also uses different internal nomenclature (for
instance __libc_sigaction).  For internal libc usage, we explicit avoid PLT usage
so you will need to either use a dynamic runtime tool to rewrite the text segment
(DynamicRIO, etc.), a probe tools (uprobes, systemtap, etc. which might not fit
the model you are aiming since it might not run in the process namespace), or
recompile glibc to remove the hidden_def definition on the symbol (so PLT are 
generated for internal calls and LD_PRELOAD can override it). 

> 
> In any event, my question is: is there a sanctioned or semi-sanctioned way
> to override system calls for both the static and dynamic linking process?
> 
>  - Godmar

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-09-26 11:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-22 12:31 What are the option for overriding system calls GNU libc calls? Godmar Back
2022-09-26 11:57 ` Adhemerval Zanella Netto

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 read-only IMAP folder(s) and NNTP newsgroup(s).