php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77357 base64_encode / base64_decode doest not work on nested VM
Submitted: 2018-12-27 09:05 UTC Modified: 2019-01-04 08:09 UTC
From: hsiangjen at gmail dot com Assigned: nikic (profile)
Status: Closed Package: *General Issues
PHP Version: 7.3.0 OS: Windows 2012R2
Private report: No CVE-ID: None
 [2018-12-27 09:05 UTC] hsiangjen at gmail dot com
Description:
------------
The Windows guest machine installed in the nested virtual enviornment (esx -> OpenStack -> Windows 2012R2), the simple code works on php 7.2.13 but 7.3.0

Test script:
---------------
$STRING = '564dace0-391c-42b6-d098-5b7742cb19ee';
$output = base64_encode($STRING);
print_r($output);

Expected result:
----------------
NTY0ZGFjZTAtMzkxYy00MmI2LWQwOTgtNWI3NzQyY2IxOWVl

Actual result:
--------------
Firefox Browser display:

The connection was reset

The connection to the server was reset while the page was loading.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-12-27 10:03 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2018-12-27 10:03 UTC] requinix@php.net
Please read the comments on bug #77284 to see if your problem is the same.
 [2018-12-27 14:57 UTC] hsiangjen at gmail dot com
Checked the source code, I think the issue maybe related to new method that using CPU instructions to calculate string.

Here is my VM guest CPU information from CPU-Z.


Number of cores		1 (max 1)
Number of threads	1 (max 1)
Name			Intel Pentium II
Codename		
Specification		QEMU Virtual CPU version 2.0.0
Package (platform ID)	Slot 1 SEPP (0x0)
CPUID			6.6.3
Extended CPUID		6.6
Core Stepping		
Technology		0.25 um
Core Speed		2997.0 MHz
Multiplier x Bus Speed	5.0 x 599.4 MHz
Base frequency (cores)	599.4 MHz
Base frequency (ext.)	599.4 MHz
Stock frequency		333 MHz
Instructions sets	MMX, SSE, SSE2, SSE3, EM64T, VT-x
Microcode Revision	0x1
L1 Data cache		32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache	32 KBytes, 8-way set associative, 64-byte line size
L2 cache		4096 KBytes, 16-way set associative, 64-byte line size
Max CPUID level		00000004h
Max CPUID ext. level	8000000Ah
Cache descriptor	Level 1, D, 32 KB, 1 thread(s)
Cache descriptor	Level 1, I, 32 KB, 1 thread(s)
Cache descriptor	Level 2, U, 4 MB, 1 thread(s)
FID/VID Control		no

IBRS			not supported
IBPB			not supported
STIBP			not supported
RDCL_NO			no
IBRS_ALL		not supported

Clock Speed 0		2997.00 MHz (Core #0)
Core 0 max ratio	(effective) 5.0
 [2018-12-28 16:34 UTC] cmb@php.net
-Assigned To: +Assigned To: cmb
 [2018-12-28 16:34 UTC] cmb@php.net
Did you compile PHP yourself, or are you using a build from
<https://windows.php.net/download/>?  If the former, did you use
the --native-intrinsics configure option?
 [2018-12-29 16:16 UTC] hsiangjen at gmail dot com
I download "VC15 x64 Thread Safe" from https://windows.php.net/download/ and module with latest build apache from https://www.apachelounge.com/download/
 [2018-12-29 16:59 UTC] cmb@php.net
-Status: Feedback +Status: Open
 [2018-12-29 16:59 UTC] cmb@php.net
Thanks for the info!
 [2018-12-30 13:42 UTC] cmb@php.net
-Status: Assigned +Status: Feedback
 [2018-12-30 13:42 UTC] cmb@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2019-01-02 08:13 UTC] hsiangjen at gmail dot com
-Status: Feedback +Status: Open
 [2019-01-02 09:45 UTC] nikic@php.net
Stack trace says:

php7ts!php_prefix_varname+8c82 
php7ts!php_prefix_varname+88a7 
php7ts!zend_ast_destroy+230 
php7ts!execute_ex+5f 
php7ts!zend_execute+1a8 
php7ts!zend_execute_scripts+b9 
php7ts!php_execute_script+261 
php!sapi_cli_single_write+1320 
php!sapi_cli_single_write+2298 
php!sapi_cli_single_write+9fa8 
kernel32!BaseThreadInitThunk+22 
ntdll!RtlUserThreadStart+34 

Which doesn't look possible. Maybe the symbols weren't resolved correctly?
 [2019-01-02 09:47 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2019-01-02 09:47 UTC] cmb@php.net
Thanks!  Apparently, the actual backtrace is:

    php7ts!php_prefix_varname+8c82
    php7ts!php_prefix_varname+88a7
    php7ts!zend_ast_destroy+230
    php7ts!execute_ex+5f
    php7ts!zend_execute+1a8
    php7ts!zend_execute_scripts+b9
    php7ts!php_execute_script+261
    php!sapi_cli_single_write+1320
    php!sapi_cli_single_write+2298
    php!sapi_cli_single_write+9fa8
    kernel32!BaseThreadInitThunk+22
    ntdll!RtlUserThreadStart+34

    The assembly instruction at php7ts!php_prefix_varname+8c82 in C:\Program Files\SaaSaMe\Transport\php_7.3\php7ts.dll from The PHP Group has caused an unknown exception (0xc000001d)
 [2019-01-03 08:43 UTC] hsiangjen at gmail dot com
I chagned order version of Debug Diagonstic tool (version 1.2)

Here is the dump again. 

https://www.dropbox.com/s/00hjbnny4hcomai/CrashHang_Report__Date_01_03_2019__Time_04_40_55PM__58.mht?dl=0

Hope this will help more.

Thank you.
 [2019-01-03 08:49 UTC] nikic@php.net
Thanks, that does look more reasonable. We're crashing inphp7ts!php_base64_encode_avx2+82 with a 0xc000001d exception, i.e. illegal instruction. Clearly we're trying to execute an AVX2 instruction on a CPU that doesn't support it. The question is why...
 [2019-01-03 09:01 UTC] hsiangjen at gmail dot com
Thank you for the help.

I guess since I am under KVM virtual machine enviornment. The CPU AVX instruction does not passvia to the guest level by default. I will bootup a Linux guest machine to try it also.

Maybe the isseu is like this: https://superuser.com/questions/453786/how-do-i-get-avx-support-in-qemu
 [2019-01-03 09:08 UTC] spam2 at rhsoft dot net
https://superuser.com/questions/453786/how-do-i-get-avx-support-in-qemu is about AVX not passed to the guest which in fact happens on your guest given "Instructions sets	MMX, SSE, SSE2, SSE3, EM64T, VT-x"

but in that case PHP must not use the instructions
 [2019-01-03 09:19 UTC] nikic@php.net
Okay, I think I see what the issue is. We're not using CPUID correctly. Here is (what I guess) is happening:

 * We're calling CPUID with EAX 7, which is above the maximum basic CPUID level of 4 supported by your CPU.
 * Per Intel instruction set reference, "If a value entered for CPUID.EAX
is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned."
 * This means we get back the level 4 information.
 * AVX2 support if bit 5 of EBX at level 7, while bits 0-11 of EBX at level 4 are the System Cache Coherence Size minus one. As this is probably a power of 2 >= 64, bit 5 will be set.

We should not be calling CPUID with values above the maximum basic function.
 [2019-01-03 09:28 UTC] nikic@php.net
-Status: Open +Status: Feedback
 [2019-01-03 09:28 UTC] nikic@php.net
I've committed a possible fix at https://github.com/php/php-src/commit/5a361c3a54c055cdf7088e76aa8efa159334e096. If you could try a snapshot build with this change (once it is available at https://windows.php.net/snapshots/), that would be great.
 [2019-01-04 02:38 UTC] hsiangjen at gmail dot com
It works for snapshot build revision r5a361c3. Thank you very much for your quick response.
 [2019-01-04 08:09 UTC] nikic@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: nikic
 [2019-01-04 08:09 UTC] nikic@php.net
Thanks for the confirmation!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Nov 08 14:01:28 2024 UTC