+jorgelo

> ERR wpa_supplicant[619]: ENGINE: engine init failed (engine: pkcs11) [error:80001401:Vendor defined:PKCS11_CTX_load:Unable to load PKCS#11 module]

I don't see this error on a known-good system (running M57) so I suspect the error is indicative of a real problem.

I don't see any recent changes to the wpa_supplicant code that would cause trouble.  The last openssl version bump was in May.  So my best guess is that it might be related to the recent chaps hardening.

I do not see any chaps-related errors in /var/log/messages.  Just the supplicant + shill errors.

I do see this error on my Chromebook, and it does not have the NoNewPrivs change (CL:539895) because the ebuild has not been revbumped yet.

What do you think?

Can you check "cat /proc/`pgrep wpa`/status | grep NoNewPrivs" on your device? wpa_supplicant is a 9999 ebuild so I'm pretty sure you will have the change.

If you have the change, can you remove "-n" from the wpa_supplicant.conf file in /etc/init and see if you cannot repro anymore? That would be indicative of this being related to no_new_privs.

Does wpa_supplicant execute anything? NNP only applies if you're executing something.

> Can you check "cat /proc/`pgrep wpa`/status | grep NoNewPrivs" on your device?

# cat /proc/`pgrep wpa`/status | grep NoNewPrivs
NoNewPrivs:	0

> If you have the change, can you remove "-n" from the wpa_supplicant.conf file

There is no -n or NoNewPrivs comment in /etc/init/wpasupplicant.conf (which is how I know I don't have the change).

I have also been experimenting with rewinding to old versions of platform2/chaps and deploying the -9999 ebuild.  But that doesn't seem to make a difference either.  All that seemed to do is erase the user cert that I used to have installed.

I take that back then. I was under the impression that the CQ was going to revbump the ebuild, will talk to Mike about that.

As for wpa_supplicant, is

    960 2017-07-10T14:43:58.723551-07:00 ERR wpa_supplicant[619]: ENGINE: engine init failed (engine: pkcs11) [error:80001401:Vendor defined:PKCS11_CTX_load:Unable to load PKCS#11 module]

the first error? Where does that pkcs11 module live? Can we add some logging to wpa_supplicant to understand what error it's encountering? (I.e. file doesn't exist, permission issue, etc?)

> is <X> the first error?

Yes, that is where the bad case diverges from the good case.

> Where does that pkcs11 module live?

Guessing /usr/lib64/libchaps.so and maybe /usr/lib64/engines/engine_pkcs11.so

> Can we add some logging to wpa_supplicant to understand what error it's encountering?

The error seems to be coming from libp11 or openssl, not supplicant itself.  All that I see in strace is:

643   sendto(3, "<183>Jul 10 16:17:10 wpa_supplicant[643]: EAP: Initialize selected EAP method: vendor 0 method 
13 (TLS)", 103, MSG_NOSIGNAL, NULL, 0) = 103
643   sendto(3, "<183>Jul 10 16:17:10 wpa_supplicant[643]: TLS: using phase1 config options", 74, MSG_NOSIGNAL, 
NULL, 0) = 74
643   sendto(3, "<183>Jul 10 16:17:10 wpa_supplicant[643]: SSL: Initializing TLS engine", 70, MSG_NOSIGNAL, NULL, 0) = 70
643   write(2, "Unable to load module (null)\n", 29) = 29
643   sendto(3, "<179>Jul 10 16:17:10 wpa_supplicant[643]: ENGINE: engine init failed (engine: pkcs11) [error:80001401:Vendor defined:PKCS11_CTX_load:Unable to load PKCS#11 module]", 163, MSG_NOSIGNAL, NULL, 0) = 163
643   sendto(3, "<181>Jul 10 16:17:10 wpa_supplicant[643]: TLS: Failed to set TLS connection parameters", 86, MSG_NOSIGNAL, NULL, 0) = 86
643   sendto(3, "<183>Jul 10 16:17:10 wpa_supplicant[643]: ENGINE: engine deinit", 63, MSG_NOSIGNAL, NULL, 0) = 63
643   sendto(3, "<181>Jul 10 16:17:10 wpa_supplicant[643]: EAP-TLS: Failed to initialize SSL.", 76, MSG_NOSIGNAL, NULL, 0) = 76


Going back to the attempted reverts of recent platform2/chaps commits, I am still seeing a problem where reverting some harmless-looking patches is causing my user cert to disappear.  Also, when I try to re-import the cert, it crashes Chrome.  The reverts were:

  3a7749a311db Revert "chaps: Move SetProcessUserAndGroup() to chapsd.cc."
  268a7a5fb183 Revert "chaps: refactor ChapsProxy to hide initialization"
  80fe3ca3f898 Revert "chaps: Use Minijail for priv dropping."

The chaps CLs (at least 3a.. and 80..) were refactors that don't change functionality: it's the same priv-dropping code (drop user to chaps, group to chronos-access, inherit groups from chaps user.)

I can't seem to connect to my test device so I'm building a VM to double-check things.

Noticed that on a fresh invocation (not from upstart) supplicant is loading a file from libp11 right before it fails.  libp11 was upgraded from 0.2.8 to 0.4.4 last week.  I'm reverting it to see if it makes a difference.

chaps gropus/users look sane FWIW.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd

commit c39adfb7f7cdc7befcf69eb15e82ff68771a0efd
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Tue Jul 11 07:39:02 2017

Revert "dev-libs/libp11: Update to latest from gentoo"

This reverts commit 6f694ce64e823617911c2530037ffa23b819610e, which
appears to be breaking EAP-TLS.

BUG= chromium:740721 
TEST=manually build a fresh image with 0.2.8, try connecting to Google-A
     using a bogus client cert, and verify in net.log that the TLS engine
     can be initialized.

Change-Id: Iad0cd557d7b839f6f4622e37ddce4881f5032eb9
Reviewed-on: https://chromium-review.googlesource.com/566283
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd/dev-libs/libp11/metadata.xml
[modify] https://crrev.com/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd/dev-libs/libp11/Manifest
[add] https://crrev.com/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd/dev-libs/libp11/files/libp11-0.2.8-no-ltdl.patch
[delete] https://crrev.com/6f694ce64e823617911c2530037ffa23b819610e/dev-libs/libp11/libp11-0.4.4.ebuild
[add] https://crrev.com/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd/dev-libs/libp11/files/libp11-0.2.8-variable-buffer-size.patch
[add] https://crrev.com/c39adfb7f7cdc7befcf69eb15e82ff68771a0efd/dev-libs/libp11/libp11-0.2.8-r3.ebuild

Kevin,

I can verify fixes using the network_WiFi_SimpleConnect.wifi_check1x_WPA autotest, but it requires a special wifi lab setup.

How exactly did you do this: "try connecting to Google-A using a bogus client cert"?

Working as expected. Samus & Eve R61-9734.0.0