Re: SHA-256

[Helmut K. C. Tessarek]

Thank you for the response.

On 2017-02-24 23:45, William A Rowe Jr wrote:
> They are useful for file completeness/error checking only. I'd agree 
> there is zero purpose in retaining SHA1 when SHA256 is in place.

Unfortunately a lot of people do not know this. They compare the hashes
instead, either because they don't understand the background, don't have
gpg installed, or think checking the hashes is the same as verifying a
signature.

> And SHA256 is a means to authenticate how, exactly?
> 
> We provide .asc pgp signatures exclusively for that purpose.

I agree, gpg is the only way to check the authenticity of a file.

However, people who use hashes to do this (for reasons I previously
mentioned) are in a lot safer spot, because it's most likely impossible
for an adversary to create a collision.

I just didn't understand why there would be a reason for other hashes,
if there was as sha-256 hash available. Even on legacy systems I've seen
implementations for sha256.

Thanks again for your answer.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/

Re: SHA-256

[William A Rowe Jr]

On Fri, Feb 24, 2017 at 12:02 PM, Yann Ylavic  wrote:
> On Fri, Feb 24, 2017 at 6:52 PM, Jim Jagielski  wrote:
>> I think we should start, in addition to "signing" w/ md5 and sha-1,
>> using sha-256 as well.
>>
>> Sound OK?
>
> Our "true" signing has and will always be PGP.
> Though SHA-256 is often asked by users@, so,
> +1

+1 to adding SHA-256, +/-0 for SHA-512 at this point in time.
With that change, +1 to removing SHA-1, and +/-0 to retaining MD5.

One modern sha hash is sufficient to verify the transmission,
and these hashes may only be used for that purpose. I'm ok with
retaining MD5 simply because a tiny number of downloaders will
have no SHA hash validation tool at hand. It's still sufficient to check
that the download was not corrupted.

If we dig through our site and delete all references to 'signature'
with respect to any hashes, how do we refer to these. This is what
autoindex reports from www.a.o/dist/...

 httpd-2.2.32.tar.bz2.asc2017-01-12 18:38  801   PGP signature
 httpd-2.2.32.tar.bz2.md52017-01-12 18:38   55   MD5 hash

Good there, no claim that this is a signature.

In the corresponding README in /dist/httpd, we state

"We offer MD5 hashes as an alternative to validate the integrity of
the downloaded files. A unix program called md5 or md5sum is included
in many unix distributions. It is also available as part of GNU
Textutils. Windows users can get binary md5 programs from here, here,
or here."

That message should be split out from 'PGP Signatures' and then
we can add the openssl command line syntax for sha validation.

There are other issues with downloads.html which I'm working up
a patch for already, but let's go ahead and do this. We made little
mention of .sha1 in our docs, so replacing these with .sha256 is
a no-brainer.

Re: SHA-256

[William A Rowe Jr]

On Fri, Feb 24, 2017 at 2:30 PM, Helmut K. C. Tessarek
 wrote:
> On 2017-02-24 12:52, Jim Jagielski wrote:
>> I think we should start, in addition to "signing" w/ md5 and sha-1,
>> using sha-256 as well.
>
> I have a question: why are you still using md5/sha1 for generating file
> hashes in the first place?
>
> Noone with knowledge of hashing algos would use these hashes to validate
> a file's authenticity.

Uhm, noone uses hashes to validate authenticity unless they are transmitted
through an entirely distinct channel. E.g. not your internet connection.

They are useful for file completeness/error checking only. I'd agree there is
zero purpose in retaining SHA1 when SHA256 is in place. MD5 has the one
distinction of being ubiquitous even on ancient OS's.

> Bottom line is that you lull people into a false sense of security by
> providing md5/sha1 hashes. People, who don't know that these algorithms
> have been broken already, might think that they are safe (by checking
> the file against the md5 hash) while in reality they are not.

And SHA256 is a means to authenticate how, exactly?

We provide .asc pgp signatures exclusively for that purpose.

Re: [users@httpd] Problem when using nested if statements in apache 2.4

[Luca Toscano]

Hi everybody,

the following users@ question is interesting in my opinion:

2017-02-20 18:17 GMT+01:00 Mike Schlottman :

>
> The problem comes when I combine these 2 so that all users except those
> coming from 127.*.*.* or 192.168.*.* see the nice error page.
>
> 
>
>   
>
> ErrorDocument 404 /errors/404
>
>   
>
> 
>
> The user from 172.28.1.84 does not get the nice 404 page, but the default
> 404 page.   The IP does not match either of the ranges as observed when
> using the ranges individually, but when combined in this way it does not
> work as expected.
>
>
>
> Any ideas why this is?
>
>
>

He ended up using a single if with an expression composed by the two
conditions in && to solve the problem, but I started to wonder why this
configuration does not work. I tested the "nested ifs" config with trace8
logging and it seem that only the outermost  expression gets evaluated.

Is there a specific reason why this happens? I'd expect two possible
outcomes from this configuration, namely either a syntax error while
parsing the config (preferred imho) or a context merge, but not a no-op.

Any pointers/suggestions about where to look?

Thanks!

Luca

Re: SHA-256

[Jacob Champion]

On 02/24/2017 10:02 AM, Yann Ylavic wrote:

Our "true" signing has and will always be PGP.
Though SHA-256 is often asked by users@, so,
+1


+1

--Jacob

Re: SHA-256

[Helmut K. C. Tessarek]

On 2017-02-24 12:52, Jim Jagielski wrote:
> I think we should start, in addition to "signing" w/ md5 and sha-1,
> using sha-256 as well.

I have a question: why are you still using md5/sha1 for generating file
hashes in the first place?

Noone with knowledge of hashing algos would use these hashes to validate
a file's authenticity.

Bottom line is that you lull people into a false sense of security by
providing md5/sha1 hashes. People, who don't know that these algorithms
have been broken already, might think that they are safe (by checking
the file against the md5 hash) while in reality they are not.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Yann,

here we go:

(gdb) p *ipsub
$1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
4294967295, 4294967295, 4294967295}}

(gdb) p *sa
$2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 ,
  servname = 0x17d01040405 , port = 770, family = 554829073,
  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
ipaddr_ptr = 0x24f0d15215c1b142,
  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
9498, sin_addr = {s_addr = 690497318},
  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
909456426, 976828471, 1178944579, 1246316615}}},
sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
  __ss_align = 4195446337656140842,
  __ss_padding =
"CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}

(gdb) p *(struct in6_addr *)sa
$3 = {__in6_u = {__u6_addr8 =
"\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
__u6_addr16 = {2826, 50431, 46336,
  16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
50528514, 84083714}}}


Stefan

Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
> Hi Stefan (Priebe),
> 
> Is IPv6 (really) involved in your network?
> 
> Could you please show up the gdb output of the below ?
> 
> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>>
>> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
>> apr_sockaddr_t *sa)
>> 1079 {
>> 1080 #if APR_HAVE_IPV6
>> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
>> 1082  * but without the IPV6 drivers installed.
>> 1083  */
>> 1084 if (sa->family == AF_INET) {
>> 1085 if (ipsub->family == AF_INET &&
>> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
>> ipsub->sub[0])) {
>> 1087 return 1;
>> 1088 }
>> 1089 }
>> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
>> 1091 if (ipsub->family == AF_INET &&
>> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
>> ipsub->mask[0]) == ipsub->sub[0]) {
>> 1093 return 1;
>> 1094 }
>> 1095 }
> 
> (gdb) p *ipsub
> (gdb) p *sa
> (gdb) p *(struct in6_addr *)sa
> 
> and possibly more to come...
> 
> 
> Thanks,
> Yann.
> 

Re: SHA-256

[Yann Ylavic]

On Fri, Feb 24, 2017 at 6:52 PM, Jim Jagielski  wrote:
> I think we should start, in addition to "signing" w/ md5 and sha-1,
> using sha-256 as well.
>
> Sound OK?

Our "true" signing has and will always be PGP.
Though SHA-256 is often asked by users@, so,
+1

Re: SHA-256

[Dirk-Willem van Gulik]

On 24 Feb 2017, at 18:52, Jim Jagielski  wrote:
> 
> I think we should start, in addition to "signing" w/ md5 and sha-1,
> using sha-256 as well.
> 
> Sound OK?

That seems to match the advice of NIST, E-CRYPT and the BSI on


https://www.nrc.nl/nieuws/2017/02/24/zelfrijdende-auto-google-uber-stal-onze-robotauto-6964363-a1547533
 


none of which seems that eager to push us to 385 or 512 for the next 4 years. 

Though if we are updating the scripts - perhaps add sha-512 - just to 
‘socialize’ it early.

Dw.

SHA-256

[Jim Jagielski]

I think we should start, in addition to "signing" w/ md5 and sha-1,
using sha-256 as well.

Sound OK?

Re: mod_remoteip and mod_http2 combined

[Sander Hoentjen]

On 02/20/2017 07:48 PM, William A Rowe Jr wrote:
> On Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri  wrote:
>> On 2017-02-15 09:07 (-0600), William A Rowe Jr  wrote:
>>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen  wrote:
 mod_remote ip has:
 /* mod_proxy creates outgoing connections - we don't want those */
 if (!remoteip_is_server_port(c->local_addr->port)) {
 return DECLINED;
 }
 I am guessing something similar is needed for h2 connections?
>>> I suspect that the mod_remoteip logic is wrong, that it should be guarding
>>> against any subordinate connections and examining only explicitly configured
>>> ports / origin IPs. the PROXY protocol is not part of the HTTP protocol and
>>> incompatible with it, so the trust list logic isn't directly compatible 
>>> (this is
>>> clearly explained in the PROXY pseudo-RFC.)
>>>
>> Hi, Bill. That is what the module is doing. The original authors wrote it to 
>> have a list of virtual hosts it is explicitly enabled for and explicitly 
>> disabled for. I added a third list for optional vhosts. In the 
>> pre_connection hook, it checks to see if the connection's local_addr (which 
>> should normally be the server's IP) is explicitly configured to enable PROXY 
>> handling. It then checks to see if the local port is a server port.
>>
>> Looking at the logs shared, 192.168.122.249:84 is the server IP:Port combo 
>> and is also the local IP:Port from mod_h2. If h2 sets the master of this 
>> connection, then we could skip the whole ordeal with this patch:
>>
>> Index: modules/metadata/mod_remoteip.c
>> ===
>> --- modules/metadata/mod_remoteip.c (revision 1781701)
>> +++ modules/metadata/mod_remoteip.c (working copy)
>> @@ -862,6 +862,10 @@
>>  remoteip_conn_config_t *conn_conf;
>>  int optional;
>>
>> +if (c->master != NULL) {
>> +return DECLINED;
>> +}
>> +
>>  conf = ap_get_module_config(ap_server_conf->module_config,
>>  _module);
>>
>> .. but I don't know if that potentially means we are looking at the wrong 
>> connection.
First I'll say that with the "Optional" mode it worked, just not with On
I just tried this patch and as far as I have tested this seems to work
fine in On mode, as well as in Optional. I do see some other issue, but
that is probably in my own code, I'll try to track that down later.
> That should be close, but need to ensure c->master is initialized for
> http as well
> where there is no master/subordinate.
I am not sure what this means, how should I test this?
>
> If the 'optional' (unwise) feature were removed, the decision to
> inject the filter before
> the http or h2 filter would be trivial, it would step out of the way
> after the first-pass
> (and perhaps not need to live on the filter stack at all - if we do a
> fixed read against
> the core filter - we hopefully know the number of bytes affected early
> and can then
> do a second read to complete the v1 vs v2 read?) --- all before we are
> in a multiple
> pipeline state.
>
> If we move to a conn_rec oriented one-shot nothing happens during the request
> phase at all.
>
> By looking at the protocol filter stack, we should be able to glean
> whether we are
> talking to the core filter, or an 'unexpected' non-network filter, right?
>
I myself have no use-case at the moment for the "Optional" mode, maybe
others do.

Re: release v1.9.0

[Yann Ylavic]

On Fri, Feb 24, 2017 at 5:39 PM, Stefan Priebe - Profihost AG
 wrote:
> No we don't use IPv6 at all. Do you still need those values?

Yes please.

Regards,
Yann.

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

No we don't use IPv6 at all. Do you still need those values?

Greets,
Stefan

Excuse my typo sent from my mobile phone.

> Am 24.02.2017 um 14:18 schrieb Yann Ylavic :
> 
> Hi Stefan (Priebe),
> 
> Is IPv6 (really) involved in your network?
> 
> Could you please show up the gdb output of the below ?
> 
>> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>> 
>> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
>> apr_sockaddr_t *sa)
>> 1079 {
>> 1080 #if APR_HAVE_IPV6
>> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
>> 1082  * but without the IPV6 drivers installed.
>> 1083  */
>> 1084 if (sa->family == AF_INET) {
>> 1085 if (ipsub->family == AF_INET &&
>> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
>> ipsub->sub[0])) {
>> 1087 return 1;
>> 1088 }
>> 1089 }
>> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
>> 1091 if (ipsub->family == AF_INET &&
>> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
>> ipsub->mask[0]) == ipsub->sub[0]) {
>> 1093 return 1;
>> 1094 }
>> 1095 }
> 
> (gdb) p *ipsub
> (gdb) p *sa
> (gdb) p *(struct in6_addr *)sa
> 
> and possibly more to come...
> 
> 
> Thanks,
> Yann.

Re: release v1.9.0

[Yann Ylavic]

Hi Stefan (Priebe),

Is IPv6 (really) involved in your network?

Could you please show up the gdb output of the below ?

On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>
> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
> apr_sockaddr_t *sa)
> 1079 {
> 1080 #if APR_HAVE_IPV6
> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
> 1082  * but without the IPV6 drivers installed.
> 1083  */
> 1084 if (sa->family == AF_INET) {
> 1085 if (ipsub->family == AF_INET &&
> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
> ipsub->sub[0])) {
> 1087 return 1;
> 1088 }
> 1089 }
> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
> 1091 if (ipsub->family == AF_INET &&
> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
> ipsub->mask[0]) == ipsub->sub[0]) {
> 1093 return 1;
> 1094 }
> 1095 }

(gdb) p *ipsub
(gdb) p *sa
(gdb) p *(struct in6_addr *)sa

and possibly more to come...


Thanks,
Yann.

Re: release v1.9.0

[Yann Ylavic]

On Fri, Feb 24, 2017 at 1:35 PM, Stefan Eissing
 wrote:
> Meh.
>
> Stefan: once during the last 2 days or several?
>
>
> This is accessing r->useragent_addr by mod_access_compat which is, for h2 
> slaves, initialized with c->client_addr.
>
> Since c->client_addr is always initialized by the master connection, I did 
> not see any race issues with sharing this across multiple slaves. Anyone has 
> an idea?

No idea, but don't see it related to http2, though.

I'm there:

1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
apr_sockaddr_t *sa)
1079 {
1080 #if APR_HAVE_IPV6
1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
1082  * but without the IPV6 drivers installed.
1083  */
1084 if (sa->family == AF_INET) {
1085 if (ipsub->family == AF_INET &&
1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
ipsub->sub[0])) {
1087 return 1;
1088 }
1089 }
1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
1091 if (ipsub->family == AF_INET &&
1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
ipsub->mask[0]) == ipsub->sub[0]) {
1093 return 1;
1094 }
1095 }
1096 else if (sa->family == AF_INET6 && ipsub->family == AF_INET6) {
1097 apr_uint32_t *addr = (apr_uint32_t *)sa->ipaddr_ptr;
1098
1099 if ((addr[0] & ipsub->mask[0]) == ipsub->sub[0] &&
1100 (addr[1] & ipsub->mask[1]) == ipsub->sub[1] &&
1101 (addr[2] & ipsub->mask[2]) == ipsub->sub[2] &&
1102 (addr[3] & ipsub->mask[3]) == ipsub->sub[3]) {
1103 return 1;
1104 }
1105 }
1106 #else
1107 if ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) == ipsub->sub[0]) {
1108 return 1;
1109 }
1110 #endif /* APR_HAVE_IPV6 */
 return 0; /* no match */
1112 }

=> IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)

Hmm...

Re: httpd 2.4.25, mpm_event, ssl: segfaults

[Niklas Edmundsson]

On Fri, 24 Feb 2017, Yann Ylavic wrote:


On Thu, Feb 23, 2017 at 8:50 PM, Jacob Champion  wrote:

Going off on a tangent here:

For those of you who actually know how the ssl stuff really works, is it
possible to get multiple threads involved in doing the encryption, or do
you need the results from the previous block in order to do the next
one?


I'm not a cryptographer, but I think how parallelizable it is depends on the
ciphersuite in use. Like you say, some ciphersuites require one block to be
fed into the next as an input; others don't.


Yes, and the cost of scheduling threads for non dedicated cypto device
is not worth it I think.
But mainly there is not only one stream involved in a typical HTTP
server, so probably multiple simulteneous connections already saturate
the AES-NI...


Actually, the AES-NI capability can be seen as a dedicated crypto 
device of sorts... It's just a bit more versatile with a CPU core 
stuck in there as well ;-)


I would much prefer if httpd could be able to push full bandwidth 
single-stream https using multiple cores instead of enticing users to 
use silly "parallel get" clients, download accelerators and whatnot.


Granted, the use cases are not perhaps the standard 
serve-many-files-to-the-public ones, but they do exist. And depending 
on which way the computing trends blow we might start seeing more 
competing low-power cpus with more cores and less capability requiring 
more threads to perform on single/few-stream workloads.


In any event I don't think the basic idea of multiple-thread-crypto 
should be dismissed lightly, especially if someone (definitely not me) 
figures out a neat way to do it :-)


Personally, it's the angst! of having to wait more than 10 seconds for 
a DVD-sized Linux-distro.iso download when I KNOW that there are 7 
cores idling and knowing that without the single-core bottleneck I 
would have 6 additionals seconds of time to spend on something useful 
8-()



/Nikke - thinking that the Subject is not that accurate anymore...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
 Sattinger's Law:  It works better if you plug it in.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: release v1.9.0

[Stefan Eissing]

Meh.

Stefan: once during the last 2 days or several?


This is accessing r->useragent_addr by mod_access_compat which is, for h2 
slaves, initialized with c->client_addr.

Since c->client_addr is always initialized by the master connection, I did not 
see any race issues with sharing this across multiple slaves. Anyone has an 
idea?

> Am 24.02.2017 um 12:33 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
>  Hi Stefan,
> 
> new trace:
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
>sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
> #0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
>sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
> #1  0x7f459573b400 in find_allowdeny (r=r@entry=0x7f44c002c250,
>method=method@entry=0, a=, a=)
>at mod_access_compat.c:270
> #2  0x7f459573b59a in check_dir_access (r=0x7f44c002c250)
>at mod_access_compat.c:324
> #3  0x560ce8333fd0 in ap_run_access_checker (r=0x7f44c002c250)
>at request.c:87
> #4  0x560ce8336ea8 in ap_process_request_internal (r=0x7f44c002c250)
>at request.c:265
> #5  0x560ce8377b40 in ap_process_async_request (r=0x7f44c002c250)
>at http_request.c:434
> #6  0x560ce8377cf0 in ap_process_request (r=0x7f44c002c250)
>at http_request.c:471
> #7  0x560ce83b8aad in h2_task_process_request (c=,
>task=) at h2_task.c:612
> #8  h2_task_process_conn (c=0x7f44c003d070) at h2_task.c:659
> #9  0x560ce8347fd0 in ap_run_process_connection (c=0x7f44c0026220)
>at connection.c:42
> #10 0x560ce83b9eaf in h2_task_do (task=0x7f44c002a240,
>thread=0x560ce8afc900, worker_id=365015362) at h2_task.c:578
> #11 0x560ce83c362f in execute (thread=0x560ce8afc900,
> wctx=0x560ce8afc8c0)
>at h2_worker.c:46
> #12 0x7f45967610a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #13 0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Stefan
> 
> Am 23.02.2017 um 07:59 schrieb Stefan Priebe - Profihost AG:
>> Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
>>> Hi Stefan,
>>> 
>>> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
>>>  wrote:
 
 @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
>>> 
>>> Yes, I think this is the right thing to do for now (no more patches than 
>>> v7).
>>> 
 Or
 do i need V8 or something else?
>>> 
>>> Not ready yet, I'll propose it when that's the case if you can test it then.
>>> That's an mpm_event optimization (hopefully) only, v7 is good from
>>> correctness POV...
>> 
>> OK it's running. Will report back.
>> 
>> Greets,
>> Stefan
>> 
>>> Thanks for testing, still!
>>> 
>>> Regards,
>>> Yann.
>>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: httpd 2.4.25, mpm_event, ssl: segfaults

[Niklas Edmundsson]

On Fri, 24 Feb 2017, Yann Ylavic wrote:


The issue is potentially the huge (order big-n) allocations which
finally may hurt the system (fragmentation, OOM...).



Is this a real or theoretical problem?


Both. Fragmentation is a hard issue, but a constant is: the more you
ask for big allocs, the more likely you won't be serviced one day or
another (or another task will be killed for that, until yours).

Long living (or closed to memory limits) systems suffer from this, no
matter what allocator, small and large allocations fragment the memory
(httpd is likely not the only program on the system), the only
"remedy" is small order allocations (2^order pages, a "sane" order
being lower than 2, hence order-1 on a system with 4K pages is 8K
bytes).


I've only seen this class of issues on Linux systems where 
vm.min_free_kbytes is left at default in combination with 
better-than-GigE networking. Since we started to tune 
vm.min_free_kbytes to be in the order of 0.5s bursts at 
maximum-network-speed (ie. 512M for 10GigE) we haven't seen it in 
production. I think our working theory was too little space to handle 
bursts resulted in the kernel unable to figure out which file cache 
pages to throw out in time, but I think we never got to figuring out 
the exact reason...





However, for large file performance I really don't buy into the notion that
it's a good idea to break everything into tiny puny blocks. The potential
for wasting CPU cycles on this micro-management is rather big...


I don't think that a readv/writev of 16 iovecs of 8KB is (noticeably)
slower than read/write of contiguous 128K, both might well end up in a
scaterlist for the kernel/hardware.


Ah, true. Scatter/gather is magic...


I do find iovecs useful, it the small blocks that gets me into skeptic
mode...


Small blocks is not for networking, it's for internal use only.
And remember that TLS records are 16K max anyway, give 128KB to
openssl's SSL_write it will output 8 chunks of 16KB.


Oh, I had completely missed that limit on TLS record size...


Kinda related: We also have the support for larger page sizes with modern
CPUs. Has anyone investigated if it makes sense allocating memory pools in
chunks that fit those large pages?


I think PPC64 have 64K pages already.
APR pools are already based on the page size IIRC.


I was thinking of the huge/large pages available on x86:s, 2 MiB and 
maybe 1 GiB IIRC.


My thought was that doing 2 MiB allocations for the large memory pools 
instead of 4k might make sense for configurations when you have a lot 
of threads resulting in allocating that much memory eventually, one 
page instead of lots. On Linux transparent huge page support, when 
enabled, can take advantage of this leading to less TLB 
entries/misses.



/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
 *  <- Tribble  *  <- Tribble having Safe Sex
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: httpd 2.4.25, mpm_event, ssl: segfaults

[Daniel Lescohier]

On Thu, Feb 23, 2017 at 7:48 PM, Yann Ylavic  wrote:

> On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote:
> >
> > IOW:
> > read():Three copies: copy from filesystem cache to httpd read() buffer to
> > encrypted-data buffer to kernel socket buffer.
>
> Not really, "copy from filesystem cache to httpd read() buffer" is
> likely mapping to userspace, so no copy (on read) here.
>
> > mmap(): Two copies: filesystem page already mapped into httpd, so just
> copy
> > from filesystem (cached) page to encrypted-data buffer to kernel socket
> > buffer.
>
> So, as you said earlier the "write to socket" isn't a copy either,
> hence both read() and mmap() implementations could work with a single
> copy when mod_ssl is involved (this is more than a copy but you
> counted it above so), and no copy at all without it.
>

When you do a write() system call to a socket, the kernel must copy the
data from the userspace buffer to it's own buffers, because of data
lifetime.  When the write() system call returns, userspace is free to
modify the buffer (which it owns).  But, the data from the last write()
call must live a long time in the kernel.  The kernel needs to keep a copy
of it until the remote system ACKs all of it.  The data is referenced first
in the kernel transmission control system, then in the network card's ring
buffers.  If the remote system's feedback indicates that a packet was
dropped or corrupted, the kernel may send it multiple times.  The data has
a different lifetime than the userspace buffer, so the kernel must copy it
to a buffer it owns.

On the userspace high-order memory allocations.  I still don't see what the
problem is. Say you're using 64kiB buffers.  When you free the buffers
(e.g., at the end of the http request), they go into the memory allocator's
64kiB free-list, and they're available to be allocated again (e.g., by
another http request).  The memory allocator won't use the 64kiB free
chunks for smaller allocations, unless the free-lists for the
smaller-orders are emptied out.  That'd mean there was a surge in demand
for smaller-size allocations, so it'd make sense to start using the
higher-order free chunk instead of calling brk().  Only if there are no
more high-order free chunks left will the allocator have to call brk().
When the kernel gets the brk() request, if the system is short of
high-order contiguous memory, it doesn't have to give contiguous-physical
pages on that brk() calls.  The Page Table Entries for that request can be
composed of many individual 4kiB pages scattered all over physical memory.
That's hidden from userspace, userspace sees a contiguous range of virtual
memory.

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Yann,
  Hi Stefan,

new trace:
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
#0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
#1  0x7f459573b400 in find_allowdeny (r=r@entry=0x7f44c002c250,
method=method@entry=0, a=, a=)
at mod_access_compat.c:270
#2  0x7f459573b59a in check_dir_access (r=0x7f44c002c250)
at mod_access_compat.c:324
#3  0x560ce8333fd0 in ap_run_access_checker (r=0x7f44c002c250)
at request.c:87
#4  0x560ce8336ea8 in ap_process_request_internal (r=0x7f44c002c250)
at request.c:265
#5  0x560ce8377b40 in ap_process_async_request (r=0x7f44c002c250)
at http_request.c:434
#6  0x560ce8377cf0 in ap_process_request (r=0x7f44c002c250)
at http_request.c:471
#7  0x560ce83b8aad in h2_task_process_request (c=,
task=) at h2_task.c:612
#8  h2_task_process_conn (c=0x7f44c003d070) at h2_task.c:659
#9  0x560ce8347fd0 in ap_run_process_connection (c=0x7f44c0026220)
at connection.c:42
#10 0x560ce83b9eaf in h2_task_do (task=0x7f44c002a240,
thread=0x560ce8afc900, worker_id=365015362) at h2_task.c:578
#11 0x560ce83c362f in execute (thread=0x560ce8afc900,
wctx=0x560ce8afc8c0)
at h2_worker.c:46
#12 0x7f45967610a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan

Am 23.02.2017 um 07:59 schrieb Stefan Priebe - Profihost AG:
> Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
>>  wrote:
>>>
>>> @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
>>
>> Yes, I think this is the right thing to do for now (no more patches than v7).
>>
>>> Or
>>> do i need V8 or something else?
>>
>> Not ready yet, I'll propose it when that's the case if you can test it then.
>> That's an mpm_event optimization (hopefully) only, v7 is good from
>> correctness POV...
> 
> OK it's running. Will report back.
> 
> Greets,
> Stefan
> 
>> Thanks for testing, still!
>>
>> Regards,
>> Yann.
>>