[Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Alexander Hermes]

Folks,

I'm looking for some guidance on how to troubleshoot/debug an issue with (S=
ELinux) labels over NFS that we've been having as a result of a kernel upgr=
ade - description below.
I looked around on http://linux-nfs.org but was not able to find how to deb=
ug this kind of issue with labels - everything I found relates to more fund=
amental issues like mounts plain not working.=20

With apologies for sending this to the devel mailing list, could you please=
 help me get to the bottom of this? Or redirect me to somewhere / someone t=
hat can?

Thank you very much,

Alexander Hermes

----

## Summary

In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from=
 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS =
v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label=
 support - attempting to change labels on a mounted file leads to "Operatio=
n Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to th=
e earlier kernel version the issue goes away.

## Background

As part of our gitlab HA deployment we use NFS to host data on a back end s=
erver that is then mounted by application servers (cf. https://docs.gitlab.=
com/ce/administration/high_availability/nfs.html). To do this we have a fai=
rly typical setup where the server (in this example "enfigitback2-devel") e=
xports a bunch of mounts via /etc/exports which are then mounted on a coupl=
e of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").

## The issue

On the new kernel I am not able to change or view the SELinux labels of fil=
es / directories mounted on the client:

```
[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/=
gitlab/.ssh/authorized_keys
chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' t=
o 'system_u:object_r:ssh_home_t:s0': Operation not supported
[root@enfigitfront2-devel ~]# uname -r
3.10.0-693.2.2.el7.x86_64
```
On the old kernel I am:

```
[root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t /var/opt/=
gitlab/.ssh/authorized_keys
[root@enfigitfront1-devel ~]# uname -r
3.10.0-327.36.2.el7.x86_64
```

We can't keep using the old kernel forever so I'd like to get to the bottom=
 of this - what could this be due to? How can I debug this further to under=
stand where the "Operation not supported" is coming from?

## Server details
Distro: CentOS 7.3 / 7.4
Kernel (`uname -r`):=20
 * 3.10.0-514.10.2.el7.x86_64 (server)
* 3.10.0-693.2.2.el7.x86_64 (client - new)
* 3.10.0-327.36.2.el7.x86_64 (client - old)
nfs-utils: RPM package version 1.3.0

=20
Server mount option example:
/export/.ssh 172.18.10.148(rw,sync,no_root_squash) 172.18.10.151(rw,sync,no=
_root_squash)

Client mount options (/etc/fstab):
enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    nfs=
     defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netdev,loo=
kupcache=3Dnone 0       0

## Debugging I've done

### Mounting by hand
I tried to mount one of the exported mounts "by hand" using `mount` and fou=
nd the following:
* mounting the same export on a different mount point using the same option=
s as in /etc/fstab yields a mount that has the same issue
* mounting with `nosharecache` results in a mount that *does not* have the =
issue.

Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Scott Mayhew]

On Tue, 21 Nov 2017, Alexander Hermes wrote:

> Folks,
> 
> I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below.
> I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. 
> 
> With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can?
> 
> Thank you very much,
> 
> Alexander Hermes
> 
> ----
> 
> ## Summary
> 
> In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away.
> 
> ## Background
> 
> As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").
> 
> ## The issue
> 
> On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client:
> 
> ```
> [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys
> chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported
> [root@enfigitfront2-devel ~]# uname -r
> 3.10.0-693.2.2.el7.x86_64
> ```
> On the old kernel I am:
> 
> ```
> [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys
> [root@enfigitfront1-devel ~]# uname -r
> 3.10.0-327.36.2.el7.x86_64
> ```
> 
> We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from?
> 
> ## Server details
> Distro: CentOS 7.3 / 7.4
> Kernel (`uname -r`): 
>  * 3.10.0-514.10.2.el7.x86_64 (server)
> * 3.10.0-693.2.2.el7.x86_64 (client - new)
> * 3.10.0-327.36.2.el7.x86_64 (client - old)
> nfs-utils: RPM package version 1.3.0
> 
>  
> Server mount option example:
> /export/.ssh 172.18.10.148(rw,sync,no_root_squash) 172.18.10.151(rw,sync,no_root_squash)

Add "security_label" to the export options above.  If you don't see
"security_label" listed in the exports(5) man page then you need to
upgrade your nfs-utils package.

-Scott

> 
> Client mount options (/etc/fstab):
> enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    nfs     defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0       0
> 
> ## Debugging I've done
> 
> ### Mounting by hand
> I tried to mount one of the exported mounts "by hand" using `mount` and found the following:
> * mounting the same export on a different mount point using the same options as in /etc/fstab yields a mount that has the same issue
> * mounting with `nosharecache` results in a mount that *does not* have the issue.
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Alexander Hermes]

> Folks,
>=20
> I'm looking for some guidance on how to troubleshoot/debug an issue with =
(SELinux) labels over NFS that we've been having as a result of a kernel up=
grade - description below.
> I looked around on http://linux-nfs.org but was not able to find how to d=
ebug this kind of issue with labels - everything I found relates to more fu=
ndamental issues like mounts plain not working.=20
>=20
> With apologies for sending this to the devel mailing list, could you plea=
se help me get to the bottom of this? Or redirect me to somewhere / someone=
 that can?
>=20
> Thank you very much,
>=20
> Alexander Hermes
>=20
> ----
>=20
> ## Summary
>=20
> In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel fr=
om 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NF=
S v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux lab=
el support - attempting to change labels on a mounted file leads to "Operat=
ion Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to =
the earlier kernel version the issue goes away.
>=20
> ## Background
>=20
> As part of our gitlab HA deployment we use NFS to host data on a back end=
 server that is then mounted by application servers (cf. https://docs.gitla=
b.com/ce/administration/high_availability/nfs.html). To do this we have a f=
airly typical setup where the server (in this example "enfigitback2-devel")=
 exports a bunch of mounts via /etc/exports which are then mounted on a cou=
ple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").
>=20
> ## The issue
>=20
> On the new kernel I am not able to change or view the SELinux labels of f=
iles / directories mounted on the client:
>=20
> ```
> [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t=20
> /var/opt/gitlab/.ssh/authorized_keys
> chcon: failed to change context of=20
> '/var/opt/gitlab/.ssh/authorized_keys' to=20
> 'system_u:object_r:ssh_home_t:s0': Operation not supported=20
> [root@enfigitfront2-devel ~]# uname -r
> 3.10.0-693.2.2.el7.x86_64
> ```
> On the old kernel I am:
>=20
> ```
> [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t=20
> /var/opt/gitlab/.ssh/authorized_keys
> [root@enfigitfront1-devel ~]# uname -r
> 3.10.0-327.36.2.el7.x86_64
> ```
>=20
> We can't keep using the old kernel forever so I'd like to get to the bott=
om of this - what could this be due to? How can I debug this further to und=
erstand where the "Operation not supported" is coming from?
>=20
> ## Server details
> Distro: CentOS 7.3 / 7.4
> Kernel (`uname -r`):=20
>  * 3.10.0-514.10.2.el7.x86_64 (server)
> * 3.10.0-693.2.2.el7.x86_64 (client - new)
> * 3.10.0-327.36.2.el7.x86_64 (client - old)
> nfs-utils: RPM package version 1.3.0
>=20
> =20
> Server mount option example:
> /export/.ssh 172.18.10.148(rw,sync,no_root_squash)=20
> 172.18.10.151(rw,sync,no_root_squash)

Add "security_label" to the export options above.  If you don't see "securi=
ty_label" listed in the exports(5) man page then you need to upgrade your n=
fs-utils package.

-Scott

>=20
> Client mount options (/etc/fstab):
> enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    n=
fs     defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netdev,l=
ookupcache=3Dnone 0       0
>=20
> ## Debugging I've done
>=20
> ### Mounting by hand
> I tried to mount one of the exported mounts "by hand" using `mount` and f=
ound the following:
> * mounting the same export on a different mount point using the same=20
> options as in /etc/fstab yields a mount that has the same issue
> * mounting with `nosharecache` results in a mount that *does not* have th=
e issue.
>=20
>=20


Hi Scott,

Thank you for pointing out "security_label". I have applied the option...

	/export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.1=
0.151(rw,sync,no_root_squash,security_label)

and rebooted both server and client (in that order), but I still see the sa=
me behaviour as before on the server with the uplevel kernel:

	[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt=
/gitlab/.ssh/authorized_keys
	chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' =
to 'system_u:object_r:ssh_home_t:s0': Operation not supported

I notice that the exports(5) man page mentions " This will only work if all=
 clients use a consistent security policy." under security_label. I'm not s=
ure what a "consistent security policy" means - what does this mean in term=
s of options/configuration?=20

Thanks for the help,
Alex

Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Scott Mayhew]

On Tue, 21 Nov 2017, Alexander Hermes wrote:

> > Folks,
> > 
> > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below.
> > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. 
> > 
> > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can?
> > 
> > Thank you very much,
> > 
> > Alexander Hermes
> > 
> > ----
> > 
> > ## Summary
> > 
> > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away.
> > 
> > ## Background
> > 
> > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").
> > 
> > ## The issue
> > 
> > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client:
> > 
> > ```
> > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t 
> > /var/opt/gitlab/.ssh/authorized_keys
> > chcon: failed to change context of 
> > '/var/opt/gitlab/.ssh/authorized_keys' to 
> > 'system_u:object_r:ssh_home_t:s0': Operation not supported 
> > [root@enfigitfront2-devel ~]# uname -r
> > 3.10.0-693.2.2.el7.x86_64
> > ```
> > On the old kernel I am:
> > 
> > ```
> > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t 
> > /var/opt/gitlab/.ssh/authorized_keys
> > [root@enfigitfront1-devel ~]# uname -r
> > 3.10.0-327.36.2.el7.x86_64
> > ```
> > 
> > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from?
> > 
> > ## Server details
> > Distro: CentOS 7.3 / 7.4
> > Kernel (`uname -r`): 
> >  * 3.10.0-514.10.2.el7.x86_64 (server)
> > * 3.10.0-693.2.2.el7.x86_64 (client - new)
> > * 3.10.0-327.36.2.el7.x86_64 (client - old)
> > nfs-utils: RPM package version 1.3.0
> > 
> >  
> > Server mount option example:
> > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) 
> > 172.18.10.151(rw,sync,no_root_squash)
> 
> Add "security_label" to the export options above.  If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package.
> 
> -Scott
> 
> > 
> > Client mount options (/etc/fstab):
> > enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    nfs     defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0       0
> > 
> > ## Debugging I've done
> > 
> > ### Mounting by hand
> > I tried to mount one of the exported mounts "by hand" using `mount` and found the following:
> > * mounting the same export on a different mount point using the same 
> > options as in /etc/fstab yields a mount that has the same issue
> > * mounting with `nosharecache` results in a mount that *does not* have the issue.
> > 
> > 
> 
> 
> Hi Scott,
> 
> Thank you for pointing out "security_label". I have applied the option...
> 
> 	/export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.10.151(rw,sync,no_root_squash,security_label)
> 
> and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel:
> 
> 	[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys
> 	chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported
> 
> I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? 

I'm assuming  that means you don't want some clients using full labeled
NFS, others mounting with the context= mount option, and others with
SELinux completely disabled.  With labeled NFS, the creation and
enforcement of labels happens on the client side and the server just
stores the labels.

Anyways, I missed the fact that your clients are using an earlier
kernel.  In order to get the desired behavior when mounting an NFS
server that is using the "security_label" export option, you're pretty
much going to need to run an updated kernel on the clients too...
specifically one with commit 0b4d3452b "security/selinux: allow
security_sb_clone_mnt_opts to enable/disable native labeling behavior".
AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it).

-Scott


> 
> Thanks for the help,
> Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[J. Bruce Fields]

On Mon, Nov 27, 2017 at 08:51:37AM -0500, Scott Mayhew wrote:
> On Tue, 21 Nov 2017, Alexander Hermes wrote:
> 
> > > Folks,
> > > 
> > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below.
> > > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. 
> > > 
> > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can?
> > > 
> > > Thank you very much,
> > > 
> > > Alexander Hermes
> > > 
> > > ----
> > > 
> > > ## Summary
> > > 
> > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away.
> > > 
> > > ## Background
> > > 
> > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").
> > > 
> > > ## The issue
> > > 
> > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client:
> > > 
> > > ```
> > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t 
> > > /var/opt/gitlab/.ssh/authorized_keys
> > > chcon: failed to change context of 
> > > '/var/opt/gitlab/.ssh/authorized_keys' to 
> > > 'system_u:object_r:ssh_home_t:s0': Operation not supported 
> > > [root@enfigitfront2-devel ~]# uname -r
> > > 3.10.0-693.2.2.el7.x86_64
> > > ```
> > > On the old kernel I am:
> > > 
> > > ```
> > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t 
> > > /var/opt/gitlab/.ssh/authorized_keys
> > > [root@enfigitfront1-devel ~]# uname -r
> > > 3.10.0-327.36.2.el7.x86_64
> > > ```
> > > 
> > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from?
> > > 
> > > ## Server details
> > > Distro: CentOS 7.3 / 7.4
> > > Kernel (`uname -r`): 
> > >  * 3.10.0-514.10.2.el7.x86_64 (server)
> > > * 3.10.0-693.2.2.el7.x86_64 (client - new)
> > > * 3.10.0-327.36.2.el7.x86_64 (client - old)
> > > nfs-utils: RPM package version 1.3.0
> > > 
> > >  
> > > Server mount option example:
> > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) 
> > > 172.18.10.151(rw,sync,no_root_squash)
> > 
> > Add "security_label" to the export options above.  If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package.
> > 
> > -Scott
> > 
> > > 
> > > Client mount options (/etc/fstab):
> > > enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    nfs     defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0       0
> > > 
> > > ## Debugging I've done
> > > 
> > > ### Mounting by hand
> > > I tried to mount one of the exported mounts "by hand" using `mount` and found the following:
> > > * mounting the same export on a different mount point using the same 
> > > options as in /etc/fstab yields a mount that has the same issue
> > > * mounting with `nosharecache` results in a mount that *does not* have the issue.
> > > 
> > > 
> > 
> > 
> > Hi Scott,
> > 
> > Thank you for pointing out "security_label". I have applied the option...
> > 
> > 	/export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.10.151(rw,sync,no_root_squash,security_label)
> > 
> > and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel:
> > 
> > 	[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys
> > 	chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported
> > 
> > I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? 
> 
> I'm assuming  that means you don't want some clients using full labeled
> NFS, others mounting with the context= mount option, and others with
> SELinux completely disabled.  With labeled NFS, the creation and
> enforcement of labels happens on the client side and the server just
> stores the labels.

So also for example if the clients disagree about how to label files in
your home directory, or something, then things will likely break.  I
don't know how big a problem that is in practice.

--b.

> 
> Anyways, I missed the fact that your clients are using an earlier
> kernel.  In order to get the desired behavior when mounting an NFS
> server that is using the "security_label" export option, you're pretty
> much going to need to run an updated kernel on the clients too...
> specifically one with commit 0b4d3452b "security/selinux: allow
> security_sb_clone_mnt_opts to enable/disable native labeling behavior".
> AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it).
> 
> -Scott
> 
> 
> > 
> > Thanks for the help,
> > Alex
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Alexander Hermes]

> On Tue, 21 Nov 2017, Alexander Hermes wrote:
>=20
> > > Folks,
> > >=20
> > > I'm looking for some guidance on how to troubleshoot/debug an issue w=
ith (SELinux) labels over NFS that we've been having as a result of a kerne=
l upgrade - description below.
> > > I looked around on http://linux-nfs.org but was not able to find how =
to debug this kind of issue with labels - everything I found relates to mor=
e fundamental issues like mounts plain not working.=20
> > >=20
> > > With apologies for sending this to the devel mailing list, could you =
please help me get to the bottom of this? Or redirect me to somewhere / som=
eone that can?
> > >=20
> > > Thank you very much,
> > >=20
> > > Alexander Hermes
> > >=20
> > > ----
> > >=20
> > > ## Summary
> > >=20
> > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kerne=
l from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result=
, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux=
 label support - attempting to change labels on a mounted file leads to "Op=
eration Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting=
 to the earlier kernel version the issue goes away.
> > >=20
> > > ## Background
> > >=20
> > > As part of our gitlab HA deployment we use NFS to host data on a back=
 end server that is then mounted by application servers (cf. https://docs.g=
itlab.com/ce/administration/high_availability/nfs.html). To do this we have=
 a fairly typical setup where the server (in this example "enfigitback2-dev=
el") exports a bunch of mounts via /etc/exports which are then mounted on a=
 couple of application servers ("enfigitfront1-devel" / "enfigitfront2-deve=
l").
> > >=20
> > > ## The issue
> > >=20
> > > On the new kernel I am not able to change or view the SELinux labels =
of files / directories mounted on the client:
> > >=20
> > > ```
> > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t=20
> > > /var/opt/gitlab/.ssh/authorized_keys
> > > chcon: failed to change context of=20
> > > '/var/opt/gitlab/.ssh/authorized_keys' to
> > > 'system_u:object_r:ssh_home_t:s0': Operation not supported=20
> > > [root@enfigitfront2-devel ~]# uname -r
> > > 3.10.0-693.2.2.el7.x86_64
> > > ```
> > > On the old kernel I am:
> > >=20
> > > ```
> > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t=20
> > > /var/opt/gitlab/.ssh/authorized_keys
> > > [root@enfigitfront1-devel ~]# uname -r
> > > 3.10.0-327.36.2.el7.x86_64
> > > ```
> > >=20
> > > We can't keep using the old kernel forever so I'd like to get to the =
bottom of this - what could this be due to? How can I debug this further to=
 understand where the "Operation not supported" is coming from?
> > >=20
> > > ## Server details
> > > Distro: CentOS 7.3 / 7.4
> > > Kernel (`uname -r`):=20
> > >  * 3.10.0-514.10.2.el7.x86_64 (server)
> > > * 3.10.0-693.2.2.el7.x86_64 (client - new)
> > > * 3.10.0-327.36.2.el7.x86_64 (client - old)
> > > nfs-utils: RPM package version 1.3.0
> > >=20
> > > =20
> > > Server mount option example:
> > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash)
> > > 172.18.10.151(rw,sync,no_root_squash)
> >=20
> > Add "security_label" to the export options above.  If you don't see "se=
curity_label" listed in the exports(5) man page then you need to upgrade yo=
ur nfs-utils package.
> >=20
> > -Scott
> >=20
> > >=20
> > > Client mount options (/etc/fstab):
> > > enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh =
   nfs     defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netd=
ev,lookupcache=3Dnone 0       0
> > >=20
> > > ## Debugging I've done
> > >=20
> > > ### Mounting by hand
> > > I tried to mount one of the exported mounts "by hand" using `mount` a=
nd found the following:
> > > * mounting the same export on a different mount point using the=20
> > > same options as in /etc/fstab yields a mount that has the same=20
> > > issue
> > > * mounting with `nosharecache` results in a mount that *does not* hav=
e the issue.
> > >=20
> > >=20
> >=20
> >=20
> > Hi Scott,
> >=20
> > Thank you for pointing out "security_label". I have applied the option.=
..
> >=20
> > 	/export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label)=20
> > 172.18.10.151(rw,sync,no_root_squash,security_label)
> >=20
> > and rebooted both server and client (in that order), but I still see th=
e same behaviour as before on the server with the uplevel kernel:
> >=20
> > 	[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var=
/opt/gitlab/.ssh/authorized_keys
> > 	chcon: failed to change context of=20
> > '/var/opt/gitlab/.ssh/authorized_keys' to=20
> > 'system_u:object_r:ssh_home_t:s0': Operation not supported
> >=20
> > I notice that the exports(5) man page mentions " This will only work if=
 all clients use a consistent security policy." under security_label. I'm n=
ot sure what a "consistent security policy" means - what does this mean in =
terms of options/configuration?=20
>=20
> I'm assuming  that means you don't want some clients using full=20
> labeled NFS, others mounting with the context=3D mount option, and=20
> others with SELinux completely disabled.  With labeled NFS, the=20
> creation and enforcement of labels happens on the client side and the=20
> server just stores the labels.

So also for example if the clients disagree about how to label files in you=
r home directory, or something, then things will likely break.  I don't kno=
w how big a problem that is in practice.

--b.

>=20
> Anyways, I missed the fact that your clients are using an earlier=20
> kernel.  In order to get the desired behavior when mounting an NFS=20
> server that is using the "security_label" export option, you're pretty=20
> much going to need to run an updated kernel on the clients too...
> specifically one with commit 0b4d3452b "security/selinux: allow=20
> security_sb_clone_mnt_opts to enable/disable native labeling behavior".
> AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it).
>=20
> -Scott
>=20
>=20
> >=20
> > Thanks for the help,
> > Alex
> > --

Hi,

Thanks for the reply. Yes, I imagine there'd be problems if clients are con=
fused about what labels are applied, but I just wanted to check if anyone k=
new of that actually preventing other clients from reading or setting label=
s at all (throwing "Operation not supported" errors). It sounds from what y=
ou are saying like that is _not_ the case.

Scott, I just want to clarify your comment about clients using an earlier k=
ernel.  Since my original message we now have the following kernels

Server: 			3.10.0-693.5.2.el7.x86_64
Client (working): 	3.10.0-327.36.2.el7.x86_64
Client (non-working): 	3.10.0-693.2.2.el7.x86_64

So it's the _working_ client which has the down-level kernel. Are you sayin=
g it needs to be up-level also for this to work? Or do you mean that all of=
 the versions are too old somehow?=20
This was working when all servers were down-level (CentOS 7.3 kernel so 3.1=
0-327) _without_ the "security_label" exports option - did the new kernel t=
ighten the security such that this is now required?

Separately, do either of you know of a sensible way I can debug the root ca=
use for the issue further (to get a more detail why "Operation not supporte=
d" is thrown)? I don't know the kernel source at all so just reading the co=
de is not viable for me (without some guidance), but is there some logging =
or more verbose output I can turn on?

Alex

Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Scott Mayhew]

On Tue, 28 Nov 2017, Alexander Hermes wrote:

> > On Tue, 21 Nov 2017, Alexander Hermes wrote:
> > 
> > > > Folks,
> > > > 
> > > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below.
> > > > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. 
> > > > 
> > > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can?
> > > > 
> > > > Thank you very much,
> > > > 
> > > > Alexander Hermes
> > > > 
> > > > ----
> > > > 
> > > > ## Summary
> > > > 
> > > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away.
> > > > 
> > > > ## Background
> > > > 
> > > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel").
> > > > 
> > > > ## The issue
> > > > 
> > > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client:
> > > > 
> > > > ```
> > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t 
> > > > /var/opt/gitlab/.ssh/authorized_keys
> > > > chcon: failed to change context of 
> > > > '/var/opt/gitlab/.ssh/authorized_keys' to
> > > > 'system_u:object_r:ssh_home_t:s0': Operation not supported 
> > > > [root@enfigitfront2-devel ~]# uname -r
> > > > 3.10.0-693.2.2.el7.x86_64
> > > > ```
> > > > On the old kernel I am:
> > > > 
> > > > ```
> > > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t 
> > > > /var/opt/gitlab/.ssh/authorized_keys
> > > > [root@enfigitfront1-devel ~]# uname -r
> > > > 3.10.0-327.36.2.el7.x86_64
> > > > ```
> > > > 
> > > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from?
> > > > 
> > > > ## Server details
> > > > Distro: CentOS 7.3 / 7.4
> > > > Kernel (`uname -r`): 
> > > >  * 3.10.0-514.10.2.el7.x86_64 (server)
> > > > * 3.10.0-693.2.2.el7.x86_64 (client - new)
> > > > * 3.10.0-327.36.2.el7.x86_64 (client - old)
> > > > nfs-utils: RPM package version 1.3.0
> > > > 
> > > >  
> > > > Server mount option example:
> > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash)
> > > > 172.18.10.151(rw,sync,no_root_squash)
> > > 
> > > Add "security_label" to the export options above.  If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package.
> > > 
> > > -Scott
> > > 
> > > > 
> > > > Client mount options (/etc/fstab):
> > > > enfigitback2-devel.datcon.co.uk:/export/.ssh    /var/opt/gitlab/.ssh    nfs     defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0       0
> > > > 
> > > > ## Debugging I've done
> > > > 
> > > > ### Mounting by hand
> > > > I tried to mount one of the exported mounts "by hand" using `mount` and found the following:
> > > > * mounting the same export on a different mount point using the 
> > > > same options as in /etc/fstab yields a mount that has the same 
> > > > issue
> > > > * mounting with `nosharecache` results in a mount that *does not* have the issue.
> > > > 
> > > > 
> > > 
> > > 
> > > Hi Scott,
> > > 
> > > Thank you for pointing out "security_label". I have applied the option...
> > > 
> > > 	/export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 
> > > 172.18.10.151(rw,sync,no_root_squash,security_label)
> > > 
> > > and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel:
> > > 
> > > 	[root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys
> > > 	chcon: failed to change context of 
> > > '/var/opt/gitlab/.ssh/authorized_keys' to 
> > > 'system_u:object_r:ssh_home_t:s0': Operation not supported
> > > 
> > > I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? 
> > 
> > I'm assuming  that means you don't want some clients using full 
> > labeled NFS, others mounting with the context= mount option, and 
> > others with SELinux completely disabled.  With labeled NFS, the 
> > creation and enforcement of labels happens on the client side and the 
> > server just stores the labels.
> 
> So also for example if the clients disagree about how to label files in your home directory, or something, then things will likely break.  I don't know how big a problem that is in practice.
> 
> --b.
> 
> > 
> > Anyways, I missed the fact that your clients are using an earlier 
> > kernel.  In order to get the desired behavior when mounting an NFS 
> > server that is using the "security_label" export option, you're pretty 
> > much going to need to run an updated kernel on the clients too...
> > specifically one with commit 0b4d3452b "security/selinux: allow 
> > security_sb_clone_mnt_opts to enable/disable native labeling behavior".
> > AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it).
> > 
> > -Scott
> > 
> > 
> > > 
> > > Thanks for the help,
> > > Alex
> > > --
> 
> Hi,
> 
> Thanks for the reply. Yes, I imagine there'd be problems if clients are confused about what labels are applied, but I just wanted to check if anyone knew of that actually preventing other clients from reading or setting labels at all (throwing "Operation not supported" errors). It sounds from what you are saying like that is _not_ the case.

That's correct.

> 
> Scott, I just want to clarify your comment about clients using an earlier kernel.  Since my original message we now have the following kernels
> 
> Server: 			3.10.0-693.5.2.el7.x86_64
> Client (working): 	3.10.0-327.36.2.el7.x86_64
> Client (non-working): 	3.10.0-693.2.2.el7.x86_64
> 
> So it's the _working_ client which has the down-level kernel.

That's the opposite from what I'm seeing if I install the RHEL kernels
corresponding to the CentOS versions you have listed.

> Are you saying it needs to be up-level also for this to work? Or do you mean that all of the versions are too old somehow? 
> This was working when all servers were down-level (CentOS 7.3 kernel so 3.10-327) _without_ the "security_label" exports option - did the new kernel tighten the security such that this is now required?

Yes, I was saying that in order to use the "security_label" option, your
NFS server and NFS clients need to be running 7.4 kernels.  But it
sounds like there's something else going on here that I'm not
understanding.  Here's what I see when I install the same kernel
versions that you have.

On my NFS server I have a single export with the "security_label"
option:

[root@nfsserver ~]# uname -r
3.10.0-693.5.2.el7.x86_64
[root@nfsserver ~]# cat /etc/exports
/export *(rw,insecure,no_root_squash,security_label)
[root@nfsserver ~]# exportfs -v
/export         <world>(rw,sync,wdelay,hide,no_subtree_check,security_label,sec=sys,insecure,no_root_squash,no_all_squash)

If I mount using the older kernel, I can see the label but I can't
change it:

[root@rhel72 ~]# uname -r
3.10.0-327.36.2.el7.x86_64
[root@rhel72 ~]# mount -o v4.2 nfsserver:/export /mnt/t
[root@rhel72 ~]# ls -Z /mnt/t/file
-rw-r--r--. root root system_u:object_r:etc_t:s0       /mnt/t/file
[root@rhel72 ~]# chcon -t usr_t /mnt/t/file
chcon: failed to change context of ‘/mnt/t/file’ to ‘system_u:object_r:usr_t:s0’: Operation not supported

If I mount using the newer kernel, I can see and change the label:

[root@rhel74 ~]# uname -r
3.10.0-693.2.2.el7.x86_64
[root@rhel74 ~]# mount -o v4.2 nfsserver:/export /mnt/t
[root@rhel74 ~]# ls -Z /mnt/t
-rw-r--r--. root root system_u:object_r:etc_t:s0       file
[root@rhel74 ~]# chcon -t usr_t /mnt/t/file
[root@rhel74 ~]# ls -Z /mnt/t
-rw-r--r--. root root system_u:object_r:usr_t:s0       file

To answer your question, on the NFS server side the older kernel would
always send the individual security labels and a change was made to
make that behavior be opt-in because it was causing problems for some
users (Bruce can correct me on that if I'm wrong).

On the client side there was a problem with setting the appropriate flag
on the superblock that had to do with the way NFSv4 mounts are done. The
client mounts the NFSv4 root and then does a path walk to the real
export.  When it gets to the real export it clones the superblock from
the NFSv4 root.  The flag was not getting set on the clone.  That's what
the commit that I pointed out earlier was fixing.
> 
> Separately, do either of you know of a sensible way I can debug the root cause for the issue further (to get a more detail why "Operation not supported" is thrown)? I don't know the kernel source at all so just reading the code is not viable for me (without some guidance), but is there some logging or more verbose output I can turn on?

There isn't really any verbose logging that I can think of.  When you
get "Operation not supported" from chcon, it pretty much means that the
mount doesn't have the SBLABEL_MNT flag set (RHEL uses an older flag
SE_SBLABELSUPP but it's really the same thing).  You can see whether the
flag is set by looking for the text "seclabel" in the mount options for
your mount in /proc/mounts.  On the older kernel I see this:

[root@rhel72 ~]# grep nfs4 /proc/mounts
nfsserver:/export /mnt/t nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,...

and on the newer kernel I see this:

[root@rhel74 ~]# grep nfs4 /proc/mounts
nfsserver:/export /mnt/t nfs4 rw,seclabel,relatime,vers=4.2,rsize=524288,wsize=524288,...
                                 ^^^^^^^^

The other thing you can look at is the caps field in
/proc/self/mountstats.  If the server has security labels enabled then
the caps field will have NFS_CAP_SECURITY_LABEL set, which is defined as

#define NFS_CAP_SECURITY_LABEL (1U << 18)

You can take the value from the caps field and plug it into a bash printf

[root@rhel74 ~]# grep caps /proc/self/mountstats
        caps:   caps=0x1ffffdf,wtmult=512,dtsize=32768,bsize=0,namlen=255
[root@rhel74 ~]# printf "%x\n" $(( 0x1ffffdf & (1<<18) ))
40000

If you see 0 instead of 40000 then NFS_CAP_SECURITY_LABEL isn't set.

On the older kernel I still see NFS_CAP_SECURITY_LABEL set:

[root@rhel72 ~]# grep caps /proc/self/mountstats
        caps:   caps=0x3fffff,wtmult=512,dtsize=32768,bsize=0,namlen=255
[root@rhel72 ~]# printf "%x\n" $(( 0x3fffff & (1<<18) ))
40000

So in my case the chcon is failing on the older kernel due to the
absence of the SBLABEL_MNT/SE_SBLABELSUPP flag.

-Scott
> 
> Alex

RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693

[Alexander Hermes]

PiA+IE9uIFR1ZSwgMjEgTm92IDIwMTcsIEFsZXhhbmRlciBIZXJtZXMgd3JvdGU6DQo+ID4gDQo+
ID4gPiA+IEZvbGtzLA0KPiA+ID4gPiANCj4gPiA+ID4gSSdtIGxvb2tpbmcgZm9yIHNvbWUgZ3Vp
ZGFuY2Ugb24gaG93IHRvIHRyb3VibGVzaG9vdC9kZWJ1ZyBhbiBpc3N1ZSB3aXRoIChTRUxpbnV4
KSBsYWJlbHMgb3ZlciBORlMgdGhhdCB3ZSd2ZSBiZWVuIGhhdmluZyBhcyBhIHJlc3VsdCBvZiBh
IGtlcm5lbCB1cGdyYWRlIC0gZGVzY3JpcHRpb24gYmVsb3cuDQo+ID4gPiA+IEkgbG9va2VkIGFy
b3VuZCBvbiBodHRwOi8vbGludXgtbmZzLm9yZyBidXQgd2FzIG5vdCBhYmxlIHRvIGZpbmQgaG93
IHRvIGRlYnVnIHRoaXMga2luZCBvZiBpc3N1ZSB3aXRoIGxhYmVscyAtIGV2ZXJ5dGhpbmcgSSBm
b3VuZCByZWxhdGVzIHRvIG1vcmUgZnVuZGFtZW50YWwgaXNzdWVzIGxpa2UgbW91bnRzIHBsYWlu
IG5vdCB3b3JraW5nLiANCj4gPiA+ID4gDQo+ID4gPiA+IFdpdGggYXBvbG9naWVzIGZvciBzZW5k
aW5nIHRoaXMgdG8gdGhlIGRldmVsIG1haWxpbmcgbGlzdCwgY291bGQgeW91IHBsZWFzZSBoZWxw
IG1lIGdldCB0byB0aGUgYm90dG9tIG9mIHRoaXM/IE9yIHJlZGlyZWN0IG1lIHRvIHNvbWV3aGVy
ZSAvIHNvbWVvbmUgdGhhdCBjYW4/DQo+ID4gPiA+IA0KPiA+ID4gPiBUaGFuayB5b3UgdmVyeSBt
dWNoLA0KPiA+ID4gPiANCj4gPiA+ID4gQWxleGFuZGVyIEhlcm1lcw0KPiA+ID4gPiANCj4gPiA+
ID4gLS0tLQ0KPiA+ID4gPiANCj4gPiA+ID4gIyMgU3VtbWFyeQ0KPiA+ID4gPiANCj4gPiA+ID4g
SW4gdXBncmFkaW5nIG91ciBzZXJ2ZXJzIGZyb20gQ2VudE9TIDcuMyB0byA3LjQgd2UgdXBncmFk
ZWQgdGhlIGtlcm5lbCBmcm9tIDMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0IHRvIDMuMTAuMC02
OTMuMi4yLmVsNy54ODZfNjQuIEFzIGEgcmVzdWx0LCBORlMgdjQuMiBtb3VudHMgbW91bnRlZCB2
aWEgL2V0Yy9mc3RhYiBhdCBib290IGRvIG5vdCBoYXZlIHByb3BlciBTRWxpbnV4IGxhYmVsIHN1
cHBvcnQgLSBhdHRlbXB0aW5nIHRvIGNoYW5nZSBsYWJlbHMgb24gYSBtb3VudGVkIGZpbGUgbGVh
ZHMgdG8gIk9wZXJhdGlvbiBOb3QgU3VwcG9ydGVkIi4gYGxzIC1sWmAgc2hvd3MgdGhlIGluY29y
cmVjdCBsYWJlbHMuIFVwb24gcmVib290aW5nIHRvIHRoZSBlYXJsaWVyIGtlcm5lbCB2ZXJzaW9u
IHRoZSBpc3N1ZSBnb2VzIGF3YXkuDQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBCYWNrZ3JvdW5kDQo+
ID4gPiA+IA0KPiA+ID4gPiBBcyBwYXJ0IG9mIG91ciBnaXRsYWIgSEEgZGVwbG95bWVudCB3ZSB1
c2UgTkZTIHRvIGhvc3QgZGF0YSBvbiBhIGJhY2sgZW5kIHNlcnZlciB0aGF0IGlzIHRoZW4gbW91
bnRlZCBieSBhcHBsaWNhdGlvbiBzZXJ2ZXJzIChjZi4gaHR0cHM6Ly9kb2NzLmdpdGxhYi5jb20v
Y2UvYWRtaW5pc3RyYXRpb24vaGlnaF9hdmFpbGFiaWxpdHkvbmZzLmh0bWwpLiBUbyBkbyB0aGlz
IHdlIGhhdmUgYSBmYWlybHkgdHlwaWNhbCBzZXR1cCB3aGVyZSB0aGUgc2VydmVyIChpbiB0aGlz
IGV4YW1wbGUgImVuZmlnaXRiYWNrMi1kZXZlbCIpIGV4cG9ydHMgYSBidW5jaCBvZiBtb3VudHMg
dmlhIC9ldGMvZXhwb3J0cyB3aGljaCBhcmUgdGhlbiBtb3VudGVkIG9uIGEgY291cGxlIG9mIGFw
cGxpY2F0aW9uIHNlcnZlcnMgKCJlbmZpZ2l0ZnJvbnQxLWRldmVsIiAvICJlbmZpZ2l0ZnJvbnQy
LWRldmVsIikuDQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBUaGUgaXNzdWUNCj4gPiA+ID4gDQo+ID4g
PiA+IE9uIHRoZSBuZXcga2VybmVsIEkgYW0gbm90IGFibGUgdG8gY2hhbmdlIG9yIHZpZXcgdGhl
IFNFTGludXggbGFiZWxzIG9mIGZpbGVzIC8gZGlyZWN0b3JpZXMgbW91bnRlZCBvbiB0aGUgY2xp
ZW50Og0KPiA+ID4gPiANCj4gPiA+ID4gYGBgDQo+ID4gPiA+IFtyb290QGVuZmlnaXRmcm9udDIt
ZGV2ZWwgfl0jIGNoY29uIC0tcmVjdXJzaXZlIC0tdHlwZSANCj4gPiA+ID4gc3NoX2hvbWVfdCAv
dmFyL29wdC9naXRsYWIvLnNzaC9hdXRob3JpemVkX2tleXMNCj4gPiA+ID4gY2hjb246IGZhaWxl
ZCB0byBjaGFuZ2UgY29udGV4dCBvZiANCj4gPiA+ID4gJy92YXIvb3B0L2dpdGxhYi8uc3NoL2F1
dGhvcml6ZWRfa2V5cycgdG8NCj4gPiA+ID4gJ3N5c3RlbV91Om9iamVjdF9yOnNzaF9ob21lX3Q6
czAnOiBPcGVyYXRpb24gbm90IHN1cHBvcnRlZCANCj4gPiA+ID4gW3Jvb3RAZW5maWdpdGZyb250
Mi1kZXZlbCB+XSMgdW5hbWUgLXINCj4gPiA+ID4gMy4xMC4wLTY5My4yLjIuZWw3Lng4Nl82NA0K
PiA+ID4gPiBgYGANCj4gPiA+ID4gT24gdGhlIG9sZCBrZXJuZWwgSSBhbToNCj4gPiA+ID4gDQo+
ID4gPiA+IGBgYA0KPiA+ID4gPiBbcm9vdEBlbmZpZ2l0ZnJvbnQxLWRldmVsIH5dIyBjaGNvbiAt
LXJlY3Vyc2l2ZSAtLXR5cGUgDQo+ID4gPiA+IHNzaF9ob21lX3QgL3Zhci9vcHQvZ2l0bGFiLy5z
c2gvYXV0aG9yaXplZF9rZXlzDQo+ID4gPiA+IFtyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwgfl0j
IHVuYW1lIC1yDQo+ID4gPiA+IDMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0DQo+ID4gPiA+IGBg
YA0KPiA+ID4gPiANCj4gPiA+ID4gV2UgY2FuJ3Qga2VlcCB1c2luZyB0aGUgb2xkIGtlcm5lbCBm
b3JldmVyIHNvIEknZCBsaWtlIHRvIGdldCB0byB0aGUgYm90dG9tIG9mIHRoaXMgLSB3aGF0IGNv
dWxkIHRoaXMgYmUgZHVlIHRvPyBIb3cgY2FuIEkgZGVidWcgdGhpcyBmdXJ0aGVyIHRvIHVuZGVy
c3RhbmQgd2hlcmUgdGhlICJPcGVyYXRpb24gbm90IHN1cHBvcnRlZCIgaXMgY29taW5nIGZyb20/
DQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBTZXJ2ZXIgZGV0YWlscw0KPiA+ID4gPiBEaXN0cm86IENl
bnRPUyA3LjMgLyA3LjQNCj4gPiA+ID4gS2VybmVsIChgdW5hbWUgLXJgKTogDQo+ID4gPiA+ICAq
IDMuMTAuMC01MTQuMTAuMi5lbDcueDg2XzY0IChzZXJ2ZXIpDQo+ID4gPiA+ICogMy4xMC4wLTY5
My4yLjIuZWw3Lng4Nl82NCAoY2xpZW50IC0gbmV3KQ0KPiA+ID4gPiAqIDMuMTAuMC0zMjcuMzYu
Mi5lbDcueDg2XzY0IChjbGllbnQgLSBvbGQpDQo+ID4gPiA+IG5mcy11dGlsczogUlBNIHBhY2th
Z2UgdmVyc2lvbiAxLjMuMA0KPiA+ID4gPiANCj4gPiA+ID4gIA0KPiA+ID4gPiBTZXJ2ZXIgbW91
bnQgb3B0aW9uIGV4YW1wbGU6DQo+ID4gPiA+IC9leHBvcnQvLnNzaCAxNzIuMTguMTAuMTQ4KHJ3
LHN5bmMsbm9fcm9vdF9zcXVhc2gpDQo+ID4gPiA+IDE3Mi4xOC4xMC4xNTEocncsc3luYyxub19y
b290X3NxdWFzaCkNCj4gPiA+IA0KPiA+ID4gQWRkICJzZWN1cml0eV9sYWJlbCIgdG8gdGhlIGV4
cG9ydCBvcHRpb25zIGFib3ZlLiAgSWYgeW91IGRvbid0IHNlZSAic2VjdXJpdHlfbGFiZWwiIGxp
c3RlZCBpbiB0aGUgZXhwb3J0cyg1KSBtYW4gcGFnZSB0aGVuIHlvdSBuZWVkIHRvIHVwZ3JhZGUg
eW91ciBuZnMtdXRpbHMgcGFja2FnZS4NCj4gPiA+IA0KPiA+ID4gLVNjb3R0DQo+ID4gPiANCj4g
PiA+ID4gDQo+ID4gPiA+IENsaWVudCBtb3VudCBvcHRpb25zICgvZXRjL2ZzdGFiKToNCj4gPiA+
ID4gZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggICAgL3Zhci9v
cHQvZ2l0bGFiLy5zc2ggICAgbmZzICAgICBkZWZhdWx0cyxzb2Z0LHY0LjIscnNpemU9MTA0ODU3
Nix3c2l6ZT0xMDQ4NTc2LG5vYXRpbWUsX25ldGRldixsb29rdXBjYWNoZT1ub25lIDAgICAgICAg
MA0KPiA+ID4gPiANCj4gPiA+ID4gIyMgRGVidWdnaW5nIEkndmUgZG9uZQ0KPiA+ID4gPiANCj4g
PiA+ID4gIyMjIE1vdW50aW5nIGJ5IGhhbmQNCj4gPiA+ID4gSSB0cmllZCB0byBtb3VudCBvbmUg
b2YgdGhlIGV4cG9ydGVkIG1vdW50cyAiYnkgaGFuZCIgdXNpbmcgYG1vdW50YCBhbmQgZm91bmQg
dGhlIGZvbGxvd2luZzoNCj4gPiA+ID4gKiBtb3VudGluZyB0aGUgc2FtZSBleHBvcnQgb24gYSBk
aWZmZXJlbnQgbW91bnQgcG9pbnQgdXNpbmcgdGhlIA0KPiA+ID4gPiBzYW1lIG9wdGlvbnMgYXMg
aW4gL2V0Yy9mc3RhYiB5aWVsZHMgYSBtb3VudCB0aGF0IGhhcyB0aGUgc2FtZSANCj4gPiA+ID4g
aXNzdWUNCj4gPiA+ID4gKiBtb3VudGluZyB3aXRoIGBub3NoYXJlY2FjaGVgIHJlc3VsdHMgaW4g
YSBtb3VudCB0aGF0ICpkb2VzIG5vdCogaGF2ZSB0aGUgaXNzdWUuDQo+ID4gPiA+IA0KPiA+ID4g
PiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBIaSBTY290dCwNCj4gPiA+IA0KPiA+ID4gVGhhbmsg
eW91IGZvciBwb2ludGluZyBvdXQgInNlY3VyaXR5X2xhYmVsIi4gSSBoYXZlIGFwcGxpZWQgdGhl
IG9wdGlvbi4uLg0KPiA+ID4gDQo+ID4gPiAJL2V4cG9ydC8uc3NoIDE3Mi4xOC4xMC4xNDgocncs
c3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCj4gPiA+IDE3Mi4xOC4xMC4xNTEo
cncsc3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCj4gPiA+IA0KPiA+ID4gYW5k
IHJlYm9vdGVkIGJvdGggc2VydmVyIGFuZCBjbGllbnQgKGluIHRoYXQgb3JkZXIpLCBidXQgSSBz
dGlsbCBzZWUgdGhlIHNhbWUgYmVoYXZpb3VyIGFzIGJlZm9yZSBvbiB0aGUgc2VydmVyIHdpdGgg
dGhlIHVwbGV2ZWwga2VybmVsOg0KPiA+ID4gDQo+ID4gPiAJW3Jvb3RAZW5maWdpdGZyb250Mi1k
ZXZlbCB+XSMgY2hjb24gLS1yZWN1cnNpdmUgLS10eXBlIHNzaF9ob21lX3QgL3Zhci9vcHQvZ2l0
bGFiLy5zc2gvYXV0aG9yaXplZF9rZXlzDQo+ID4gPiAJY2hjb246IGZhaWxlZCB0byBjaGFuZ2Ug
Y29udGV4dCBvZiANCj4gPiA+ICcvdmFyL29wdC9naXRsYWIvLnNzaC9hdXRob3JpemVkX2tleXMn
IHRvDQo+ID4gPiAnc3lzdGVtX3U6b2JqZWN0X3I6c3NoX2hvbWVfdDpzMCc6IE9wZXJhdGlvbiBu
b3Qgc3VwcG9ydGVkDQo+ID4gPiANCj4gPiA+IEkgbm90aWNlIHRoYXQgdGhlIGV4cG9ydHMoNSkg
bWFuIHBhZ2UgbWVudGlvbnMgIiBUaGlzIHdpbGwgb25seSB3b3JrIGlmIGFsbCBjbGllbnRzIHVz
ZSBhIGNvbnNpc3RlbnQgc2VjdXJpdHkgcG9saWN5LiIgdW5kZXIgc2VjdXJpdHlfbGFiZWwuIEkn
bSBub3Qgc3VyZSB3aGF0IGEgImNvbnNpc3RlbnQgc2VjdXJpdHkgcG9saWN5IiBtZWFucyAtIHdo
YXQgZG9lcyB0aGlzIG1lYW4gaW4gdGVybXMgb2Ygb3B0aW9ucy9jb25maWd1cmF0aW9uPyANCj4g
PiANCj4gPiBJJ20gYXNzdW1pbmcgIHRoYXQgbWVhbnMgeW91IGRvbid0IHdhbnQgc29tZSBjbGll
bnRzIHVzaW5nIGZ1bGwgDQo+ID4gbGFiZWxlZCBORlMsIG90aGVycyBtb3VudGluZyB3aXRoIHRo
ZSBjb250ZXh0PSBtb3VudCBvcHRpb24sIGFuZCANCj4gPiBvdGhlcnMgd2l0aCBTRUxpbnV4IGNv
bXBsZXRlbHkgZGlzYWJsZWQuICBXaXRoIGxhYmVsZWQgTkZTLCB0aGUgDQo+ID4gY3JlYXRpb24g
YW5kIGVuZm9yY2VtZW50IG9mIGxhYmVscyBoYXBwZW5zIG9uIHRoZSBjbGllbnQgc2lkZSBhbmQg
DQo+ID4gdGhlIHNlcnZlciBqdXN0IHN0b3JlcyB0aGUgbGFiZWxzLg0KPiANCj4gU28gYWxzbyBm
b3IgZXhhbXBsZSBpZiB0aGUgY2xpZW50cyBkaXNhZ3JlZSBhYm91dCBob3cgdG8gbGFiZWwgZmls
ZXMgaW4geW91ciBob21lIGRpcmVjdG9yeSwgb3Igc29tZXRoaW5nLCB0aGVuIHRoaW5ncyB3aWxs
IGxpa2VseSBicmVhay4gIEkgZG9uJ3Qga25vdyBob3cgYmlnIGEgcHJvYmxlbSB0aGF0IGlzIGlu
IHByYWN0aWNlLg0KPiANCj4gLS1iLg0KPiANCj4gPiANCj4gPiBBbnl3YXlzLCBJIG1pc3NlZCB0
aGUgZmFjdCB0aGF0IHlvdXIgY2xpZW50cyBhcmUgdXNpbmcgYW4gZWFybGllciANCj4gPiBrZXJu
ZWwuICBJbiBvcmRlciB0byBnZXQgdGhlIGRlc2lyZWQgYmVoYXZpb3Igd2hlbiBtb3VudGluZyBh
biBORlMgDQo+ID4gc2VydmVyIHRoYXQgaXMgdXNpbmcgdGhlICJzZWN1cml0eV9sYWJlbCIgZXhw
b3J0IG9wdGlvbiwgeW91J3JlIA0KPiA+IHByZXR0eSBtdWNoIGdvaW5nIHRvIG5lZWQgdG8gcnVu
IGFuIHVwZGF0ZWQga2VybmVsIG9uIHRoZSBjbGllbnRzIHRvby4uLg0KPiA+IHNwZWNpZmljYWxs
eSBvbmUgd2l0aCBjb21taXQgMGI0ZDM0NTJiICJzZWN1cml0eS9zZWxpbnV4OiBhbGxvdyANCj4g
PiBzZWN1cml0eV9zYl9jbG9uZV9tbnRfb3B0cyB0byBlbmFibGUvZGlzYWJsZSBuYXRpdmUgbGFi
ZWxpbmcgYmVoYXZpb3IiLg0KPiA+IEFGQUlLIENlbnRPUyA3LjQgc2hvdWxkIGhhdmUgaXQgKGJl
Y2F1c2UgUkhFTCA3LjQgaGFzIGl0KS4NCj4gPiANCj4gPiAtU2NvdHQNCj4gPiANCj4gPiANCj4g
PiA+IA0KPiA+ID4gVGhhbmtzIGZvciB0aGUgaGVscCwNCj4gPiA+IEFsZXgNCj4gPiA+IC0tDQo+
IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJlcGx5LiBZZXMsIEkgaW1hZ2luZSB0aGVy
ZSdkIGJlIHByb2JsZW1zIGlmIGNsaWVudHMgYXJlIGNvbmZ1c2VkIGFib3V0IHdoYXQgbGFiZWxz
IGFyZSBhcHBsaWVkLCBidXQgSSBqdXN0IHdhbnRlZCB0byBjaGVjayBpZiBhbnlvbmUga25ldyBv
ZiB0aGF0IGFjdHVhbGx5IHByZXZlbnRpbmcgb3RoZXIgY2xpZW50cyBmcm9tIHJlYWRpbmcgb3Ig
c2V0dGluZyBsYWJlbHMgYXQgYWxsICh0aHJvd2luZyAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQi
IGVycm9ycykuIEl0IHNvdW5kcyBmcm9tIHdoYXQgeW91IGFyZSBzYXlpbmcgbGlrZSB0aGF0IGlz
IF9ub3RfIHRoZSBjYXNlLg0KDQpUaGF0J3MgY29ycmVjdC4NCg0KPiANCj4gU2NvdHQsIEkganVz
dCB3YW50IHRvIGNsYXJpZnkgeW91ciBjb21tZW50IGFib3V0IGNsaWVudHMgdXNpbmcgYW4gDQo+
IGVhcmxpZXIga2VybmVsLiAgU2luY2UgbXkgb3JpZ2luYWwgbWVzc2FnZSB3ZSBub3cgaGF2ZSB0
aGUgZm9sbG93aW5nIA0KPiBrZXJuZWxzDQo+IA0KPiBTZXJ2ZXI6IAkJCTMuMTAuMC02OTMuNS4y
LmVsNy54ODZfNjQNCj4gQ2xpZW50ICh3b3JraW5nKTogCTMuMTAuMC0zMjcuMzYuMi5lbDcueDg2
XzY0DQo+IENsaWVudCAobm9uLXdvcmtpbmcpOiAJMy4xMC4wLTY5My4yLjIuZWw3Lng4Nl82NA0K
PiANCj4gU28gaXQncyB0aGUgX3dvcmtpbmdfIGNsaWVudCB3aGljaCBoYXMgdGhlIGRvd24tbGV2
ZWwga2VybmVsLg0KDQpUaGF0J3MgdGhlIG9wcG9zaXRlIGZyb20gd2hhdCBJJ20gc2VlaW5nIGlm
IEkgaW5zdGFsbCB0aGUgUkhFTCBrZXJuZWxzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIENlbnRPUyB2
ZXJzaW9ucyB5b3UgaGF2ZSBsaXN0ZWQuDQoNCj4gQXJlIHlvdSBzYXlpbmcgaXQgbmVlZHMgdG8g
YmUgdXAtbGV2ZWwgYWxzbyBmb3IgdGhpcyB0byB3b3JrPyBPciBkbyB5b3UgbWVhbiB0aGF0IGFs
bCBvZiB0aGUgdmVyc2lvbnMgYXJlIHRvbyBvbGQgc29tZWhvdz8gDQo+IFRoaXMgd2FzIHdvcmtp
bmcgd2hlbiBhbGwgc2VydmVycyB3ZXJlIGRvd24tbGV2ZWwgKENlbnRPUyA3LjMga2VybmVsIHNv
IDMuMTAtMzI3KSBfd2l0aG91dF8gdGhlICJzZWN1cml0eV9sYWJlbCIgZXhwb3J0cyBvcHRpb24g
LSBkaWQgdGhlIG5ldyBrZXJuZWwgdGlnaHRlbiB0aGUgc2VjdXJpdHkgc3VjaCB0aGF0IHRoaXMg
aXMgbm93IHJlcXVpcmVkPw0KDQpZZXMsIEkgd2FzIHNheWluZyB0aGF0IGluIG9yZGVyIHRvIHVz
ZSB0aGUgInNlY3VyaXR5X2xhYmVsIiBvcHRpb24sIHlvdXIgTkZTIHNlcnZlciBhbmQgTkZTIGNs
aWVudHMgbmVlZCB0byBiZSBydW5uaW5nIDcuNCBrZXJuZWxzLiAgQnV0IGl0IHNvdW5kcyBsaWtl
IHRoZXJlJ3Mgc29tZXRoaW5nIGVsc2UgZ29pbmcgb24gaGVyZSB0aGF0IEknbSBub3QgdW5kZXJz
dGFuZGluZy4gIEhlcmUncyB3aGF0IEkgc2VlIHdoZW4gSSBpbnN0YWxsIHRoZSBzYW1lIGtlcm5l
bCB2ZXJzaW9ucyB0aGF0IHlvdSBoYXZlLg0KDQpPbiBteSBORlMgc2VydmVyIEkgaGF2ZSBhIHNp
bmdsZSBleHBvcnQgd2l0aCB0aGUgInNlY3VyaXR5X2xhYmVsIg0Kb3B0aW9uOg0KDQpbcm9vdEBu
ZnNzZXJ2ZXIgfl0jIHVuYW1lIC1yDQozLjEwLjAtNjkzLjUuMi5lbDcueDg2XzY0DQpbcm9vdEBu
ZnNzZXJ2ZXIgfl0jIGNhdCAvZXRjL2V4cG9ydHMNCi9leHBvcnQgKihydyxpbnNlY3VyZSxub19y
b290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCltyb290QG5mc3NlcnZlciB+XSMgZXhwb3J0ZnMg
LXYNCi9leHBvcnQgICAgICAgICA8d29ybGQ+KHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9fc3VidHJl
ZV9jaGVjayxzZWN1cml0eV9sYWJlbCxzZWM9c3lzLGluc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5v
X2FsbF9zcXVhc2gpDQoNCklmIEkgbW91bnQgdXNpbmcgdGhlIG9sZGVyIGtlcm5lbCwgSSBjYW4g
c2VlIHRoZSBsYWJlbCBidXQgSSBjYW4ndCBjaGFuZ2UgaXQ6DQoNCltyb290QHJoZWw3MiB+XSMg
dW5hbWUgLXINCjMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0DQpbcm9vdEByaGVsNzIgfl0jIG1v
dW50IC1vIHY0LjIgbmZzc2VydmVyOi9leHBvcnQgL21udC90DQpbcm9vdEByaGVsNzIgfl0jIGxz
IC1aIC9tbnQvdC9maWxlDQotcnctci0tci0tLiByb290IHJvb3Qgc3lzdGVtX3U6b2JqZWN0X3I6
ZXRjX3Q6czAgICAgICAgL21udC90L2ZpbGUNCltyb290QHJoZWw3MiB+XSMgY2hjb24gLXQgdXNy
X3QgL21udC90L2ZpbGUNCmNoY29uOiBmYWlsZWQgdG8gY2hhbmdlIGNvbnRleHQgb2Yg4oCYL21u
dC90L2ZpbGXigJkgdG8g4oCYc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6czDigJk6IE9wZXJhdGlv
biBub3Qgc3VwcG9ydGVkDQoNCklmIEkgbW91bnQgdXNpbmcgdGhlIG5ld2VyIGtlcm5lbCwgSSBj
YW4gc2VlIGFuZCBjaGFuZ2UgdGhlIGxhYmVsOg0KDQpbcm9vdEByaGVsNzQgfl0jIHVuYW1lIC1y
DQozLjEwLjAtNjkzLjIuMi5lbDcueDg2XzY0DQpbcm9vdEByaGVsNzQgfl0jIHY0LjIgDQpbcm9v
dEByaGVsNzQgfl0jIGxzIC1aIC9tbnQvdA0KLXJ3LXItLXItLS4gcm9vdCByb290IHN5c3RlbV91
Om9iamVjdF9yOmV0Y190OnMwICAgICAgIGZpbGUNCltyb290QHJoZWw3NCB+XSMgY2hjb24gLXQg
dXNyX3QgL21udC90L2ZpbGUNCltyb290QHJoZWw3NCB+XSMgbHMgLVogL21udC90DQotcnctci0t
ci0tLiByb290IHJvb3Qgc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6czAgICAgICAgZmlsZQ0KDQpU
byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgb24gdGhlIE5GUyBzZXJ2ZXIgc2lkZSB0aGUgb2xkZXIg
a2VybmVsIHdvdWxkIGFsd2F5cyBzZW5kIHRoZSBpbmRpdmlkdWFsIHNlY3VyaXR5IGxhYmVscyBh
bmQgYSBjaGFuZ2Ugd2FzIG1hZGUgdG8gbWFrZSB0aGF0IGJlaGF2aW9yIGJlIG9wdC1pbiBiZWNh
dXNlIGl0IHdhcyBjYXVzaW5nIHByb2JsZW1zIGZvciBzb21lIHVzZXJzIChCcnVjZSBjYW4gY29y
cmVjdCBtZSBvbiB0aGF0IGlmIEknbSB3cm9uZykuDQoNCk9uIHRoZSBjbGllbnQgc2lkZSB0aGVy
ZSB3YXMgYSBwcm9ibGVtIHdpdGggc2V0dGluZyB0aGUgYXBwcm9wcmlhdGUgZmxhZyBvbiB0aGUg
c3VwZXJibG9jayB0aGF0IGhhZCB0byBkbyB3aXRoIHRoZSB3YXkgTkZTdjQgbW91bnRzIGFyZSBk
b25lLiBUaGUgY2xpZW50IG1vdW50cyB0aGUgTkZTdjQgcm9vdCBhbmQgdGhlbiBkb2VzIGEgcGF0
aCB3YWxrIHRvIHRoZSByZWFsIGV4cG9ydC4gIFdoZW4gaXQgZ2V0cyB0byB0aGUgcmVhbCBleHBv
cnQgaXQgY2xvbmVzIHRoZSBzdXBlcmJsb2NrIGZyb20gdGhlIE5GU3Y0IHJvb3QuICBUaGUgZmxh
ZyB3YXMgbm90IGdldHRpbmcgc2V0IG9uIHRoZSBjbG9uZS4gIFRoYXQncyB3aGF0IHRoZSBjb21t
aXQgdGhhdCBJIHBvaW50ZWQgb3V0IGVhcmxpZXIgd2FzIGZpeGluZy4NCj4gDQo+IFNlcGFyYXRl
bHksIGRvIGVpdGhlciBvZiB5b3Uga25vdyBvZiBhIHNlbnNpYmxlIHdheSBJIGNhbiBkZWJ1ZyB0
aGUgcm9vdCBjYXVzZSBmb3IgdGhlIGlzc3VlIGZ1cnRoZXIgKHRvIGdldCBhIG1vcmUgZGV0YWls
IHdoeSAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQiIGlzIHRocm93bik/IEkgZG9uJ3Qga25vdyB0
aGUga2VybmVsIHNvdXJjZSBhdCBhbGwgc28ganVzdCByZWFkaW5nIHRoZSBjb2RlIGlzIG5vdCB2
aWFibGUgZm9yIG1lICh3aXRob3V0IHNvbWUgZ3VpZGFuY2UpLCBidXQgaXMgdGhlcmUgc29tZSBs
b2dnaW5nIG9yIG1vcmUgdmVyYm9zZSBvdXRwdXQgSSBjYW4gdHVybiBvbj8NCg0KVGhlcmUgaXNu
J3QgcmVhbGx5IGFueSB2ZXJib3NlIGxvZ2dpbmcgdGhhdCBJIGNhbiB0aGluayBvZi4gIFdoZW4g
eW91IGdldCAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQiIGZyb20gY2hjb24sIGl0IHByZXR0eSBt
dWNoIG1lYW5zIHRoYXQgdGhlIG1vdW50IGRvZXNuJ3QgaGF2ZSB0aGUgU0JMQUJFTF9NTlQgZmxh
ZyBzZXQgKFJIRUwgdXNlcyBhbiBvbGRlciBmbGFnIFNFX1NCTEFCRUxTVVBQIGJ1dCBpdCdzIHJl
YWxseSB0aGUgc2FtZSB0aGluZykuICBZb3UgY2FuIHNlZSB3aGV0aGVyIHRoZSBmbGFnIGlzIHNl
dCBieSBsb29raW5nIGZvciB0aGUgdGV4dCAic2VjbGFiZWwiIGluIHRoZSBtb3VudCBvcHRpb25z
IGZvciB5b3VyIG1vdW50IGluIC9wcm9jL21vdW50cy4gIE9uIHRoZSBvbGRlciBrZXJuZWwgSSBz
ZWUgdGhpczoNCg0KW3Jvb3RAcmhlbDcyIH5dIyBncmVwIG5mczQgL3Byb2MvbW91bnRzDQpuZnNz
ZXJ2ZXI6L2V4cG9ydCAvbW50L3QgbmZzNCBydyxyZWxhdGltZSx2ZXJzPTQuMixyc2l6ZT01MjQy
ODgsd3NpemU9NTI0Mjg4LC4uLg0KDQphbmQgb24gdGhlIG5ld2VyIGtlcm5lbCBJIHNlZSB0aGlz
Og0KDQpbcm9vdEByaGVsNzQgfl0jIGdyZXAgbmZzNCAvcHJvYy9tb3VudHMNCm5mc3NlcnZlcjov
ZXhwb3J0IC9tbnQvdCBuZnM0IHJ3LHNlY2xhYmVsLHJlbGF0aW1lLHZlcnM9NC4yLHJzaXplPTUy
NDI4OCx3c2l6ZT01MjQyODgsLi4uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBe
Xl5eXl5eXg0KDQpUaGUgb3RoZXIgdGhpbmcgeW91IGNhbiBsb29rIGF0IGlzIHRoZSBjYXBzIGZp
ZWxkIGluIC9wcm9jL3NlbGYvbW91bnRzdGF0cy4gIElmIHRoZSBzZXJ2ZXIgaGFzIHNlY3VyaXR5
IGxhYmVscyBlbmFibGVkIHRoZW4gdGhlIGNhcHMgZmllbGQgd2lsbCBoYXZlIE5GU19DQVBfU0VD
VVJJVFlfTEFCRUwgc2V0LCB3aGljaCBpcyBkZWZpbmVkIGFzDQoNCiNkZWZpbmUgTkZTX0NBUF9T
RUNVUklUWV9MQUJFTCAoMVUgPDwgMTgpDQoNCllvdSBjYW4gdGFrZSB0aGUgdmFsdWUgZnJvbSB0
aGUgY2FwcyBmaWVsZCBhbmQgcGx1ZyBpdCBpbnRvIGEgYmFzaCBwcmludGYNCg0KW3Jvb3RAcmhl
bDc0IH5dIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9tb3VudHN0YXRzDQogICAgICAgIGNhcHM6ICAg
Y2Fwcz0weDFmZmZmZGYsd3RtdWx0PTUxMixkdHNpemU9MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1
DQpbcm9vdEByaGVsNzQgfl0jIHByaW50ZiAiJXhcbiIgJCgoIDB4MWZmZmZkZiAmICgxPDwxOCkg
KSkNCjQwMDAwDQoNCklmIHlvdSBzZWUgMCBpbnN0ZWFkIG9mIDQwMDAwIHRoZW4gTkZTX0NBUF9T
RUNVUklUWV9MQUJFTCBpc24ndCBzZXQuDQoNCk9uIHRoZSBvbGRlciBrZXJuZWwgSSBzdGlsbCBz
ZWUgTkZTX0NBUF9TRUNVUklUWV9MQUJFTCBzZXQ6DQoNCltyb290QHJoZWw3MiB+XSMgZ3JlcCBj
YXBzIC9wcm9jL3NlbGYvbW91bnRzdGF0cw0KICAgICAgICBjYXBzOiAgIGNhcHM9MHgzZmZmZmYs
d3RtdWx0PTUxMixkdHNpemU9MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1DQpbcm9vdEByaGVsNzIg
fl0jIHByaW50ZiAiJXhcbiIgJCgoIDB4M2ZmZmZmICYgKDE8PDE4KSApKQ0KNDAwMDANCg0KU28g
aW4gbXkgY2FzZSB0aGUgY2hjb24gaXMgZmFpbGluZyBvbiB0aGUgb2xkZXIga2VybmVsIGR1ZSB0
byB0aGUgYWJzZW5jZSBvZiB0aGUgU0JMQUJFTF9NTlQvU0VfU0JMQUJFTFNVUFAgZmxhZy4NCg0K
LVNjb3R0DQo+IA0KPiBBbGV4DQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KU2NvdHQsDQoNClRoYW5r
IHlvdS4gVXNpbmcgeW91ciBwb2ludGVycywgSSBkaWQgc29tZSBtb3JlIGRpZ2dpbmcgKGJlbG93
KS4gQmFzZWQgb24gdGhhdCBpdCBsb29rcyBsaWtlIE5GU19DQVBfU0VDVVJJVFlfTEFCRUwgaXNu
J3QgYmVpbmcgc2V0IG9uIHRoZSB1cC1sZXZlbCBrZXJuZWwsIGJ1dCAqaXMqIGJlaW5nIHNldCBv
biB0aGUgZG93bi1sZXZlbCBrZXJuZWwuIFRoZSBgc2VjbGFiZWxgIG9wdGlvbiBpcyBleGFjdGx5
IHJldmVyc2Ugb2Ygd2hhdCBpdCBzaG91bGQgYmUsIG5hbWVseSBpdCBhcHBlYXJzIG9uIHRoZSB1
cC1sZXZlbCAoZGVzcGl0ZSBubyBORlNfQ0FQKSENCg0KQXMgYSB0ZXN0LCBJIHRyaWVkIHRvIG1v
dW50IG9uZSBvZiB0aGUgZXhwb3J0cyBhIHNlY29uZCB0aW1lIG9uIHRoZSB1cC1sZXZlbCBrZXJu
ZWwuIEhlcmUgaXMgd2hhdCBJIGZvdW5kOg0KDQoqIG1vdW50aW5nIHZpYSBgbW91bnRgIHVzaW5n
IHRoZSBzYW1lICJkZWZhdWx0cyxzb2Z0LGxvb2t1cGNhY2hlPW5vbmUiIGFzIGluIC9ldGMvZnN0
YWIgcmVwcm9kdWNlcyB0aGUgaXNzdWUNCltyb290QGVuZmlnaXRmcm9udDItZGV2ZWwgbW50XSMg
bW91bnQgLW8gZGVmYXVsdHMsc29mdCx2NC4yLGxvb2t1cGNhY2hlPW5vbmUgZW5maWdpdGJhY2sy
LWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggL21udC90ZXN0LXNzaC8NCltyb290QGVu
ZmlnaXRmcm9udDItZGV2ZWwgbW50XSMgY2hjb24gLXQgdXNyX3QgL21udC90ZXN0LXNzaC9hdXRo
b3JpemVkX2tleXMNCmNoY29uOiBmYWlsZWQgdG8gY2hhbmdlIGNvbnRleHQgb2Yg4oCYL21udC90
ZXN0LXNzaC9hdXRob3JpemVkX2tleXPigJkgdG8g4oCYc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6
czDigJk6IE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkDQpbcm9vdEBlbmZpZ2l0ZnJvbnQyLWRldmVs
IG1udF0jIA0KDQoqIG1vdW50aW5nIHdpdGggZGVmYXVsdHMgZG9lcyBub3QNCltyb290QGVuZmln
aXRmcm9udDItZGV2ZWwgbW50XSMgbW91bnQgLW8gdjQuMiBlbmZpZ2l0YmFjazItZGV2ZWwuZGF0
Y29uLmNvLnVrOi9leHBvcnQvLnNzaCAvbW50L3Rlc3Qtc3NoLw0KW3Jvb3RAZW5maWdpdGZyb250
Mi1kZXZlbCBtbnRdIyBjaGNvbiAtdCB1c3JfdCAvbW50L3Rlc3Qtc3NoL2F1dGhvcml6ZWRfa2V5
cw0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCBtbnRdIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9t
b3VudHN0YXRzIA0KLi4uDQoJY2FwczoJY2Fwcz0weDFmZmZmZGYsd3RtdWx0PTUxMixkdHNpemU9
MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1DQoNCkJhc2VkIG9uIHRoYXQgSSdtIHdvbmRlcmluZyBp
ZiB0aGVyZSdzIHNvbWV0aGluZyBiYWQgaW50ZXJhY3Rpb24gd2l0aCB0aGUgbG9va3VwIGNhY2hl
IGFuZC9vciBzb2Z0L2hhcmQgb3B0aW9uIC0gYW55IHdheSBJIGNhbiBkZWJ1ZyB0aGF0IGZ1cnRo
ZXI/IEFsc28sIHdoYXQgZG8geW91IG1ha2Ugb2YgdGhlIHdlaXJkIE5GU19DQVAgc2V0IG9uIHRo
ZSB1cC9kb3dubGV2ZWwga2VybmVscywgaXQgc2VlbXMgZXhhY3RseSByZXZlcnNlISANCg0KVGhh
bmtzLCANCkFsZXggDQoNCg0KIyMjIE9uIHRoZSB1cC1sZXZlbCBrZXJuZWwNCg0KL3Byb2Mvc2Vs
Zi9tb3VudHN0YXRzIHN1Z2dlc3RzIE5GU19DQVBfU0VDVVJJVFlfTEFCRUwgaXNuJ3Qgc2V0IC0g
YnV0ICB3ZWlyZGx5IGBzZWNsYWJlbGAgaXMgcHJlc2VudCBpbiAvcHJvYy9tb3VudHMNCg0KW3Jv
b3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMgZ3JlcCBuZnMgL3Byb2MvbW91bnRzIA0KLi4uDQpl
bmZpZ2l0YmFjazItZGV2ZWwuZGF0Y29uLmNvLnVrOi9leHBvcnQvc2hhcmVkIC92YXIvb3B0L2dp
dGxhYi9naXRsYWItcmFpbHMvc2hhcmVkIG5mczQgcncsc2VjbGFiZWwsbm9hdGltZSx2ZXJzPTQu
Mixyc2l6ZT0yNjIxNDQsd3NpemU9MjYyMTQ0LG5hbWxlbj0yNTUsc29mdCxwcm90bz10Y3AscG9y
dD0wLHRpbWVvPTYwMCxyZXRyYW5zPTIsc2VjPXN5cyxjbGllbnRhZGRyPTE3Mi4xOC4xMC4xNTEs
bG9va3VwY2FjaGU9bm9uZSxsb2NhbF9sb2NrPW5vbmUsYWRkcj0xNzIuMTguMTAuMTkzIDAgMA0K
ZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggL3Zhci9vcHQvZ2l0
bGFiLy5zc2ggbmZzNCBydyxzZWNsYWJlbCxub2F0aW1lLHZlcnM9NC4yLHJzaXplPTI2MjE0NCx3
c2l6ZT0yNjIxNDQsbmFtbGVuPTI1NSxzb2Z0LHByb3RvPXRjcCxwb3J0PTAsdGltZW89NjAwLHJl
dHJhbnM9MixzZWM9c3lzLGNsaWVudGFkZHI9MTcyLjE4LjEwLjE1MSxsb29rdXBjYWNoZT1ub25l
LGxvY2FsX2xvY2s9bm9uZSxhZGRyPTE3Mi4xOC4xMC4xOTMgMCAwDQouLi4NCltyb290QGVuZmln
aXRmcm9udDItZGV2ZWwgfl0jIGdyZXAgY2FwcyAvcHJvYy9zZWxmL21vdW50c3RhdHMNCgljYXBz
OgljYXBzPTB4MWZiZmZkZix3dG11bHQ9NTEyLGR0c2l6ZT0zMjc2OCxic2l6ZT0wLG5hbWxlbj0y
NTUNCi4uLg0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMgcHJpbnRmICIleFxuIiAkKCgg
MHgxZmJmZmRmICYgKDE8PDE4KSApKQ0KMA0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMg
dW5hbWUgLXINCjMuMTAuMC02OTMuMi4yLmVsNy54ODZfNjQgDQoNCiMjIyBEb3duLWxldmVsDQpJ
cyB0aGUgcmV2ZXJzZSBvZiB0aGUgYWJvdmU6IC9wcm9jL3NlbGYvbW91bnRzdGF0cyBzaG93cyBO
RlNfQ0FQX1NFQ1VSSVRZX0xBQkVMICppcyogc2V0IGJ1dCBgc2VjbGFiZWxgIGlzbid0IHByZXNl
bnQgKHdoaWNoIG1ha2VzIHNlbnNlIGJhc2VkIG9uIHdoYXQgeW91IGFyZSBzYXlpbmcpLg0KDQpl
bmZpZ2l0YmFjazItZGV2ZWwuZGF0Y29uLmNvLnVrOi9leHBvcnQvLnNzaCAvdmFyL29wdC9naXRs
YWIvLnNzaCBuZnM0IHJ3LG5vYXRpbWUsdmVycz00LjIscnNpemU9MjYyMTQ0LHdzaXplPTI2MjE0
NCxuYW1sZW49MjU1LHNvZnQscHJvdG89dGNwLHBvcnQ9MCx0aW1lbz02MDAscmV0cmFucz0yLHNl
Yz1zeXMsY2xpZW50YWRkcj0xNzIuMTguMTAuMTQ4LGxvb2t1cGNhY2hlPW5vbmUsbG9jYWxfbG9j
az1ub25lLGFkZHI9MTcyLjE4LjEwLjE5MyAwIDANCltyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwg
fl0jIGdyZXAgbmZzIC9wcm9jL21vdW50cyANCi4uLi4NCmVuZmlnaXRiYWNrMi1kZXZlbC5kYXRj
b24uY28udWs6L2V4cG9ydC9wYWdlcy1kYXRhIC92YXIvb3B0L2dpdGxhYi9wYWdlcy1kYXRhIG5m
czQgcncsbm9hdGltZSx2ZXJzPTQuMixyc2l6ZT0yNjIxNDQsd3NpemU9MjYyMTQ0LG5hbWxlbj0y
NTUsc29mdCxwcm90bz10Y3AscG9ydD0wLHRpbWVvPTYwMCxyZXRyYW5zPTIsc2VjPXN5cyxjbGll
bnRhZGRyPTE3Mi4xOC4xMC4xNDgsbG9va3VwY2FjaGU9bm9uZSxsb2NhbF9sb2NrPW5vbmUsYWRk
cj0xNzIuMTguMTAuMTkzIDAgMA0KZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhw
b3J0Ly5zc2ggL3Zhci9vcHQvZ2l0bGFiLy5zc2ggbmZzNCBydyxub2F0aW1lLHZlcnM9NC4yLHJz
aXplPTI2MjE0NCx3c2l6ZT0yNjIxNDQsbmFtbGVuPTI1NSxzb2Z0LHByb3RvPXRjcCxwb3J0PTAs
dGltZW89NjAwLHJldHJhbnM9MixzZWM9c3lzLGNsaWVudGFkZHI9MTcyLjE4LjEwLjE0OCxsb29r
dXBjYWNoZT1ub25lLGxvY2FsX2xvY2s9bm9uZSxhZGRyPTE3Mi4xOC4xMC4xOTMgMCAwDQouLi4u
DQpbcm9vdEBlbmZpZ2l0ZnJvbnQxLWRldmVsIH5dIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9tb3Vu
dHN0YXRzDQoJY2FwczoJY2Fwcz0weDNmZmZmZix3dG11bHQ9NTEyLGR0c2l6ZT0zMjc2OCxic2l6
ZT0wLG5hbWxlbj0yNTUNCi4uLi4NCltyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwgfl0jIHByaW50
ZiAiJXhcbiIgJCgoIDB4M2ZmZmZmZiAmICgxPDwxOCkgKSkNCjQwMDAwDQpbcm9vdEBlbmZpZ2l0
ZnJvbnQxLWRldmVsIH5dIyB1bmFtZSAtcg0KMy4xMC4wLTMyNy4zNi4yLmVsNy54ODZfNjQNCg0K
DQoNCiMjIyBTZXJ2ZXIsIGp1c3QgZm9yIGdvb2QgbWVhc3VyZQ0KDQpbcm9vdEBlbmZpZ2l0YmFj
azItZGV2ZWwgfl0jIHVuYW1lIC1yDQozLjEwLjAtNjkzLjUuMi5lbDcueDg2XzY0DQpbcm9vdEBl
bmZpZ2l0YmFjazItZGV2ZWwgfl0jIGNhdCAvZXRjL2V4cG9ydHMNCi4uLg0KL2V4cG9ydC8uc3No
IDE3Mi4xOC4xMC4xNDgocncsc3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkgMTcy
LjE4LjEwLjE1MShydyxzeW5jLG5vX3Jvb3Rfc3F1YXNoLHNlY3VyaXR5X2xhYmVsKQ0KL2V4cG9y
dC9zaGFyZWQgMTcyLjE4LjEwLjE0OChydyxzeW5jLG5vX3Jvb3Rfc3F1YXNoLHNlY3VyaXR5X2xh
YmVsKSAxNzIuMTguMTAuMTUxKHJ3LHN5bmMsbm9fcm9vdF9zcXVhc2gsc2VjdXJpdHlfbGFiZWwp
DQouLi4NCltyb290QGVuZmlnaXRiYWNrMi1kZXZlbCB+XSMgZXhwb3J0ZnMgLXYNCi9leHBvcnQv
LnNzaCAgCTE3Mi4xOC4xMC4xNDgocncsc3luYyx3ZGVsYXksaGlkZSxub19zdWJ0cmVlX2NoZWNr
LHNlY3VyaXR5X2xhYmVsLHNlYz1zeXMsc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5vX2FsbF9zcXVh
c2gpDQovZXhwb3J0Ly5zc2ggIAkxNzIuMTguMTAuMTUxKHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9f
c3VidHJlZV9jaGVjayxzZWN1cml0eV9sYWJlbCxzZWM9c3lzLHNlY3VyZSxub19yb290X3NxdWFz
aCxub19hbGxfc3F1YXNoKQ0KLi4uLg0KDQo=