This bug was fixed in the package systemd - 249.11-0ubuntu3.9

---------------
systemd (249.11-0ubuntu3.9) jammy; urgency=medium

  * udev: gracefully handle rename failures (LP: #2002445)
    Files:
    - debian/patches/lp2002445/core-device-ignore-failed-uevents.patch
    - debian/patches/lp2002445/sd-device-introduce-device_get_property_int.patch
    - 
debian/patches/lp2002445/sd-device-make-device_set_syspath-clear-sysname-and-sysnu.patch
    - 
debian/patches/lp2002445/udev-restore-syspath-and-properties-on-failure.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a7ad4a9fc708500c61e3b8127f112d8c90049b2c

systemd (249.11-0ubuntu3.8) jammy; urgency=medium

  * network/dhcp4: accept local subnet routes from DHCP (LP: #2004478)
    File: 
debian/patches/lp2004478-network-dhcp4-accept-local-subnet-routes-from-DHCP.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=96928d5f45ebbfe682b47e842d63506fa0ac9583
  * udev: avoid NIC renaming race with kernel (LP: #2002445)
    Files:
    - 
debian/patches/lp2002445/sd-netlink-add-a-test-for-rtnl_set_link_name.patch
    - 
debian/patches/lp2002445/sd-netlink-do-not-swap-old-name-and-alternative-name.patch
    - 
debian/patches/lp2002445/sd-netlink-restore-altname-on-error-in-rtnl_set_link_name.patch
    - 
debian/patches/lp2002445/udev-attempt-device-rename-even-if-interface-is-up.patch
    - 
debian/patches/lp2002445/udev-net-allow-new-link-name-as-an-altname-before-renamin.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=20dc4d51a340669c26c446c23b5a84516e82ea74
  * network: create stacked netdevs after the underlying link is (LP: #2000880)
    File: 
debian/patches/lp2000880-network-create-stacked-netdevs-after-the-underlying-link-.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ab620e709f3f62eda86af26fd66c00d6e5165a25
  * Enable /dev/sgx_vepc access for the group 'sgx' (LP: #2009502)
    File: 
debian/patches/lp2009502-Enable-dev-sgx_vepc-access-for-the-group-sgx.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=434480ae4059a16ccbde9613be0c26ff1983cc3a

 -- Nick Rosbrook <nick.rosbr...@canonical.com>  Mon, 20 Mar 2023
10:32:08 -0400

** Changed in: systemd (Ubuntu Jammy)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2009502

Title:
   Enable /dev/sgx_vepc access for the group 'sgx'

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [ Impact ]

  On systems where Intel SGX is available, access to a specific device
  node (/dev/sgx_vepc) must be enforced, with a specific permission
  (0660) and group (sgx).

  This allows KVM-based virtual machines to use such feature (the SGX
  "enclaves") in a proper fashion.  Without this, a manual udev rule
  needs to be created.

  [ Test Plan ]

  As the patch itself only tailors the permissions/group to the device
  node, in a system with Intel-SGX enabled, merely `ls -la` against the
  device node should show if the permissions and group are seen as
  expected.

  [ Where problems could occur ]

  N/A.  This seems to be a very straightforward inclusion, very specific
  to access enablement to the SGX reserved memory used for hosting
  enclaves.

  [ Other Info ]

  N/A.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2009502/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to