Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[INADA Naoki]

On Tue, Sep 18, 2018 at 7:08 AM Wes Turner  wrote:
>
> To summarize:
>
> - CPython may be vulnerable to speculative execution vulnerabilities, but 
> none are known.
> - In general, CPython is currently too slow for speculative execution 
> exploitation to be practical.
>   - Sandboxed, JIT'ed JS is not too slow for speculative execution 
> exploitation to be practical
> - (Not otherwise discussed here: PyPy's sandboxed JIT may not be too slow 
> for speculative execution exploitation to be practical.)
>

As far as I know, execution speed is important for attacker, not victim.
In case of JavaScript, browser may load attacking code and run it while
user watching websites.
Browsers provides sandbox for JS, but attacker code may be able to
bypass the sandbox by Spectre or Meltdown.  So browsers disabled
high precision timer until OSes are updated.

This topic is totally unrelated to compiler options: these compiler options
doesn't prohibit running attacking code, it just guard branches from
branch target injection.

Does my understanding collect?  Why should we discuss about execution speed?

I think this topic should split to two topics: (1) Guard Python
process from Spectre/Meltdown
attack from other process, (2) Prohibit Python code attack other
processes by using
Spectre/Meltdown.


Regards,
-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Franklin? Lee]

I believe this is the article Wes wanted to link to:
https://www.thomas-krenn.com/en/wiki/Safety_instructions_for_Meltdown_and_Spectre

On Mon, Sep 17, 2018 at 6:10 PM Wes Turner  wrote:
>
> To summarize:
>
> - CPython may be vulnerable to speculative execution vulnerabilities, but 
> none are known.
> - In general, CPython is currently too slow for speculative execution 
> exploitation to be practical.
>   - Sandboxed, JIT'ed JS is not too slow for speculative execution 
> exploitation to be practical
> - (Not otherwise discussed here: PyPy's sandboxed JIT may not be too slow 
> for speculative execution exploitation to be practical.)

I'm no security researcher, and I barely remember much about
Spectre/Meltdown, but I think the idea is that, if Python takes about
2 milliseconds to run your code, then a difference of +- 10
microseconds is indistinguishable from noise. Try to write software
that can learn to distinguish two similar computers using the running
time of certain functions.

Javascript can be crafted to get close enough to some C programs.
ASM.js and WebAssembly might help.

PyPy's need for mitigation is independent of CPython's.

> - Because there is no exploit provided (or currently thought possible with 
> just CPython), this security-related dialogue is regarded as a nuisance.

More than that. Steve says that he looked into it and decided there
wasn't really anything to worry about. He believes that any exploit of
it will also imply an easier exploit is possible. He also says that
this particular fix won't really help.

Nathaniel is annoyed because Spectre is tricky to understand, and he
assumes you don't understand it as well as you think because you
haven't shown him that you have the expertise to understand it.

> Here's a good write-up:
> Safety_instructions_for_Meltdown_and_Spectre

But how does that apply to CPython? What specifically about CPython
makes the interpreter vulnerable to the attack? Under what conditions
would CPython be vulnerable to this attack, but not an easier attack
of at least the same severity?

The article I linked at the top of this email does not give advice for
interpreter writers at all. It only says what end users and chip
manufacturers ought to do. It is not relevant.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [help] where to learn how to upgrade from 2.7 to 3

[Ryan Gonzalez]

Python-dev is for development *of* Python, not *in* Python! You want
python-list instead.

Also, make sure you include some full example code where the error occurs
and what exactly is failing. Right now, it's hard for me to tell what
exactly is going on...

On Mon, Sep 17, 2018, 8:21 PM Avery Richards 
wrote:

> I am having so much fun learning python! I did not install the best
> version into my mac at first. Now I can't find out how to upgrade, (pip is
> awesome but not as conversational as I need it to be on the subject). I've
> downloaded the packages from python.org, installed all sorts of stuff,  I
> configured my text editor to recognize python3, resolving formatting
> strings output, but now as I progress the
>
> [end = '  ']
>
> is not recognized. I have figured out a lot on my own, can you help me
> upgrade to 3.6 once and for all? Again I consulted with pip and followed
> faq websites (maybe a mistake there, idk).
>
> please please thank you!
>
> ~Avery
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
-- 

Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Late Python 3.7.1 changes to fix the C locale coercion (PEP 538) implementation

[Ned Deily]

On Sep 17, 2018, at 21:20, Victor Stinner  wrote:
> tl; dr Nick, Ned, INADA-san: I modified 3.7.1 to add a new "-X
> coerce_c_locale=value" option and make sure that the C locale coercion
> cannot be when Python in embedded: are you ok with these changes?
> 
> 
> Before 3.7.0 release, during the implementation of the UTF-8 Mode (PEP
> 540), I changed two things in Nick Coghlan's implementation of the C
> locale coercion (PEP 538):
> 
> (1) PYTHONCOERCECLOCALE environment variable is now ignored when -E or
> -I command line option is used.
> 
> (2) When Python is embeded, the C locale coercion is now enabled if
> the LC_CTYPE locale is "C".
> 
> Nick asked me to change the behavior:
> https://bugs.python.org/issue34589
> 
> I just pushed this change in the 3.7 branch which adds a new "-X
> coerce_c_locale=value" option:
> https://github.com/python/cpython/commit/144f1e2c6f4a24bd288c045986842c65cc289684
> 
> Examples using Pyhon 3.7 (future 3.7.1) with UTF-8 Mode disabled, to
> only test the C locale coercion:
> ---
> $ cat test.py
> import codecs, locale
> enc = locale.getpreferredencoding()
> enc = codecs.lookup(enc).name
> print(enc)
> 
> $ export LC_ALL= LC_CTYPE=C LANG=
> 
> # Disable C locale coercion: get ASCII as expected
> $ PYTHONCOERCECLOCALE=0 ./python -X utf8=0 test.py
> ascii
> 
> # -E ignores PYTHONCOERCECLOCALE=0:
> # C locale is coerced, we get UTF-8
> $ PYTHONCOERCECLOCALE=0 ./python -E -X utf8=0 test.py
> utf-8
> 
> # -X coerce_c_locale=0 is not affected by -E:
> # C locale coercion disabled as expected, get ASCII as expected
> $ ./python -E -X utf8=0 -X coerce_c_locale=0 test.py
> ascii
> ---
> 
> 
> For (1), Nick's use case is to get Python 3.6 behavior (C locale not
> coerced) on Python 3.7 using PYTHONCOERCECLOCALE. Nick proposed to use
> PYTHONCOERCECLOCALE even with -E or -I, but I dislike introducing a
> special case for -E option.
> 
> I chose to add a new "-X coerce_c_locale=0" to Python 3.7.1 to provide
> a solution for this use case. (Python 3.7.0 and older ignore this
> option.)
> 
> Note: Python 3.7.0 is fine with PYTHONCOERCECLOCALE=0, we are only
> talking about the special case of -E and -I options.
> 
> 
> For (2), I modified Python 3.7.1 to make sure the C locale is never
> coerced when the C API is used to embed Python inside an application:
> Py_Initialize() and Py_Main(). The C locale can only be coerced by the
> official Python program ("python3.7").
> 
> I don't know if it should be possible to enable C locale coercion when
> Python is embedded. So I just made the change requested by Nick :-)
> 
> 
> I dislike doing such late changes in 3.7.1, especially since PEP 538
> has been designed by Nick Coghlan, and we disagree on the fix. But Ned
> Deily, our Python 3.7 release manager, wants to see last 3.7 fixes
> merged before Tuesday, so here we are.

Just because the 3.7.1rc is scheduled doesn't mean we should throw something 
in, particularly if it's not fully reviewed and fully agreed upon.  If it's 
important enough, we could delay the rc a few days ... or decide to wait for 
3.7.2.

> Nick, Ned, INADA-san: are you ok with these changes?
> The other choices for 3.7.1 are:
> 
> * Revert my change: C locale coercion can still be enabled when Python
> is embedded, -E option ignores PYTHONCOERCECLOCALE env var.
> 
> * Revert my change and apply Nick's PR 9257: C locale coercion cannot
> be enabled when Python is embedded and -E option doesn't ignore
> PYTHONCOERCECLOCALE env var.
> 
> 
> I spent months to fix the master branch to support all possible
> locales and encodings, and get a consistent CLI:
> https://vstinner.github.io/python3-locales-encodings.html
> 
> So I'm not excited by Nick's PR which IMHO moves Python backward,
> especially it breaks the -E option contract: it doesn't ignore
> PYTHONCOERCECLOCALE env var.

I would like to see Nick review the merged 3.7 PR and have both him and you 
agree that this is the thing to do for 3.7.1.  I also want to make sure we 
understand what affect this will have on 3.7.0 users.  Let's not potentially 
make things worse.

I'm not planning to tag 3.7.1rc for at least another 18 hours.  I'm marking 
bpo-34589 as "release blocker" and I will not proceed until this is resolved.

Thanks!
--Ned

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Late Python 3.7.1 changes to fix the C locale coercion (PEP 538) implementation

[Victor Stinner]

Hi Unicode and locales lovers,

tl; dr Nick, Ned, INADA-san: I modified 3.7.1 to add a new "-X
coerce_c_locale=value" option and make sure that the C locale coercion
cannot be when Python in embedded: are you ok with these changes?


Before 3.7.0 release, during the implementation of the UTF-8 Mode (PEP
540), I changed two things in Nick Coghlan's implementation of the C
locale coercion (PEP 538):

(1) PYTHONCOERCECLOCALE environment variable is now ignored when -E or
-I command line option is used.

(2) When Python is embeded, the C locale coercion is now enabled if
the LC_CTYPE locale is "C".

Nick asked me to change the behavior:
https://bugs.python.org/issue34589

I just pushed this change in the 3.7 branch which adds a new "-X
coerce_c_locale=value" option:
https://github.com/python/cpython/commit/144f1e2c6f4a24bd288c045986842c65cc289684

Examples using Pyhon 3.7 (future 3.7.1) with UTF-8 Mode disabled, to
only test the C locale coercion:
---
$ cat test.py
import codecs, locale
enc = locale.getpreferredencoding()
enc = codecs.lookup(enc).name
print(enc)

$ export LC_ALL= LC_CTYPE=C LANG=

# Disable C locale coercion: get ASCII as expected
$ PYTHONCOERCECLOCALE=0 ./python -X utf8=0 test.py
ascii

# -E ignores PYTHONCOERCECLOCALE=0:
# C locale is coerced, we get UTF-8
$ PYTHONCOERCECLOCALE=0 ./python -E -X utf8=0 test.py
utf-8

# -X coerce_c_locale=0 is not affected by -E:
# C locale coercion disabled as expected, get ASCII as expected
$ ./python -E -X utf8=0 -X coerce_c_locale=0 test.py
ascii
---


For (1), Nick's use case is to get Python 3.6 behavior (C locale not
coerced) on Python 3.7 using PYTHONCOERCECLOCALE. Nick proposed to use
PYTHONCOERCECLOCALE even with -E or -I, but I dislike introducing a
special case for -E option.

I chose to add a new "-X coerce_c_locale=0" to Python 3.7.1 to provide
a solution for this use case. (Python 3.7.0 and older ignore this
option.)

Note: Python 3.7.0 is fine with PYTHONCOERCECLOCALE=0, we are only
talking about the special case of -E and -I options.


For (2), I modified Python 3.7.1 to make sure the C locale is never
coerced when the C API is used to embed Python inside an application:
Py_Initialize() and Py_Main(). The C locale can only be coerced by the
official Python program ("python3.7").

I don't know if it should be possible to enable C locale coercion when
Python is embedded. So I just made the change requested by Nick :-)


I dislike doing such late changes in 3.7.1, especially since PEP 538
has been designed by Nick Coghlan, and we disagree on the fix. But Ned
Deily, our Python 3.7 release manager, wants to see last 3.7 fixes
merged before Tuesday, so here we are.


Nick, Ned, INADA-san: are you ok with these changes?


The other choices for 3.7.1 are:

* Revert my change: C locale coercion can still be enabled when Python
is embedded, -E option ignores PYTHONCOERCECLOCALE env var.

* Revert my change and apply Nick's PR 9257: C locale coercion cannot
be enabled when Python is embedded and -E option doesn't ignore
PYTHONCOERCECLOCALE env var.


I spent months to fix the master branch to support all possible
locales and encodings, and get a consistent CLI:
https://vstinner.github.io/python3-locales-encodings.html

So I'm not excited by Nick's PR which IMHO moves Python backward,
especially it breaks the -E option contract: it doesn't ignore
PYTHONCOERCECLOCALE env var.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [help] where to learn how to upgrade from 2.7 to 3

[Avery Richards]

I am having so much fun learning python! I did not install the best version
into my mac at first. Now I can't find out how to upgrade, (pip is awesome
but not as conversational as I need it to be on the subject). I've
downloaded the packages from python.org, installed all sorts of stuff,  I
configured my text editor to recognize python3, resolving formatting
strings output, but now as I progress the

[end = '  ']

is not recognized. I have figured out a lot on my own, can you help me
upgrade to 3.6 once and for all? Again I consulted with pip and followed
faq websites (maybe a mistake there, idk).

please please thank you!

~Avery
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Carl Shapiro]

On Sun, Sep 16, 2018 at 1:24 PM, Antoine Pitrou  wrote:

> I think it's of limited interest if it only helps with modules used
> during the startup sequence, not arbitrary stdlib or third-party
> modules.
>

This should help any use-case that is already using the freeze module
already bundled with CPython.  Third-party code, like py2exe, py2app,
pyinstaller, and XAR could build upon this to create applications that
start faster.


> To give an idea, on my machine the baseline Python startup is about 20ms
> (`time python -c pass`), but if I import Numpy it grows to 100ms, and
> with Pandas it's more than 200ms.  Saving 4ms on the baseline startup
> would make no practical difference for concrete usage.
>

Do you have a feeling for how many of those milliseconds are spend loading
bytecode from disk?  If so standalone executables that contain numpy and
pandas (and mercurial) would start faster


> I'm ready to think there are other use cases where it matters, though.
>

I think so.  I hope you will, too :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for review: binary op dispatch rules for subclasses

[Guido van Rossum]

FWIW I wrote up what I recall about the issue and kicked it to the next
BDFL: https://bugs.python.org/issue30140#msg325553

On Fri, Sep 14, 2018 at 6:42 PM Stephan Hoyer  wrote:

> Over a year ago, I made a pull request (
> https://github.com/python/cpython/pull/1325) to fix a long-standing issue
> with how Python handles dispatch for arithmetic binary operations involving
> subclasses (https://bugs.python.org/issue30140).
>
> I pinged the bug several times, but I'm still waiting for a review, which
> would be greatly appreciated!
>
> Best,
> Stephan
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Wes Turner]

To summarize:

- CPython may be vulnerable to speculative execution vulnerabilities, but
none are known.
- In general, CPython is currently too slow for speculative execution
exploitation to be practical.
  - Sandboxed, JIT'ed JS is not too slow for speculative execution
exploitation to be practical
- (Not otherwise discussed here: PyPy's sandboxed JIT may not be too
slow for speculative execution exploitation to be practical.)

- C extensions may be vulnerable to speculative execution vulnerabilities;
but that's the authors' and users' problem (and so it's appropriate to
mention this to extension owners following distutils-sig/PyPA)
  - C extensions can set indirect branch CFLAGS only with GCC 7.3 and GCC
8+; which are only usable with conda and the forthcoming manylinux2010 spec

- Linux kernels with [IBRS, STIBP, IBPB] can enable userspace protection
- The revised worst-case performance impacts for variant 2 mitigations are
4-8%

- MSVC has a /Qspectre flag for variant 1

- Because there is no exploit provided (or currently thought possible with
just CPython), this security-related dialogue is regarded as a nuisance.
- There is no published or official statement or investigation from the
Python community regarding Spectre (or Meltdown) vulnerabilities.

Here's a good write-up:
Safety_instructions_for_Meltdown_and_Spectre

Have a good day!

On Monday, September 17, 2018, Steve Dower  wrote:

> On 17Sep2018 1158, Wes Turner wrote:
>
>> On Monday, September 17, 2018, Steve Dower > > wrote:
>>
>> I investigated this thoroughly some time ago (when the MSVC flags
>> became available) and determined (with the help of some of the
>> original Spectre/Meltdown investigation team) that there is no
>> significant value in enabling these flags for Python.
>>
>> What did you fuzz with?
>> Does that assume that e.g. Fortify has identified all bugs in CPython C?
>> There have been a number of variants that have been disclosed; which did
>> who test for?
>>
>
> Don't change the subject.
>
> It boiled down to:
>> * Python allows arbitrary code execution by design
>>
>> Yet binaries built with GCC do have NX? Unless nested functions in C
>> extensions?
>>
>
> I don't know anything about GCC settings. Binaries for Windows have been
> built with this option for over a decade. It's unrelated to
> Spectre/Meltdown.
>
> * Pure Python code in CPython has very long per-instruction opcode
>> sequences that cannot easily be abused or timed
>>
>> A demonstration of this would be helpful.
>>
>
> That's not how proof-of-concepts work. You can't assume that the lack of a
> demonstration proves it is possible - at best you have to assume that it
> proves it is *not* possible, but really it just proves that nobody has a
> demonstration yet.
>
> What I could demonstrate (again) if I thought it would be worthwhile is
> that the changes enabled by the flag do not affect the normal interpreter
> loop, and do not affect any code that can be called fast enough to
> potentially leak information. Feel free to go ahead and build with/without
> the flags and compare the disassembly (and if you do this and find that
> compilers are detecting new cases since I looked, *that* would be very
> helpful to share directly with the security team).
>
> * Injected pure Python code cannot be coerced into generating native
>> code that is able to abuse Spectre/Meltdown but not able to abuse
>> other attacks more easily
>>
>>   So, not impossible.
>>
>
> Of course it's not impossible. But why would you
>
> * Code injection itself is outside of this particular threat model
>>
>> [Jupyter] Notebook servers are as wide open to arbitrary code execution
>> as browser JS JITs; often with VMs and/or containers as a 'sandbox'
>>
>
> `pip install requirements.txt` installs and executes unsigned code:
>> Python, C extensions
>>
>> What can a container do to contain a speculative execution exploit
>> intending to escape said container?
>>
>
> Python's threat model does not treat the Python process as a sandbox. To
> say it another way, if you assume the Python process is a sandbox, you're
> on your own.
>
> Arbitrary code, Python or otherwise, can totally escape the process, and
> then it's up to the OS to protect against escaping the machine. We do what
> we can to reduce unnecessary arbitrary code, but unless you've properly
> protected your environment then you have a lot more to worry about besides
> speculative execution vulnerabilities.
>
> By comparison with JavaScript, most JS JITs can be easily coerced
>> into generating specific native code that can break sandbox
>> guarantees (e.g. browser tabs). Python offers none of these
>> guarantees.
>>
>>
>> This is faulty logic. Because Python does not have a JIT sandbox,
>> speculative execution is not a factor for Python?
>>
>
> Because Python does not have a (native) JIT at all, speculative execution
> relies on identifying

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Nathaniel Smith]

Hi Wes,

It's great you're passionate about python security, but this is the wrong
way to go about it. Spectre is inherently super subtle and confusing, so if
there's something that people need to do, then we need a clear,
comprehensive write-up of what the threat is and how to address it. Perhaps
you could find some collaborators with expertise in these things and work
with them off-list to put something like that together – that could be
quite helpful.

What isn't helpful is what you've been doing instead: sending incoherent
jumbles of vaguely-related text, to multiple highly-subscribed mailing
lists, multiple times a day, for a week now. This is worse than useless.
Please stop.

-n

On Mon, Sep 17, 2018, 12:44 Wes Turner  wrote:

>
>
> On Mon, Sep 17, 2018 at 2:58 PM Wes Turner  wrote:
>
>>
>> I thought I read that RH has a kernel flag for userspace?
>>
>
> "Controlling the Performance Impact of Microcode and Security Patches for
> CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise
> Linux Tunables"
> https://access.redhat.com/articles/3311301
>
> > Indirect Branch Restricted Speculation (ibrs)
> > [...] When ibrs_enabled is set to 1 (spectre_v2=ibrs) the kernel runs
> with indirect branch restricted speculation, which protects the kernel
> space from attacks (even from hyperthreading/simultaneous multi-threading
> attacks). When IBRS is set to 2 (spectre_v2=ibrs_always), both userland and
> kernel runs with indirect branch restricted speculation. This protects
> userspace from hyperthreading/simultaneous multi-threading attacks as well,
> and is also the default on certain old AMD processors (family 10h, 12h and
> 16h). This feature addresses CVE-2017-5715, variant #2.
> > [...]
> > echo 2 > /sys/kernel/debug/x86/ibrs_enabled
>
>
> https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls
> > echo 2 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in both
> userspace and kernel
>
> ...
> On Mon, Sep 17, 2018 at 5:26 AM Antoine Pitrou 
> wrote:
>
>> If you want to push this forward, I suggest you measure performance of
>> Python compiled with and without the Spectre mitigation options, and
>> report the results here.  That will help vendors and packagers decide
>> whether they want to pursue the route of enabling those options.
>
>
> "Speculative Execution Exploit Performance Impacts - Describing the
> performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and
> CVE-2017-5715"
> https://access.redhat.com/articles/3307751
>
> - Revised worst-case peformance impact: 4-8%
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/njs%40pobox.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Steve Dower]

On 17Sep2018 1158, Wes Turner wrote:
On Monday, September 17, 2018, Steve Dower > wrote:


I investigated this thoroughly some time ago (when the MSVC flags
became available) and determined (with the help of some of the
original Spectre/Meltdown investigation team) that there is no
significant value in enabling these flags for Python.

What did you fuzz with?
Does that assume that e.g. Fortify has identified all bugs in CPython C?
There have been a number of variants that have been disclosed; which did 
who test for?


Don't change the subject.


It boiled down to:
* Python allows arbitrary code execution by design

Yet binaries built with GCC do have NX? Unless nested functions in C 
extensions?


I don't know anything about GCC settings. Binaries for Windows have been 
built with this option for over a decade. It's unrelated to 
Spectre/Meltdown.



* Pure Python code in CPython has very long per-instruction opcode
sequences that cannot easily be abused or timed

A demonstration of this would be helpful.


That's not how proof-of-concepts work. You can't assume that the lack of 
a demonstration proves it is possible - at best you have to assume that 
it proves it is *not* possible, but really it just proves that nobody 
has a demonstration yet.


What I could demonstrate (again) if I thought it would be worthwhile is 
that the changes enabled by the flag do not affect the normal 
interpreter loop, and do not affect any code that can be called fast 
enough to potentially leak information. Feel free to go ahead and build 
with/without the flags and compare the disassembly (and if you do this 
and find that compilers are detecting new cases since I looked, *that* 
would be very helpful to share directly with the security team).



* Injected pure Python code cannot be coerced into generating native
code that is able to abuse Spectre/Meltdown but not able to abuse
other attacks more easily

  So, not impossible.


Of course it's not impossible. But why would you


* Code injection itself is outside of this particular threat model

[Jupyter] Notebook servers are as wide open to arbitrary code execution 
as browser JS JITs; often with VMs and/or containers as a 'sandbox'


`pip install requirements.txt` installs and executes unsigned code: 
Python, C extensions


What can a container do to contain a speculative execution exploit 
intending to escape said container?


Python's threat model does not treat the Python process as a sandbox. To 
say it another way, if you assume the Python process is a sandbox, 
you're on your own.


Arbitrary code, Python or otherwise, can totally escape the process, and 
then it's up to the OS to protect against escaping the machine. We do 
what we can to reduce unnecessary arbitrary code, but unless you've 
properly protected your environment then you have a lot more to worry 
about besides speculative execution vulnerabilities.



By comparison with JavaScript, most JS JITs can be easily coerced
into generating specific native code that can break sandbox
guarantees (e.g. browser tabs). Python offers none of these guarantees.


This is faulty logic. Because Python does not have a JIT sandbox, 
speculative execution is not a factor for Python?


Because Python does not have a (native) JIT at all, speculative 
execution relies on identifying vulnerable and reusable code patterns 
within the C code and being able to invoke those directly. Because pure 
Python code does not allow this (without relying on other bugs), there 
is no way to do this within the threat model we use.


Once you allow arbitrary or unvalidated native code, you are outside the 
threat model and hence on your own. And if you find a bug that lets pure 
Python code move the instruction pointer to arbitrary native code, that 
should be reported to the security team.



Distributors are of course free to enable these flags for their own
builds, but I recommend against it for the official binaries, and
would suggest that it's worth more PR than actual security and
nobody else needs to enable it either.

(Extension authors with significant scriptable C code need to
perform their own analysis. I'm only talking about CPython here.)


Extension installers (and authors) are not likely to perform any such 
analysis.


Then it is their fault if they are compromised. Open source software 
relies on users validating the software themselves, as there is no legal 
recourse against developers who do not do it.


Extensions are composed of arbitrary C, which certainly can both 
directly exploit and indirectly enable remote exploitation of Spectre 
and Meltdown vulnerabilities.


If arbitrary C is running, we can't help you anymore.

Most users of python are installing arbitrary packages (without hashes 
or signatures).


If they are concerned about Spectre/Meltdown, they should stop doing 
this. They should also sto

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Wes Turner]

On Mon, Sep 17, 2018 at 2:58 PM Wes Turner  wrote:

>
> I thought I read that RH has a kernel flag for userspace?
>

"Controlling the Performance Impact of Microcode and Security Patches for
CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise
Linux Tunables"
https://access.redhat.com/articles/3311301

> Indirect Branch Restricted Speculation (ibrs)
> [...] When ibrs_enabled is set to 1 (spectre_v2=ibrs) the kernel runs
with indirect branch restricted speculation, which protects the kernel
space from attacks (even from hyperthreading/simultaneous multi-threading
attacks). When IBRS is set to 2 (spectre_v2=ibrs_always), both userland and
kernel runs with indirect branch restricted speculation. This protects
userspace from hyperthreading/simultaneous multi-threading attacks as well,
and is also the default on certain old AMD processors (family 10h, 12h and
16h). This feature addresses CVE-2017-5715, variant #2.
> [...]
> echo 2 > /sys/kernel/debug/x86/ibrs_enabled

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls
> echo 2 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in both
userspace and kernel

...
On Mon, Sep 17, 2018 at 5:26 AM Antoine Pitrou  wrote:

> If you want to push this forward, I suggest you measure performance of
> Python compiled with and without the Spectre mitigation options, and
> report the results here.  That will help vendors and packagers decide
> whether they want to pursue the route of enabling those options.


"Speculative Execution Exploit Performance Impacts - Describing the
performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and
CVE-2017-5715"
https://access.redhat.com/articles/3307751

- Revised worst-case peformance impact: 4-8%
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Wes Turner]

On Monday, September 17, 2018, Steve Dower  wrote:

> I investigated this thoroughly some time ago (when the MSVC flags became
> available) and determined (with the help of some of the original
> Spectre/Meltdown investigation team) that there is no significant value in
> enabling these flags for Python.


What did you fuzz with?
Does that assume that e.g. Fortify has identified all bugs in CPython C?
There have been a number of variants that have been disclosed; which did
who test for?


>
> It boiled down to:
> * Python allows arbitrary code execution by design


Yet binaries built with GCC do have NX? Unless nested functions in C
extensions?


> * Pure Python code in CPython has very long per-instruction opcode
> sequences that cannot easily be abused or timed


A demonstration of this would be helpful.

* Injected pure Python code cannot be coerced into generating native code
> that is able to abuse Spectre/Meltdown but not able to abuse other attacks
> more easily


 So, not impossible.

* Code injection itself is outside of this particular threat model


[Jupyter] Notebook servers are as wide open to arbitrary code execution as
browser JS JITs; often with VMs and/or containers as a 'sandbox'

`pip install requirements.txt` installs and executes unsigned code: Python,
C extensions

What can a container do to contain a speculative execution exploit
intending to escape said container?

I thought I read that RH has a kernel flag for userspace?


> By comparison with JavaScript, most JS JITs can be easily coerced into
> generating specific native code that can break sandbox guarantees (e.g.
> browser tabs). Python offers none of these guarantees.


This is faulty logic. Because Python does not have a JIT sandbox,
speculative execution is not a factor for Python?


>
> Distributors are of course free to enable these flags for their own
> builds, but I recommend against it for the official binaries, and would
> suggest that it's worth more PR than actual security and nobody else needs
> to enable it either.
>
> (Extension authors with significant scriptable C code need to perform
> their own analysis. I'm only talking about CPython here.)


Extension installers (and authors) are not likely to perform any such
analysis.

Extensions are composed of arbitrary C, which certainly can both directly
exploit and indirectly enable remote exploitation of Spectre and Meltdown
vulnerabilities.

Most users of python are installing arbitrary packages (without hashes or
signatures).


>
> Cheers,
> Steve
>
> On 16Sep2018 0707, Wes Turner wrote:
>
>> Should Python builds add `-mindirect-branch=thunk
>> -mindirect-branch-register` to CFLAGS?
>>
>> Where would this be to be added in the build scripts with which
>> architectures?
>>
>> /QSpectre is the MSVC build flag for Spectre Variant 1:
>>
>>  > The /Qspectre option is available in Visual Studio 2017 version 15.7
>> and later.
>>
>> https://docs.microsoft.com/en-us/cpp/build/reference/qspectr
>> e?view=vs-2017
>>
>> security@ directed me to the issue tracker / lists,
>> so I'm forwarding this to python-dev and python-ideas, as well.
>>
>> # Forwarded message
>> From: *Wes Turner* mailto:wes.tur...@gmail.com>>
>> Date: Wednesday, September 12, 2018
>> Subject: SEC: Spectre variant 2: GCC: -mindirect-branch=thunk
>> -mindirect-branch-register
>> To: distutils-sig mailto:distutils-sig@python.
>> org>>
>>
>>
>> Should C extensions that compile all add
>> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the
>> risk of Spectre variant 2 (which does indeed affect user space applications
>> as well as kernels)?
>>
>> [1] https://github.com/speed47/spectre-meltdown-checker/issues/
>> 119#issuecomment-361432244 > ectre-meltdown-checker/issues/119#issuecomment-361432244>
>> [2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) <
>> https://en.wikipedia.org/wiki/Spectre_%28security_vulnerability%29>
>> [3] https://en.wikipedia.org/wiki/Speculative_Store_Bypass#Specu
>> lative_execution_exploit_variants > /Speculative_Store_Bypass#Speculative_execution_exploit_variants>
>>
>> On Wednesday, September 12, 2018, Wes Turner > > wrote:
>>
>> On Wednesday, September 12, 2018, Joni Orponen
>> mailto:j.orpo...@4teamwork.ch>> wrote:
>>
>> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner
>> mailto:wes.tur...@gmail.com>> wrote:
>>
>> Should C extensions that compile all add
>> `-mindirect-branch=thunk -mindirect-branch-register` [1]
>> to mitigate the risk of Spectre variant 2 (which does
>> indeed affect user space applications as well as kernels)?
>>
>>
>> Are those available on GCC <= 4.2.0 as per PEP 513?
>>
>>
>> AFAIU, only
>> GCC 7.3 and 8 have the retpoline (indirect-branch=thunk) support
>> enabled by the `-mindirect-branch

Re: [Python-Dev] Official citation for Python

[MRAB]

On 2018-09-17 05:05, Jeremy Hylton wrote:


I wanted to start with an easy answer that is surely unsatisfying:
http://blog.apastyle.org/apastyle/2015/01/how-to-cite-software-in-apa-style.html

APA style is pretty popular, and it says that standard software doesn't 
need to be specified. Standard software includes "Microsoft Word, Java, 
and Adobe Photoshop." So I'd say Python fits well in that category, and 
doesn't need to be cited.


I said you wouldn't be satisfied...

It goes on to say """Note: We don’t keep a comprehensive list of what 
programs are “standard.” You make the call.""".


[snip]
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Steve Dower]

I investigated this thoroughly some time ago (when the MSVC flags became 
available) and determined (with the help of some of the original 
Spectre/Meltdown investigation team) that there is no significant value 
in enabling these flags for Python.


It boiled down to:
* Python allows arbitrary code execution by design
* Pure Python code in CPython has very long per-instruction opcode 
sequences that cannot easily be abused or timed
* Injected pure Python code cannot be coerced into generating native 
code that is able to abuse Spectre/Meltdown but not able to abuse other 
attacks more easily

* Code injection itself is outside of this particular threat model

By comparison with JavaScript, most JS JITs can be easily coerced into 
generating specific native code that can break sandbox guarantees (e.g. 
browser tabs). Python offers none of these guarantees.


Distributors are of course free to enable these flags for their own 
builds, but I recommend against it for the official binaries, and would 
suggest that it's worth more PR than actual security and nobody else 
needs to enable it either.


(Extension authors with significant scriptable C code need to perform 
their own analysis. I'm only talking about CPython here.)


Cheers,
Steve

On 16Sep2018 0707, Wes Turner wrote:
Should Python builds add `-mindirect-branch=thunk 
-mindirect-branch-register` to CFLAGS?


Where would this be to be added in the build scripts with which 
architectures?


/QSpectre is the MSVC build flag for Spectre Variant 1:

 > The /Qspectre option is available in Visual Studio 2017 version 15.7 
and later.


https://docs.microsoft.com/en-us/cpp/build/reference/qspectre?view=vs-2017

security@ directed me to the issue tracker / lists,
so I'm forwarding this to python-dev and python-ideas, as well.

# Forwarded message
From: *Wes Turner* mailto:wes.tur...@gmail.com>>
Date: Wednesday, September 12, 2018
Subject: SEC: Spectre variant 2: GCC: -mindirect-branch=thunk 
-mindirect-branch-register
To: distutils-sig >



Should C extensions that compile all add
`-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the 
risk of Spectre variant 2 (which does indeed affect user space 
applications as well as kernels)?


[1] 
https://github.com/speed47/spectre-meltdown-checker/issues/119#issuecomment-361432244 

[2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) 

[3] 
https://en.wikipedia.org/wiki/Speculative_Store_Bypass#Speculative_execution_exploit_variants 



On Wednesday, September 12, 2018, Wes Turner mailto:wes.tur...@gmail.com>> wrote:

On Wednesday, September 12, 2018, Joni Orponen
mailto:j.orpo...@4teamwork.ch>> wrote:

On Wed, Sep 12, 2018 at 8:48 PM Wes Turner
mailto:wes.tur...@gmail.com>> wrote:

Should C extensions that compile all add
`-mindirect-branch=thunk -mindirect-branch-register` [1]
to mitigate the risk of Spectre variant 2 (which does
indeed affect user space applications as well as kernels)?


Are those available on GCC <= 4.2.0 as per PEP 513?


AFAIU, only
GCC 7.3 and 8 have the retpoline (indirect-branch=thunk) support
enabled by the `-mindirect-branch=thunk
-mindirect-branch-register` CFLAGS.


  On Wednesday, September 12, 2018, Wes Turner > wrote:


"What is a retpoline and how does it work?"

https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work






___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Nearly - all tests PASS for AIX

[Michael]

Dear all,

The last two months I have spent nearly all my free time to cleanup "a
frustration" - from my side - the long list of failing tests for AIX
(there were nearly 20 when I started).

atm - I am stuck on one - test_importlib (mail elsewhere), and the one I
just finished (test_httpservers) may be overly simplified (just skipping
the trailing-slash tests) - see issue34711 for a discussion. I would be
grateful for feedback before I post it as a PR - to avoid working in
circles.

I hope you, the developers and development-minded community consider in
a useful contribution.

Currently - with all my proposed patches combined I have:

393 tests OK.

1 test failed:
    test_importlib

25 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_idle
    test_kqueue test_lzma test_msilib test_ossaudiodev test_readline
    test_spwd test_sqlite test_startfile test_tcl test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_unicode_file
    test_unicode_file_functions test_winconsoleio test_winreg
    test_winsound test_zipfile64

1 re-run test:
    test_importlib

Awaiting comments and suggestions. Many thanks for your time.

Michael Felt




signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Antoine Pitrou]

Hi,

Please don't cross-post so heavily.  python-dev is sufficient for this.

If you want to push this forward, I suggest you measure performance of
Python compiled with and without the Spectre mitigation options, and
report the results here.  That will help vendors and packagers decide
whether they want to pursue the route of enabling those options.

Note there are plenty of data-driven conditional jumps in Python.  It
will not be easy to determine which ones are vulnerable to exploiting
through speculative execution of a mispredicted branch.  The bytecode
evaluation loop sounds like a potential attack target, but it's also
performance-sensitive.

Regards

Antoine.


On Sun, 16 Sep 2018 20:29:06 -0400
Wes Turner  wrote:
> Are all current Python builds and C extensions vulnerable to Spectre
> variants {1, 2, *}?
> 
> There are now multiple threads:
> 
> "SEC: Spectre variant 2: GCC: -mindirect-branch=thunk
> -mindirect-branch-register"
> -
> https://mail.python.org/mm3/archives/list/distutils-...@python.org/thread/4BGE226DB5EWIAT5VCJ75QD5ASOVJZCM/
> - https://mail.python.org/pipermail/python-ideas/2018-September/053473.html
> - https://mail.python.org/pipermail/python-dev/2018-September/155199.html
> 
> 
> Original thread (that I forwarded to security@):
> "[Python-ideas] Executable space protection: NX bit,"
> https://mail.python.org/pipermail/python-ideas/2018-September/053175.html
> > ~ Do trampolines / nested functions in C extensions switch off the NX bit?  
> 
> On Sunday, September 16, 2018, Nathaniel Smith  wrote:
> 
> > On Wed, Sep 12, 2018, 12:29 Joni Orponen  wrote:
> >  
> >> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner  wrote:
> >>  
> >>> Should C extensions that compile all add
> >>> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the
> >>> risk of Spectre variant 2 (which does indeed affect user space 
> >>> applications
> >>> as well as kernels)?
> >>>  
> >>
> >> Are those available on GCC <= 4.2.0 as per PEP 513?
> >>  
> >
> > Pretty sure no manylinux1 compiler is ever going to get these mitigations.
> >
> > For manylinux2010 on x86-64, we can easily use a much newer compiler: RH
> > maintains a recent compiler, currently gcc 7.3, or if that doesn't work for
> > some reason then the conda folks have be apparently figured out how to
> > build the equivalent from gcc upstream releases.
> >  
> 
> Are there different CFLAGS and/or gcc compatibility flags in conda builds
> of Python and C extensions?
> 
> Where are those set in conda builds?
> 
> What's the best way to set CFLAGS in Python builds and C extensions?
> 
> export CFLAGS="-mindirect-branch=thunk -mindirect-branch-register"
> ./configure
> make
> 
> ?
> 
> Why are we supposed to use an old version of GCC that doesn't have the
> retpoline patches that only mitigate Spectre variant 2?
> 
> 
> >
> > Unfortunately, the manylinux2010 infrastructure is not quite ready... I'm
> > pretty sure it needs some volunteers to push it to the finish line, though
> > unfortunately I haven't had enough time to keep track.
> >  
> 
> "PEP 571 -- The manylinux2010 Platform Tag"
> https://www.python.org/dev/peps/pep-0571/
> 
> "Tracking issue for manylinux2010 rollout"
> https://github.com/pypa/manylinux/issues/179
> 
> Are all current Python builds and C extensions vulnerable to Spectre
> variants {1, 2, *}?
> 
> >  
> 



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Official citation for Python

[Stephen J. Turnbull]

Jacqueline Kazil writes:

 > I thought I could take two to three concrete formats and user test
 > there and report on how community members who would be using the
 > citation feel.

+1

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] debugging test_importlib.test_bad_traverse - script status is SUCCESS - but FAIL is expected.

[Michael]

I read the discussion related to issue32374. That seems to be sure that
other events that could
cause the test to fail (i.e., the program executes successfully) are
caught early, and/or ignored
so that the program fails - and the test succeeds.

I am having trouble figuring out why the script below does not fail on
AIX, and would appreciate your assistance in debugging what is
happening, i.e., getting deeper.

Many thanks!

  +270  @unittest.skipIf(not hasattr(sys, 'gettotalrefcount'),
  +271  '--with-pydebug has to be enabled for this test')
  +272  def test_bad_traverse(self):
  +273  ''' Issue #32374: Test that traverse fails when
accessing per-module
  +274  state before Py_mod_exec was executed.
  +275  (Multiphase initialization modules only)
  +276  '''
  +277  script = """if True:
  +278  try:
  +279  from test import support
  +280  import importlib.util as util
  +281  spec = util.find_spec('_testmultiphase')
  +282  spec.name = '_testmultiphase_with_bad_traverse'
  +283
  +284  with support.SuppressCrashReport():
  +285  m = spec.loader.create_module(spec)
  +286  except:
  +287  # Prevent Python-level exceptions from
  +288  # ending the process with non-zero status
  +289  # (We are testing for a crash in C-code)
  +290  pass"""
  +291  assert_python_failure("-c", script)

To make sure the full debug info is loaded I added "-X dev", and for
your reading
added some additional print statements - and for speed run the command
directly.
Regardless of how I run it (calling as a test, or directly) the
end-result is the same.

# Note: I was not able to fine the default "loader.create_module() code"
to add debugging statements.
# Pointer for that is welcome!

./python -X dev '-X' 'faulthandler' '-I' '-c' "if True:
    try:
    from test import support
    import importlib.util as util
    spec = util.find_spec('_testmultiphase')
    spec.name = '_testmultiphase_with_bad_traverse'

    m = spec.loader.create_module(spec)
    print(m)
    print(dir(m))
    print(m.__doc__)
    print(m.__loader__)
    print(m.__name__)
    print(m.__package__)
    print(m.__spec__)
    except:
    # Prevent Python-level exceptions from
    # ending the process with non-zero status
    # (We are testing for a crash in C-code)
    print('in except')"

['__doc__', '__loader__', '__name__', '__package__', '__spec__']
Test module _testmultiphase_with_bad_traverse
None
_testmultiphase_with_bad_traverse
None
None
root@x066:[/data/prj/python/git/Python3-3.8.0]echo $?
0

To get some additional idea of what is happening I added some fprintf
statements:

The additional debug info is: (see diff below)
1. bad_traverse:0
2. bad_traverse:0
1. bad_traverse:0
2. bad_traverse:0
1. bad_traverse:0
2. bad_traverse:0

*** To my SURPRISE *** only one routine with these print statements is
ever called.
I was expecting at more. (only bad_traverse(...) gets called, I was
expecting
both bad_traverse_test (Objects/moduleobject.c) and some kind of
initialization
of m_state->integer.

Since the macro Py_VISIT includes a return() statement, and my debug
statement always print the
second line - I assume Py_VISIT(m_state->integer) is not doing anything
(i.e., vret == 0)

/* Utility macro to help write tp_traverse functions.
 * To use this macro, the tp_traverse function must name its arguments
 * "visit" and "arg".  This is intended to keep tp_traverse functions
 * looking as much alike as possible.
 */
#define Py_VISIT(op)    \
    do {    \
    if (op) {   \
    int vret = visit((PyObject *)(op), arg);    \
    if (vret)   \
    return vret;    \
    }   \
    } while (0)


Is this what it should be?

root@x066:[/data/prj/python/git/Python3-3.8.0]git status
On branch aix-pr
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

    modified:   Modules/_testmultiphase.c
    modified:   Objects/moduleobject.c

no changes added to commit (use "git add" and/or "git commit -a")
root@x066:[/data/prj/python/git/Pytho