[SR-Users] Re: TLS module crashes with FIPS OpenSSL
Can you try with kamailio ... --atexit=no On Tue, 14 May 2024, 13:13 Marat Gareev via sr-users, < sr-users@lists.kamailio.org> wrote: > Hello again, > > I've updated Kamailio to 5.7.5, set tls_threads_mode=2 and got another > segfault: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7f26bb352efd in __strlen_avx2 () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > kamailio-5.7.5-4817.x86_64 > (gdb) bt > #0 0x7f26bb352efd in __strlen_avx2 () from /lib64/libc.so.6 > #1 0x7f26bb31a278 in __vfprintf_internal () from /lib64/libc.so.6 > #2 0x7f26bb3dd4ea in __vsyslog_internal () from /lib64/libc.so.6 > #3 0x7f26bb3dd9ca in syslog () from /lib64/libc.so.6 > #4 0x0071e574 in qm_debug_check_frag (qm=0x7f26aa4ee000, > f=0x7f26aa638388, file=0x7f26baa5b0b6 "tls: tls_init.c", line=399, > efile=0x8abb39 "core/mem/q_malloc.c", eline=526) at core/mem/q_malloc.c:126 > #5 0x007227c3 in qm_free (qmp=0x7f26aa4ee000, p=0x7f26aa6383c0, > file=0x7f26baa5b0b6 "tls: tls_init.c", func=0x7f26baa5cdb8 "ser_free", > line=399, mname=0x7f26baa5b0b2 "tls") at core/mem/q_malloc.c:526 > #6 0x0072d2c9 in qm_shm_free (qmp=0x7f26aa4ee000, p=0x7f26aa6383c0, > file=0x7f26baa5b0b6 "tls: tls_init.c", func=0x7f26baa5cdb8 "ser_free", > line=399, mname=0x7f26baa5b0b2 "tls") > at core/mem/q_malloc.c:1364 > #7 0x7f26baa12ea9 in ?? () > #8 0x7f26aa6383c0 in ?? () > #9 0x01b3ba70914b in ?? () > #10 0x7f26ba853e4b in ?? () from /lib64/libcrypto.so.3 > #11 0x7f26aa6383c0 in ?? () > #12 0x7f26aa6383c0 in ?? () > #13 0x7f26ba61cfc5 in conf_modules_finish_int () from > /lib64/libcrypto.so.3 > #14 0x7f26ba61d694 in CONF_modules_unload () from /lib64/libcrypto.so.3 > #15 0x7f26ba6c0ff9 in OPENSSL_cleanup () from /lib64/libcrypto.so.3 > #16 0x7f26baa1a21e in ?? () > #17 0x0001000623b0 in ?? () > #18 0x7f26aa5276c8 in ?? () > #19 0x7ffd66587330 in ?? () > #20 0x0071e0a0 in futex_release (lock=0x7f26bb3dd930 ) at > core/mem/../mem/../futexlock.h:134 > #21 0x006e993e in destroy_tls () at core/tls_hooks.c:75 > #22 0x0041f278 in cleanup (show_status=1) at main.c:595 > #23 0x00420af1 in shutdown_children (sig=15, show_status=1) at > main.c:722 > #24 0x00421717 in handle_sigs () at main.c:753 > #25 0x00430c88 in main_loop () at main.c:1989 > #26 0x00439d13 in main (argc=14, argv=0x7ffd66587d08) at main.c:3213 > (gdb) > > > > And yes, the problem is definitely related to FIPS, because I did not see > any errors with regular OpenSSL 3.x. > > пн, 13 мая 2024 г. в 13:39, Marat Gareev : > >> Hello Henning, >> >> yes, I use this major version >> >> $ openssl version >> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) >> >> Thanks, I'll try updating Kamailio and report the results. >> >> >> пн, 13 мая 2024 г. в 13:19, Henning Westerholt : >> >>> Hello, >>> >>> >>> >>> are you on openssl 3.x by any chance? If yes, please upgrade to kamailio >>> 5.7.5 or 5.8.1 and set tls_thread_mode=2 in the kamailio.cfg, as it fixes >>> certain memory corruption issues on this openssl version. >>> >>> If you are still getting crashes after the upgrade and setting, please >>> let us know, it might be something related to the FIPS mode. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Henning >>> >>> >>> >>> *From:* Marat Gareev via sr-users >>> *Sent:* Montag, 13. Mai 2024 09:19 >>> *To:* Kamailio (SER) - Users Mailing List >>> *Cc:* Marat Gareev >>> *Subject:* [SR-Users] TLS module crashes with FIPS OpenSSL >>> >>> >>> >>> Hello, >>> >>> >>> >>> I encountered a problem stopping Kamailio with FIPS OpenSSL: >>> >>> >>> >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> >>> #0 0x7ff7292380ac in OPENSSL_sk_pop () from /lib64/libcrypto.so.3 >>> >>> Missing separate debuginfos, use: dnf debuginfo-install >>> kamailio-5.7.3-4816.x86_64 >>> >>> (gdb) bt >>> >>> #0 0x7ff7292380ac in OPENSSL_sk_pop () from /lib64/libcrypto.so.3 >>> >>> #1 0x7ff72914bf5b in conf_modules_finish_int () from >>> /lib64/libcrypto.so.3 >>> >>> #2 0x7ff72914c694 in CONF_modules_unload () from /lib64/libcrypto.so.3 >>> >>> #3 0x7ff7291efff9 in OPENSSL_cleanup () from /lib64/libcrypto.so.3 >>> >>> #4 0x7ff72954702b in ?? () >>> >>> #5 0x000100061c08 in ?? () >>> >>> #6 0x7ff7190566c8 in ?? () >>> >>> #7 0x7ffccf196a20 in ?? () >>> >>> #8 0x0071da8a in futex_release (lock=0x7ff729f08b50 ) at >>> core/mem/../mem/../futexlock.h:134 >>> >>> #9 0x006e9448 in destroy_tls () at core/tls_hooks.c:75 >>> >>> #10 0x0041f278 in cleanup (show_status=1) at main.c:594 >>> >>> #11 0x00420af1 in shutdown_children (sig=15, show_status=1) at >>> main.c:721 >>> >>> #12 0x00421717 in handle_sigs () at main.c:752 >>> >>> #13 0x00430c88 in main_loop () at main.c:1988 >>> >>> #14
[SR-Users] Re: TLS module doesn't support TLSV1
Check how libssl3 is configured in /etc/ssl/openssl.cnf. You may need: [system_default_sect] MinProtocol = TLSv1.0 CipherString = ALL@SECLEVEL=0 From: https://serverfault.com/questions/1143995/tls-1-0-broken-with-newer-debian-openssl Regards Richard __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtimer intermittent failures
In the method can you put
return 1
at the end. KEMI python is very strict on an int return value.
On Tue, 5 Mar 2024, 07:08 Marrold via sr-users,
wrote:
> Hi all,
>
> I am using Kamailio 5.7.4 on a Debian 12 machine, with a Python Kemi based
> config. I am seeing some intermittent failures when accessing an instance
> variable within a function called by rtimer.
>
> I'm using the rtimer module with the following parameters:
>
> modparam("rtimer", "timer", "name=hello;interval=5;mode=0;")
> modparam("rtimer", "exec", "timer=hello;route=ksr_route_hello")
>
> I initialise the kamailio class, and instance variable like this:
>
> class kamailio:
> def __init__(self):
>
> self.hello = "hi"
>
> Within the class I have the following route function:
>
> def ksr_route_hello(self, msg, evname):
>
> KSR.info("Running ksr_route_hello\n")
> KSR.info(f"Hello? {self.hello}\n")
>
> Then in the logs I see it sometimes works, and sometimes fails:
>
> 9(15) INFO: [core/kemi.c:106]: sr_kemi_core_info(): Running
> ksr_route_hello
> 9(15) INFO: [core/kemi.c:106]: sr_kemi_core_info(): Hello? hi
>
> 9(15) INFO: [core/kemi.c:106]: sr_kemi_core_info(): Running
> ksr_route_hello
> 9(15) ERROR: app_python3 [python_support.c:167]:
> python_handle_exception(): apy_exec: ksr_route_hello(rtimer): Unhandled
> exception in the Python code:
> TypeError: 'NoneType' object cannot be interpreted as an integer
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File "/etc/kamailio/kamailio.py", line 1007, in ksr_route_hello
> KSR.info("Running ksr_route_hello\n")
> SystemError: returned a result with an exception
> set
>
> Does anyone know where I'm going wrong?
>
> Thanks
> Matthew
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: [sr-dev] Re: Roadmap to next major Kamailio release series v5.8.x
Hi Daniel
===
For the upgrading notes, some ideas —
"tls.so: fixing GH#3635 new global config tls_threads_mode = 0 | 1
0: is the default and is the existing Kamailio behaviour
1: run some initialization functions(libcurl, database) in a thread to
avoid creating thread-locals in thread#1 before fork
On platforms with OpenSSL 3 "tls_threads_mode = 1" is needed to avoid
shared memory contention, especially if other modules (eg. db_mysql,
http_async_client, dispatcher with SIPS URIs) that might use TLS are loaded.
On platforms with OpenSSL 1.1.1 — shared memory contention is much harder
to trigger — but this setting is recommended when other modules that use
TLS are loaded"
===
Deployment note (for the wiki?)
Here is an SRE/deployment note — not sure of a good place to put this
(maybe the wiki)
"To validate the config for OpenSSL 3/1.1.1 memory contention potential run
the main kamailio process
under gdb (don't follow child forks: "set follow-fork-mode parent" — the
default setting anyway)
# ** EITHER **
# deb-based: install dbgsym for libssl3 / libssl1.1
# RPM-based: install debuginfo for openssl, openssl-libs
# ** OR **
# configure gdb to use debuginfod for debug symbols
# STEP 1
# stop at main(), this step is required because the next breakpoint
requires knowledge
# of thread#1
gdb> break main
gdb> run
# STEP 2
# this breakpoint detects if OpenSSL 3 initializes the thread-local
err_thread_local
# in process#0.thread#1 — this causes shared memory contention
gdb> breakpoint CRYPTO_THREAD_set_local thread 1 if
$_caller_is("ossl_err_get_state_int", 32)
gdb> commands
backtrace 32
continue
end
##For OpenSSL 1.1.1
gdb> breakpoint CRYPTO_THREAD_set_local thread 1 if
$_caller_is("ERR_get_state", 32)
gdb> commands
backtrace 32
continue
end
# continue execution of Kamailio
gdb> continue
If this breakpoint is triggered then the configuration has potential for
shared memory contention.
Do file an issue at GH with your configuration and the gdb output.
"
Dev note: I have completed an "audit" of all in-tree modules that load
libssl — libcurl, libmariadb, libcrypto, libpq etc. The only one not
touched is DIAMETER cdp.so with TLS. If anyone uses this and can provide me
with temporary access that would be great.
Regards
Richard
On Tue, 27 Feb 2024 at 23:55, Daniel-Constantin Mierla via sr-dev <
sr-...@lists.kamailio.org> wrote:
> Hello,
>
> I propose to aim to get out 5.8.0 next week on Wednesday or Thursday
> (March 6 or 7, 2024). I haven't seen much activity around issues in the
> new features/modules. If time allows to build the pages for what-is-new
> and how-to-upgrade (which I think it should be rather minimal), then I
> think it should be no other major task. Overall it will be almost two
> weeks since the 5.8 branch was created.
>
> Cheers,
> Daniel
>
> On 23.02.24 12:11, Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > quick note that later today I will create the branch 5.8, notification
> > emails will be sent once done.
> >
> > Cheers,
> > Daniel
> >
> > On 16.02.24 08:01, Daniel-Constantin Mierla wrote:
> >> Hello,
> >>
> >> hopefully the devel version is now more stabilized after the freezing,
> >> the new components being adjusted enough not to need many more changes.
> >> Therefore I consider to branch 5.8 out of devel version next week on
> >> Friday, February 23, 2024, sometime around noon UTC.
> >>
> >> After that the master branch becomes open for new features, and branch
> >> 5.8 has to be hammered further to build the 5.8.x series.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On 10.01.24 10:11, Daniel-Constantin Mierla wrote:
> >>> Hello,
> >>>
> >>> discussed a bit during the online Kamailio devel meeting, it is time to
> >>> set the milestones towards the next major Kamailio release series
> v5.8.x.
> >>>
> >>> If no other suggestions that suit more developers, I would propose to
> >>> freeze by end of this month or early February, then test for about 4
> >>> weeks as usual and release by end of February or during March.
> >>>
> >>> If anyone wants to add new features/modules, they have to be published
> >>> till freezing date, either pushed in the git repository or proposed as
> >>> pull request.
> >>>
> >>> Cheers,
> >>> Daniel
> >> --
> >> Daniel-Constantin Mierla (@ asipto.com)
> >> twitter.com/miconda -- linkedin.com/in/miconda
> >> Kamailio Consultancy, Training and Development Services -- asipto.com
> >> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> >> Kamailio World Conference, April 18-19, 2024, Berlin --
> kamailioworld.com
> >>
> > --
> > Daniel-Constantin Mierla (@ asipto.com)
> > twitter.com/miconda -- linkedin.com/in/miconda
> > Kamailio Consultancy, Training and Development Services -- asipto.com
> > Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> > Kamailio World Conference, April 18-19, 2024, Berlin --
> kamailioworld.com
> >
> --
> Daniel-Constantin Mierla (@ asipto.com)
>
[SR-Users] Heads-up: testing needed for major OpenSSL refactoring
Hello Kamailio community, After the January refactoring of OpenSSL integration, configurations that initialise libssl in rank 0 (thread #1) are likely to trigger errors more aggressively. This type of configuration has all along been broken due to OpenSSL use of thread-local variables. The first "victim" is https://github.com/kamailio/kamailio/issues/3727 — the configuration has dispatcher + db_unixodbc (+ some driver) — this configuration initialises libssl in rank 0(thread #1). I have a couple of PRs in the queue for db_unixodbc, db_mysql (PostgreSQL may need similar attention). master and 5.7 branches are affected Regards Richard __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] defexps not working as expected
In the config file:
#!define KEYVALUE "key=s:value"
modparam("pv", "varset", KEYVALUE)
works. But if I try to use defexp or defexps the ID KEYVALUE
is not set as expected and the parser complains.
## this doesn't parse
#!defexp KEYVALUE2 "key=s:value"
#!defexps KEYVALUE3 "key=s:value"
# both these lead to syntax error
modparam("pv", "varset", KEYVALUE2)
modparam("pv", "varset", KEYVALUE3)
Any ideas why defexp doesn't behave the same way here?
Shih-Ping
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Dispatcher HA:won't route headers be wrong if in-dialog request is sent to backup?
Hi sr-users, In the case of dispatcher-based HA such as the Wazo example ( https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq) won't the Route: headers be wrong for in-dialog requests if the request is sent to the backup proxy? front proxy -> proxy A, B, C, D,... -> network Suppose the INVITE goes through proxy A, then proxy A goes down. Based on the HA logic, an in-dialog request will go to a backup, say, proxy B. However, won't the Route headers be wrong (since they are placed by A) in the original transaction? How do you handle Route:, Record-Route: headers at the HA tier? 1. In the front proxy & HA tier don't use route headers at all ?? 2. Manually check and remove route headers (i.e proxy B treats route headers for proxy A as "myself") ?? I am curious as to what is your practice. Regards Shih-Ping __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio behind TLS-TCP load balancer
On Sat, 12 Aug 2023, 09:19 David Villasmil, > I found I need to manually add record-route presets every time and invite > comes in. And when trying to forward an ACK to the client via tls/tcp load > balancer Kamailio complaint the socket is not TLS so it fails. > Have you tried forcing TCP with t_relay_to_tcp? __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio as SIP proxy for an Asterisk with Private IP Address
On Mon, 24 Jul 2023 at 18:47, Alex Balashov wrote: > Hello John, > > If that's the goal per se, you will likely need to use the Path[1][2][3] > extension, which allows a proxy to stay in the signalling path of > non-adjacent registration contacts. > > This is assuming the Asterisk project have fixed their long-standing Path > bug in `chan_pjsip`, which they have hitherto refused to fix for several > years. If not, you may have to engage in some hacky stateful Contact > rewriting in lieu of Path. > For future googlers and future me: you will need Asterisk ≥ 18.17.0, 20.2.0 to have fixed Path support in chan_pjsip. https://issues.asterisk.org/jira/browse/ASTERISK-30100 Those are very recent versions of Asterisk. For kamailio config you could take a look at the sample config of the outbound module: this loads the path module and adds suitable Path headers towards an internal registrar. However, as Alex mentioned, this whole thing is quite fraught. It depends on the registrar storing the Path header, and using it on INVITE - which was the problem with earlier versions of Asterisk. Regards Richard __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] CANCEL timeout in branch route does not trigger any failure routes
Hi Kamailio users How can I get a failure route to trigger in timeout-to-CANCEL in a parallel forking scenario? Parallel forking test scenario 1. one(the main - 0) branch picks up the call 2. 2nd branch sends CANCEL (expecting 487 etc) - but the callee does not send any replies Result: No failure route handlers are called on timeout of this CANCEL - that is kamailio attempts the CANCEL 4 times but neither tm.t_on_failure_route, tm.t_on_branch_failure handlers are called. Any suggestions on how to resolve this? Regards Shih-Ping __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] ClueCon and ... FreeSWITCH 1.10.8/RHEL8 packages!
Hi sr-users, Since ClueCon is going on right now, and some Kamailio community members are involved I hope you will forgive a little promo here: I have a RHEL8 build of the just released 1.10.8 on Copr: https://copr.fedorainfracloud.org/coprs/beaveryoga/FreeSWITCH-1.10.8/ Hope you will find it useful in your kamailio + Class 5 scenarios! Cheers Shih-Ping __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] tls_wolfssl talk at KWO: traffic generation scripts are online
Hi sr-users,
The TLS traffic generation scripts are online here:
* SIP library - fork of sippy/b2bua - use main-async branch
https://github.com/space88man/b2bua
This branch is an async refactoring of sippy; the master branch of the repo
is the regular sync+elperiodic version.
* runtime UA generation scripts:
https://github.com/space88man/multiuac-tester
This repo contains the TLS-client transport (sippy out-of-the-box supports
UDP); also gratuitously uses the match/case syntax for fun (so needs Python
3.10)
* no documentation: the scripts/t_register.py and scripts/t_phone.py should
give you an idea how to create UACs.
The script in the talk is scripts/t_register.py - creates SIP UACs that sit
in an infinite loop and do REGISTER and keepalive ('\r\n\r\n').
Disclaimer: this is not a SIP-scenario framework like SIPp; SIP messages
are programmatically created using sippy; e.g., the test scenario does not
need to handle RTP media so the SDP body is a hardcoded string.
Regards
S-P
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Request rpms for 5.6.1
Hi kamailio team, I'd like to request that 5.6.1 be added to rpm.kamailio.org. Thanks! S-P Chan __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Does pure outbound RFC5626 work without edge proxies?
Hi sr-users, Does pure RFC5626 outbound work without an edge proxy->internal proxy design? By "pure" I mean no nathelper to rewrite addresses. I tried setting up the following: Configuration: use standard kamailio configuration without WITH_NAT (Ignore RTP-rtpengine/rtpproxy for the moment as I am just testing the control plane) 1. UA1 UA2 each behind NAT, with bogus Contact: headers 2. kamailio loaded with rr/tm (no outbound/path because I am using single proxy/registrar — without edge proxies) 3. no nathelper: no Contact rewriting, set_contact_alias etc 4. Both UA1 and UA2 establish persistent TLS to kamailio 5. INVITE/200 OK/ACK does work. 6. Contact headers show the NAT bogus addresses (as expected). UA1/UA2 are configured to be "dumb"(i.e. don't self-rewrite Contact:/SDP based on rport/received). Problem: 7. In-dialog requests don't work as kamailio tries to route to the bogus addresses per the Contact header. I.e. kamailio doesn't seem to resolve the UAs(bogus Contact addresses) to the persistent TLS connections. Now in the Route header I don't see any flow-token so probably kamailio is doing "normal" routing instead of RFC5626 routing (i.e. because it has no flow-token to match with an existing flow). This leads me to ask: for pure RFC5626 to work (no nathelper stuff at all) is it a must that there is a "edge-proxy--[1]-->internal-proxy" layout? ...and...the flow-tokens in [1] are what make it possible to skip bogus Contact: header and route to an existing flow? Regards Shih-Ping Chan __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] What is the alignment of shm_malloc and friends?
Hello Daniel, On Mon, 20 Jun 2022 at 19:09, Daniel-Constantin Mierla wrote: > Hello, > > iirc, the alignment is to sizeof(void*), which is 8. > The qm allocator naturally returns 16-byte aligned memory. However the definition of DBG_SR_MEMORY(from 'make cfg' with all the defaults.) causes 16 to drop to 8. Is this intentional? Regards S-P //qm naturally aligns on 16 bytes without DBG_QM_MALLOC! #ifdef DBG_QM_MALLOC #if defined(__CPU_sparc64) || defined(__CPU_sparc) /* tricky, on sun in 32 bits mode long long must be 64 bits aligned * but long can be 32 bits aligned => malloc should return long long * aligned memory */ #define ROUNDTO sizeof(long long) #else #define ROUNDTO sizeof(void*) /* minimum possible ROUNDTO * ->heavy debugging*/ #endif #else /* DBG_QM_MALLOC */ #define ROUNDTO 16UL /* size we round to, must be = 2^n and also * sizeof(qm_frag)+sizeof(qm_frag_end) * must be multiple of ROUNDTO! */ #endif __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] What is the alignment of shm_malloc and friends?
On Mon, 20 Jun 2022 at 7:09 PM, Daniel-Constantin Mierla wrote: > Hello, > > iirc, the alignment is to sizeof(void*), which is 8. > > I haven't met cases when the alignment is required to be different that > the size of the pointer/memory address. Any particular reason for > wolfssl to require that? > > https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html Modern malloc/realloc return 16 byte aligned memory on 64bit systems so 3rd party libraries now assume this behaviour. wolfSSL has some optimisations with aligned data and Debian has this flag on by default in 5.2.0. I did verify that without this flag existing shm functions work. With this flag turned on Kamailio will segfault unless I add wrappers to align up to 16 bytes. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] What is the alignment of shm_malloc and friends?
Hi Daniel and kamailio users, In my integration adventure of wolfSSL and kamailio I have encountered an alignment issue sometime causing segfaults. May I enquire what is the alignment of shm_malloc and friends? The wolfSSL library integration requires that ser_malloc and ser_realloc return values aligned on alignof(_max_align_t) which in the case of x86_64 is 16. Thank you Shih-Ping __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Testers wanted for new TLS transport based on wolfSSL
Hello Kamailio users, I would like testers to try out a new module tls_wolfssl, an alternate TLS transport based on wolfSSL. Why another TLS transport implementation? The travails of using OpenSSL >= 1.1.1 in Kamailio’s multi-process paradigm has been documented by OpenSIPS (and that sister project has implemented tls_wolfssl). Essentially, OpenSSL makes no concessions to the multi-process use case and in fact has implementation details that work against global shared memory structures. As a result Kamailio contains some tricky code * a pthread polyfill in core * duplicated SSL_CTX per worker * atexit workaround How to test? The code is currently in master and can be built in the usual way. Debian has 5.2.0 libwolfssl-dev needed; for some RPM distros (el8, el9, fc36) I have created a Copr repository https://copr.fedorainfracloud.org/coprs/beaveryoga/wolfSSL/ Known limitations The current state can be considered as identical to tls+OpenSSL 1.1.1/3.0.x. Old TLS protocols < 1.2 and cipher list configuration don’t work, i.e., only TLS 1.2 and 1.3 work with the default cipher list. In your configuration just replace loadmodule “tls.so” with loadmodule “tls_wolfssl.so” The rest of the TLS configuration can remain unchanged unless you are using a funky protocol version/cipher list combination. Thanks! S-P __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
