* Re: problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
From: Harald Dunkel @ 2022-07-31 17:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <94dbdb74-1de7-22e6-62d2-1fe460eb89d9@afaics.de>
Hi folks,
sorry for the double post. Please ignore.
Regards
Harri
On 2022-07-31 19:11:52, Harald Dunkel wrote:
> Hi folks,
>
> setup:
> kernel 5.18.14 (built from git)
> Qnap TS-559 Pro II, 4*3.5 HDD + 1 SSD, /boot is on USB stick
> Intel(R) Atom(TM) CPU D525
> Debian Sid
>
> On a reboot after some runtime my Qnap TS-559 Pro II shuts down cleanly, but
> after the kernel and initrd are loaded again it writes an endless stream of
> messages to the console
>
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
>
> Appr. 2 lines per second. I get an emergency console to login, but it
> is garbled.
>
> If I wait a few minutes to let the qnap cool down it boots again.
>
> # lspci
> 00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
> 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
> 00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)
> 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
> 00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
> 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 03:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
> 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
> 06:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
>
> # lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Address sizes: 36 bits physical, 48 bits virtual
> Byte Order: Little Endian
> CPU(s): 4
> On-line CPU(s) list: 0-3
> Vendor ID: GenuineIntel
> BIOS Vendor ID: Intel
> Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz
> BIOS Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz To Be Filled By O.E.M. CPU @ 1.8GHz
> BIOS CPU family: 43
> CPU family: 6
> Model: 28
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 1
> Stepping: 10
> BogoMIPS: 3591.07
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm const
> ant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
> Caches (sum of all):
> L1d: 48 KiB (2 instances)
> L1i: 64 KiB (2 instances)
> L2: 1 MiB (2 instances)
> NUMA:
> NUMA node(s): 1
> NUMA node0 CPU(s): 0-3
> Vulnerabilities:
> Itlb multihit: Not affected
> L1tf: Not affected
> Mds: Not affected
> Meltdown: Not affected
> Mmio stale data: Not affected
> Retbleed: Not affected
> Spec store bypass: Not affected
> Spectre v1: Not affected
> Spectre v2: Not affected
> Srbds: Not affected
> Tsx async abort: Not affected
>
>
> Every helpful hint is highly appreciated.
>
> Harri
--
Dipl.-Ing. Harald Dunkel |
Muehlenbachstr. 3 | keep it simple
52134 Herzogenrath, Germany |
+49 2407 565 105 |
^ permalink raw reply
* problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
From: Harald Dunkel @ 2022-07-31 17:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <94dbdb74-1de7-22e6-62d2-1fe460eb89d9@afaics.de>
Hi folks,
setup:
kernel 5.18.14 (built from git)
Qnap TS-559 Pro II, 4*3.5 HDD + 1 SSD, /boot is on USB stick
Intel(R) Atom(TM) CPU D525
Debian Sid
On a reboot after some runtime my Qnap TS-559 Pro II shuts down cleanly, but
after the kernel and initrd are loaded again it writes an endless stream of
messages to the console
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
Appr. 2 lines per second. I get an emergency console to login, but it
is garbled.
If I wait a few minutes to let the qnap cool down it boots again.
# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
03:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
06:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel
Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz
BIOS Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz To Be Filled By O.E.M. CPU @ 1.8GHz
BIOS CPU family: 43
CPU family: 6
Model: 28
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
Stepping: 10
BogoMIPS: 3591.07
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm const
ant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
Caches (sum of all):
L1d: 48 KiB (2 instances)
L1i: 64 KiB (2 instances)
L2: 1 MiB (2 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Not affected
Spectre v1: Not affected
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected
Every helpful hint is highly appreciated.
Harri
^ permalink raw reply
* Re: problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
From: Greg KH @ 2022-07-27 7:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <94dbdb74-1de7-22e6-62d2-1fe460eb89d9@afaics.de>
On Mon, Jul 25, 2022 at 05:43:10PM +0200, Harald Dunkel wrote:
> Hi folks,
>
> setup:
> kernel 5.18.14 (built from git)
> Qnap TS-559 Pro II, 4*3.5 HDD + 1 SSD, /boot is on USB stick
> Intel(R) Atom(TM) CPU D525
> Debian Sid
>
> On a reboot after some runtime my Qnap TS-559 Pro II shuts down cleanly, but
> after the kernel and initrd are loaded again it writes an endless stream of
> messages to the console
>
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
>
> Appr. 2 lines per second. I get an emergency console to login, but it
> is garbled.
>
> If I wait a few minutes to let the qnap cool down it boots again.
Try posting on the linux-pci@vger.kernel.org list, that is the best for
this type of thing.
thanks,
greg k-h
^ permalink raw reply
* problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
From: Harald Dunkel @ 2022-07-25 15:43 UTC (permalink / raw)
To: linux-hotplug
Hi folks,
setup:
kernel 5.18.14 (built from git)
Qnap TS-559 Pro II, 4*3.5 HDD + 1 SSD, /boot is on USB stick
Intel(R) Atom(TM) CPU D525
Debian Sid
On a reboot after some runtime my Qnap TS-559 Pro II shuts down cleanly, but
after the kernel and initrd are loaded again it writes an endless stream of
messages to the console
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
pcieport 0000:00:1c:0: pciehp: Slot(0): No link
Appr. 2 lines per second. I get an emergency console to login, but it
is garbled.
If I wait a few minutes to let the qnap cool down it boots again.
# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
03:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
06:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel
Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz
BIOS Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz To Be Filled By O.E.M. CPU @ 1.8GHz
BIOS CPU family: 43
CPU family: 6
Model: 28
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
Stepping: 10
BogoMIPS: 3591.07
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm const
ant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
Caches (sum of all):
L1d: 48 KiB (2 instances)
L1i: 64 KiB (2 instances)
L2: 1 MiB (2 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Not affected
Spectre v1: Not affected
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected
Every helpful hint is highly appreciated.
Harri
^ permalink raw reply
* Re: Trying to understand udev duplicate ID_PATH issue
From: Andrei Borzenkov @ 2021-03-06 7:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJtFHUTJeJGjLBGcxAspgzYOpRUXGAfM0moyA8GMLT3580rKCQ@mail.gmail.com>
On 06.03.2021 01:53, Eli V wrote:
> Using udev 241, I'm seeing duplicate ID_PATHs for tape devices:
>
> $ udevadm info --name=/dev/st0 --query=all | grep PATH> E: DEVPATH=/devices/pci0000:b2/0000:b2:00.0/0000:b3:00.0/host11/port-11:0/end_device-11:0/target11:0:0/11:0:0:0/scsi_tape/st0
> E: ID_PATH=pci-0000:b3:00.0-sas-phy0-lun-0
>
> $ udevadm info --name=/dev/st1 --query=all | grep PATH> E: DEVPATH=/devices/pci0000:b2/0000:b2:00.0/0000:b3:00.0/host11/port-11:1/end_device-11:1/target11:0:1/11:0:1:0/scsi_tape/st1
> E: ID_PATH=pci-0000:b3:00.0-sas-phy0-lun-0
>
> Not sure how these ID_PATHs get generate but it would be nice to sort
> things out so /dev/tape/by-path has links for both devices. This is
> running on a Debian 10 system, but using the Ubuntu 5.4.78 kernel. Not
> much of a udev expert so I don't know if this is fixable via some udev
> rules, or something else is needed.
>
SAS phy numbers are expected to be unique in a SAS device (in this case
SAS HBA). If kernel returns two identical phy numbers for the same
device, you need to discuss it with kernel guys. If information returned
by kernel is correct and you still can reproduce it with current
udev/systemd - report an issue on systemd github page where udev is
developed.
^ permalink raw reply
* Trying to understand udev duplicate ID_PATH issue
From: Eli V @ 2021-03-05 22:53 UTC (permalink / raw)
To: linux-hotplug
Using udev 241, I'm seeing duplicate ID_PATHs for tape devices:
$ udevadm info --name=/dev/st0 --query=all | grep PATHE: DEVPATH=/devices/pci0000:b2/0000:b2:00.0/0000:b3:00.0/host11/port-11:0/end_device-11:0/target11:0:0/11:0:0:0/scsi_tape/st0
E: ID_PATH=pci-0000:b3:00.0-sas-phy0-lun-0
$ udevadm info --name=/dev/st1 --query=all | grep PATHE: DEVPATH=/devices/pci0000:b2/0000:b2:00.0/0000:b3:00.0/host11/port-11:1/end_device-11:1/target11:0:1/11:0:1:0/scsi_tape/st1
E: ID_PATH=pci-0000:b3:00.0-sas-phy0-lun-0
Not sure how these ID_PATHs get generate but it would be nice to sort
things out so /dev/tape/by-path has links for both devices. This is
running on a Debian 10 system, but using the Ubuntu 5.4.78 kernel. Not
much of a udev expert so I don't know if this is fixable via some udev
rules, or something else is needed.
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Jarkko Sakkinen @ 2020-12-22 22:14 UTC (permalink / raw)
To: Topi Miettinen
Cc: Ulrich Windl, luto, Ben Hutchings, jethro, bruce.schlobohm,
kai.svahn, luto, haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <815056f6-cb4b-0d48-ea2c-1cde97af45d4@gmail.com>
On Wed, Dec 16, 2020 at 03:05:05PM +0200, Topi Miettinen wrote:
> On 16.12.2020 12.03, Ulrich Windl wrote:
> > > > > Jarkko Sakkinen <jarkko@kernel.org> schrieb am 15.12.2020 um 05:19 in
> > Nachricht
> > <20201215041903.GA21875@kernel.org>:
> > > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
> > > > > > > Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
> > > > Nachricht
> > > > <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
> > > > > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
> > > > > > On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > > > > > > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > > > > > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > > > > > > > $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
> > > > > > > > > > > > No results. So making /dev noexec doesn't seem to have any
> > benefit.
> > > > > > > > > > >
> > > > > > > > > > > It's no surprise that there aren't any executables in /dev since
> > > > > > > > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > > > > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > > > > > > > needed) and thus a potential location for constructing unapproved
> > > > > > > > > > > executables if it is also mounted exec (W^X).
> > > > > > > > > >
> > > > > > > > > > UID 0 can just change mount options, though, unless SELinux or
> > similar
> > > > is
> > > > > used. And SELinux can protect /dev just fine without noexec.
> > > > > > > > >
> > > > > > > > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
> > > > SELinux
> > > > > > > > > is not universal and the policies might not contain all users or
> > > > services.
> > > > > > > > >
> > > > > > > > > ‑Topi
> > > > > > > >
> > > > > > > > What's the data that supports having noexec /dev anyway? With root
> > > > > > > > access I can then just use something else like /dev/shm mount.
> > > > > > > >
> > > > > > > > Has there been out in the wild real world cases that noexec mount
> > > > > > > > of would have prevented?
> > > > > > > >
> > > > > > > > For me this sounds a lot just something that "feels more secure"
> > > > > > > > without any measurable benefit. Can you prove me wrong?
> > > > > > >
> > > > > > > I don't think security works that way. An attacker has various methods
> > to
> > > > > > > choose from, some are more interesting than others. The case where
> > > > rw,exec
> > > > > > > /dev would be interesting would imply that easier or more common
> > avenues
> > > > > > > would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > > > > > > /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
> > > > approach
> > > > > > > with no need for any file system access is getting more common. It
> > does
> > > > not
> > > > > > > mean that it would not be prudent to block the relatively easy
> > approaches
> > > > > > > too, including /dev.
> > > > > >
> > > > > > What if we add a new mount option "chrexec", which allows exec
> > > > > > for character devices (S_IFCHR).
> > > > >
> > > > > I think devices are a bad match for SGX because devices haven't been
> > > > > executable and SGX is actually an operation for memory. So something
> > > > > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
> > > > > would be much more natural. Even better would be something that
> > > > > conceptully also works for AMD version (either with the same flags or
> > > > > MFD_SGX / MFD_whatever_the_AMD_version_is).
> > > >
> > > > +1
> > >
> > > SGX reserved memory from kernel's point of view is IO memory.
> > >
> > > Mapping SGX to memfd would not be a great idea, as it does not map
> > > into concept of anonymous file backed by regular memory.
> > >
> > > A device file is very natural match actually. We have ioctl API for
> > > uploading enclave pages during the build procedure to the enclave and
> > > custom #PF handler. Conceptually it's a lot like video memory or such
> > > special device specific memory area.
> > >
> > > There's no AMD equivalent of this technology.
> >
> > Hi!
> >
> > Back to "noexec": AFAIR the execute bit does not make sense for device files,
> > and the purpose probably was to avoid execution of non-device files (e.g.
> > regular executables) from inside /dev (where they should not be). So in this
> > view "noexec" makes sense.
> > There were similar arguments for not allowing device files in user
> > directories.
>
> PR#17940 (https://github.com/systemd/systemd/pull/17940) was merged, so /dev
> will now on be mounted with "exec" by systemd.
>
> I made issue #17942 (https://github.com/systemd/systemd/issues/17942) to
> discuss related hardening options. I'm leaning towards
> NoExecPaths=/ExecPaths= as it would enable nice hardening by allow-listing
> of all executable content for system services with simple directives like:
>
> [Service]
> NoExecPaths=/
> ExecPaths=/usr/sbin/daemon /lib64/ld-linux-x86-64.so.2 /usr/lib
>
> Then a service infected with malware would not be able to execute a shell
> present in the system or downloaded later, if that was not explicitly
> allowed. /dev would also not have "exec" flag by default, but SGX could be
> allowed with "ExecPaths=/dev/sgx" when needed.
OK, this sounds relieving, thank you (late resp, I was vacation last
week).
> -Topi
/Jarkko
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Topi Miettinen @ 2020-12-16 13:05 UTC (permalink / raw)
To: Ulrich Windl, jarkko
Cc: luto, Ben Hutchings, jethro, bruce.schlobohm, kai.svahn, luto,
haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <5FD9DB8D020000A10003D8DC@gwsmtp.uni-regensburg.de>
On 16.12.2020 12.03, Ulrich Windl wrote:
>>>> Jarkko Sakkinen <jarkko@kernel.org> schrieb am 15.12.2020 um 05:19 in
> Nachricht
> <20201215041903.GA21875@kernel.org>:
>> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
>>>>>> Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
>>> Nachricht
>>> <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
>>>> On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>>>>> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>>>>>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>>>>>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
>>>>>>>>>>> No results. So making /dev noexec doesn't seem to have any
> benefit.
>>>>>>>>>>
>>>>>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>>>>>> executables if it is also mounted exec (W^X).
>>>>>>>>>
>>>>>>>>> UID 0 can just change mount options, though, unless SELinux or
> similar
>>> is
>>>> used. And SELinux can protect /dev just fine without noexec.
>>>>>>>>
>>>>>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
>>> SELinux
>>>>>>>> is not universal and the policies might not contain all users or
>>> services.
>>>>>>>>
>>>>>>>> ‑Topi
>>>>>>>
>>>>>>> What's the data that supports having noexec /dev anyway? With root
>>>>>>> access I can then just use something else like /dev/shm mount.
>>>>>>>
>>>>>>> Has there been out in the wild real world cases that noexec mount
>>>>>>> of would have prevented?
>>>>>>>
>>>>>>> For me this sounds a lot just something that "feels more secure"
>>>>>>> without any measurable benefit. Can you prove me wrong?
>>>>>>
>>>>>> I don't think security works that way. An attacker has various methods
> to
>>>>>> choose from, some are more interesting than others. The case where
>>> rw,exec
>>>>>> /dev would be interesting would imply that easier or more common
> avenues
>>>>>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>>>>>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
>>> approach
>>>>>> with no need for any file system access is getting more common. It
> does
>>> not
>>>>>> mean that it would not be prudent to block the relatively easy
> approaches
>>>>>> too, including /dev.
>>>>>
>>>>> What if we add a new mount option "chrexec", which allows exec
>>>>> for character devices (S_IFCHR).
>>>>
>>>> I think devices are a bad match for SGX because devices haven't been
>>>> executable and SGX is actually an operation for memory. So something
>>>> like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
>>>> would be much more natural. Even better would be something that
>>>> conceptully also works for AMD version (either with the same flags or
>>>> MFD_SGX / MFD_whatever_the_AMD_version_is).
>>>
>>> +1
>>
>> SGX reserved memory from kernel's point of view is IO memory.
>>
>> Mapping SGX to memfd would not be a great idea, as it does not map
>> into concept of anonymous file backed by regular memory.
>>
>> A device file is very natural match actually. We have ioctl API for
>> uploading enclave pages during the build procedure to the enclave and
>> custom #PF handler. Conceptually it's a lot like video memory or such
>> special device specific memory area.
>>
>> There's no AMD equivalent of this technology.
>
> Hi!
>
> Back to "noexec": AFAIR the execute bit does not make sense for device files,
> and the purpose probably was to avoid execution of non-device files (e.g.
> regular executables) from inside /dev (where they should not be). So in this
> view "noexec" makes sense.
> There were similar arguments for not allowing device files in user
> directories.
PR#17940 (https://github.com/systemd/systemd/pull/17940) was merged, so
/dev will now on be mounted with "exec" by systemd.
I made issue #17942 (https://github.com/systemd/systemd/issues/17942) to
discuss related hardening options. I'm leaning towards
NoExecPaths=/ExecPaths= as it would enable nice hardening by
allow-listing of all executable content for system services with simple
directives like:
[Service]
NoExecPaths=/
ExecPaths=/usr/sbin/daemon /lib64/ld-linux-x86-64.so.2 /usr/lib
Then a service infected with malware would not be able to execute a
shell present in the system or downloaded later, if that was not
explicitly allowed. /dev would also not have "exec" flag by default, but
SGX could be allowed with "ExecPaths=/dev/sgx" when needed.
-Topi
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Ulrich Windl @ 2020-12-16 10:03 UTC (permalink / raw)
To: jarkko
Cc: luto, Ben Hutchings, jethro, toiwoton, bruce.schlobohm, kai.svahn,
luto, haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <20201215041903.GA21875@kernel.org>
>>> Jarkko Sakkinen <jarkko@kernel.org> schrieb am 15.12.2020 um 05:19 in
Nachricht
<20201215041903.GA21875@kernel.org>:
> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
>> >>> Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
>> Nachricht
>> <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
>> > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>> >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>> >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>> >>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>> >>>>>>>> As a further argument, I just did this on a Fedora system:
>> >>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
>> >>>>>>>> No results. So making /dev noexec doesn't seem to have any
benefit.
>> >>>>>>>
>> >>>>>>> It's no surprise that there aren't any executables in /dev since
>> >>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>> >>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>> >>>>>>> needed) and thus a potential location for constructing unapproved
>> >>>>>>> executables if it is also mounted exec (W^X).
>> >>>>>>
>> >>>>>> UID 0 can just change mount options, though, unless SELinux or
similar
>> is
>> > used. And SELinux can protect /dev just fine without noexec.
>> >>>>>
>> >>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
>> SELinux
>> >>>>> is not universal and the policies might not contain all users or
>> services.
>> >>>>>
>> >>>>> ‑Topi
>> >>>>
>> >>>> What's the data that supports having noexec /dev anyway? With root
>> >>>> access I can then just use something else like /dev/shm mount.
>> >>>>
>> >>>> Has there been out in the wild real world cases that noexec mount
>> >>>> of would have prevented?
>> >>>>
>> >>>> For me this sounds a lot just something that "feels more secure"
>> >>>> without any measurable benefit. Can you prove me wrong?
>> >>>
>> >>> I don't think security works that way. An attacker has various methods
to
>> >>> choose from, some are more interesting than others. The case where
>> rw,exec
>> >>> /dev would be interesting would imply that easier or more common
avenues
>> >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>> >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
>> approach
>> >>> with no need for any file system access is getting more common. It
does
>> not
>> >>> mean that it would not be prudent to block the relatively easy
approaches
>> >>> too, including /dev.
>> >>
>> >> What if we add a new mount option "chrexec", which allows exec
>> >> for character devices (S_IFCHR).
>> >
>> > I think devices are a bad match for SGX because devices haven't been
>> > executable and SGX is actually an operation for memory. So something
>> > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
>> > would be much more natural. Even better would be something that
>> > conceptully also works for AMD version (either with the same flags or
>> > MFD_SGX / MFD_whatever_the_AMD_version_is).
>>
>> +1
>
> SGX reserved memory from kernel's point of view is IO memory.
>
> Mapping SGX to memfd would not be a great idea, as it does not map
> into concept of anonymous file backed by regular memory.
>
> A device file is very natural match actually. We have ioctl API for
> uploading enclave pages during the build procedure to the enclave and
> custom #PF handler. Conceptually it's a lot like video memory or such
> special device specific memory area.
>
> There's no AMD equivalent of this technology.
Hi!
Back to "noexec": AFAIR the execute bit does not make sense for device files,
and the purpose probably was to avoid execution of non-device files (e.g.
regular executables) from inside /dev (where they should not be). So in this
view "noexec" makes sense.
There were similar arguments for not allowing device files in user
directories.
Regards,
Ulrich
>
> /Jarkko
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Jarkko Sakkinen @ 2020-12-15 4:27 UTC (permalink / raw)
To: Ulrich Windl
Cc: toiwoton, luto, Ben Hutchings, jethro, bruce.schlobohm, kai.svahn,
luto, haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <20201215041903.GA21875@kernel.org>
On Tue, Dec 15, 2020 at 06:19:09AM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
> > >>> Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
> > Nachricht
> > <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
> > > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
> > >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > >>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > >>>>>>>> As a further argument, I just did this on a Fedora system:
> > >>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
> > >>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
> > >>>>>>>
> > >>>>>>> It's no surprise that there aren't any executables in /dev since
> > >>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
> > >>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
> > >>>>>>> needed) and thus a potential location for constructing unapproved
> > >>>>>>> executables if it is also mounted exec (W^X).
> > >>>>>>
> > >>>>>> UID 0 can just change mount options, though, unless SELinux or similar
> > is
> > > used. And SELinux can protect /dev just fine without noexec.
> > >>>>>
> > >>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
> > SELinux
> > >>>>> is not universal and the policies might not contain all users or
> > services.
> > >>>>>
> > >>>>> ‑Topi
> > >>>>
> > >>>> What's the data that supports having noexec /dev anyway? With root
> > >>>> access I can then just use something else like /dev/shm mount.
> > >>>>
> > >>>> Has there been out in the wild real world cases that noexec mount
> > >>>> of would have prevented?
> > >>>>
> > >>>> For me this sounds a lot just something that "feels more secure"
> > >>>> without any measurable benefit. Can you prove me wrong?
> > >>>
> > >>> I don't think security works that way. An attacker has various methods to
> > >>> choose from, some are more interesting than others. The case where
> > rw,exec
> > >>> /dev would be interesting would imply that easier or more common avenues
> > >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
> > approach
> > >>> with no need for any file system access is getting more common. It does
> > not
> > >>> mean that it would not be prudent to block the relatively easy approaches
> > >>> too, including /dev.
> > >>
> > >> What if we add a new mount option "chrexec", which allows exec
> > >> for character devices (S_IFCHR).
> > >
> > > I think devices are a bad match for SGX because devices haven't been
> > > executable and SGX is actually an operation for memory. So something
> > > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
> > > would be much more natural. Even better would be something that
> > > conceptully also works for AMD version (either with the same flags or
> > > MFD_SGX / MFD_whatever_the_AMD_version_is).
> >
> > +1
>
> SGX reserved memory from kernel's point of view is IO memory.
>
> Mapping SGX to memfd would not be a great idea, as it does not map
> into concept of anonymous file backed by regular memory.
>
> A device file is very natural match actually. We have ioctl API for
> uploading enclave pages during the build procedure to the enclave and
> custom #PF handler. Conceptually it's a lot like video memory or such
> special device specific memory area.
>
> There's no AMD equivalent of this technology.
Anyway, I take a not on "PROT_SGX" as one of the ways sort this out in
the future. That would at least fit what we have. Thanks for all the
feedback.
/Jarkko
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Jarkko Sakkinen @ 2020-12-15 4:19 UTC (permalink / raw)
To: Ulrich Windl
Cc: toiwoton, luto, Ben Hutchings, jethro, bruce.schlobohm, kai.svahn,
luto, haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <5FD7137E020000A10003D81B@gwsmtp.uni-regensburg.de>
On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
> >>> Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
> Nachricht
> <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
> > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
> >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> >>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> >>>>>>>> As a further argument, I just did this on a Fedora system:
> >>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
> >>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
> >>>>>>>
> >>>>>>> It's no surprise that there aren't any executables in /dev since
> >>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
> >>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
> >>>>>>> needed) and thus a potential location for constructing unapproved
> >>>>>>> executables if it is also mounted exec (W^X).
> >>>>>>
> >>>>>> UID 0 can just change mount options, though, unless SELinux or similar
> is
> > used. And SELinux can protect /dev just fine without noexec.
> >>>>>
> >>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
> SELinux
> >>>>> is not universal and the policies might not contain all users or
> services.
> >>>>>
> >>>>> ‑Topi
> >>>>
> >>>> What's the data that supports having noexec /dev anyway? With root
> >>>> access I can then just use something else like /dev/shm mount.
> >>>>
> >>>> Has there been out in the wild real world cases that noexec mount
> >>>> of would have prevented?
> >>>>
> >>>> For me this sounds a lot just something that "feels more secure"
> >>>> without any measurable benefit. Can you prove me wrong?
> >>>
> >>> I don't think security works that way. An attacker has various methods to
> >>> choose from, some are more interesting than others. The case where
> rw,exec
> >>> /dev would be interesting would imply that easier or more common avenues
> >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
> approach
> >>> with no need for any file system access is getting more common. It does
> not
> >>> mean that it would not be prudent to block the relatively easy approaches
> >>> too, including /dev.
> >>
> >> What if we add a new mount option "chrexec", which allows exec
> >> for character devices (S_IFCHR).
> >
> > I think devices are a bad match for SGX because devices haven't been
> > executable and SGX is actually an operation for memory. So something
> > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
> > would be much more natural. Even better would be something that
> > conceptully also works for AMD version (either with the same flags or
> > MFD_SGX / MFD_whatever_the_AMD_version_is).
>
> +1
SGX reserved memory from kernel's point of view is IO memory.
Mapping SGX to memfd would not be a great idea, as it does not map
into concept of anonymous file backed by regular memory.
A device file is very natural match actually. We have ioctl API for
uploading enclave pages during the build procedure to the enclave and
custom #PF handler. Conceptually it's a lot like video memory or such
special device specific memory area.
There's no AMD equivalent of this technology.
/Jarkko
^ permalink raw reply
* Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Ulrich Windl @ 2020-12-14 7:25 UTC (permalink / raw)
To: toiwoton, jarkko
Cc: luto, Ben Hutchings, jethro, bruce.schlobohm, kai.svahn, luto,
haitao.huang, jarkko.sakkinen,
systemd-devel@lists.freedesktop.org, casey, sds, linux-hotplug,
linux-sgx
In-Reply-To: <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>
>>> Topi Miettinen <toiwoton@gmail.com> schrieb am 11.12.2020 um 12:46 in
Nachricht
<27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com>:
> On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
>>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>>>
>>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>>> executables if it is also mounted exec (W^X).
>>>>>>
>>>>>> UID 0 can just change mount options, though, unless SELinux or similar
is
> used. And SELinux can protect /dev just fine without noexec.
>>>>>
>>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
SELinux
>>>>> is not universal and the policies might not contain all users or
services.
>>>>>
>>>>> ‑Topi
>>>>
>>>> What's the data that supports having noexec /dev anyway? With root
>>>> access I can then just use something else like /dev/shm mount.
>>>>
>>>> Has there been out in the wild real world cases that noexec mount
>>>> of would have prevented?
>>>>
>>>> For me this sounds a lot just something that "feels more secure"
>>>> without any measurable benefit. Can you prove me wrong?
>>>
>>> I don't think security works that way. An attacker has various methods to
>>> choose from, some are more interesting than others. The case where
rw,exec
>>> /dev would be interesting would imply that easier or more common avenues
>>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
approach
>>> with no need for any file system access is getting more common. It does
not
>>> mean that it would not be prudent to block the relatively easy approaches
>>> too, including /dev.
>>
>> What if we add a new mount option "chrexec", which allows exec
>> for character devices (S_IFCHR).
>
> I think devices are a bad match for SGX because devices haven't been
> executable and SGX is actually an operation for memory. So something
> like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
> would be much more natural. Even better would be something that
> conceptully also works for AMD version (either with the same flags or
> MFD_SGX / MFD_whatever_the_AMD_version_is).
+1
^ permalink raw reply
* Re: [systemd-devel] Creating executable device nodes in /dev?
From: Christian Brauner @ 2020-12-12 12:32 UTC (permalink / raw)
To: Greg KH
Cc: Jarkko Sakkinen, systemd Mailing List, Haitao Huang,
Schlobohm, Bruce, Ben Hutchings, linux-hotplug, Jethro Beekman,
Jarkko Sakkinen, Andy Lutomirski, Andy Lutomirski,
Casey Schaufler, Svahn, Kai, Stephen Smalley, linux-sgx
In-Reply-To: <X9NYG1+ke6nPwBvO@kroah.com>
On Fri, Dec 11, 2020 at 12:29:31PM +0100, Greg KH wrote:
> On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > > > > No results. So making /dev noexec doesn't seem to have any benefit.
> > > > > > >
> > > > > > > It's no surprise that there aren't any executables in /dev since
> > > > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > > > needed) and thus a potential location for constructing unapproved
> > > > > > > executables if it is also mounted exec (W^X).
> > > > > >
> > > > > > UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
> > > > >
> > > > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
> > > > > is not universal and the policies might not contain all users or services.
> > > > >
> > > > > -Topi
> > > >
> > > > What's the data that supports having noexec /dev anyway? With root
> > > > access I can then just use something else like /dev/shm mount.
> > > >
> > > > Has there been out in the wild real world cases that noexec mount
> > > > of would have prevented?
> > > >
> > > > For me this sounds a lot just something that "feels more secure"
> > > > without any measurable benefit. Can you prove me wrong?
> > >
> > > I don't think security works that way. An attacker has various methods to
> > > choose from, some are more interesting than others. The case where rw,exec
> > > /dev would be interesting would imply that easier or more common avenues
> > > would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > > /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
> > > with no need for any file system access is getting more common. It does not
> > > mean that it would not be prudent to block the relatively easy approaches
> > > too, including /dev.
> >
> > What if we add a new mount option "chrexec", which allows exec
> > for character devices (S_IFCHR).
>
> Oh please no.
(Once more because my I was subscribed with an old email address.)
Greg's right. That's very obviously a horrible hack so this is an
instant nak from my side.
Christian
^ permalink raw reply
* Re: [systemd-devel] Creating executable device nodes in /dev?
From: Christian Brauner @ 2020-12-12 11:51 UTC (permalink / raw)
To: Greg KH
Cc: Jarkko Sakkinen, systemd Mailing List, Haitao Huang,
Schlobohm, Bruce, Ben Hutchings, linux-hotplug, Jethro Beekman,
Jarkko Sakkinen, Andy Lutomirski, Andy Lutomirski,
Casey Schaufler, Svahn, Kai, Stephen Smalley, linux-sgx
In-Reply-To: <X9NYG1+ke6nPwBvO@kroah.com>
On Fri, Dec 11, 2020 at 12:29:31PM +0100, Greg KH wrote:
> On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > > > > No results. So making /dev noexec doesn't seem to have any benefit.
> > > > > > >
> > > > > > > It's no surprise that there aren't any executables in /dev since
> > > > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > > > needed) and thus a potential location for constructing unapproved
> > > > > > > executables if it is also mounted exec (W^X).
> > > > > >
> > > > > > UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
> > > > >
> > > > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
> > > > > is not universal and the policies might not contain all users or services.
> > > > >
> > > > > -Topi
> > > >
> > > > What's the data that supports having noexec /dev anyway? With root
> > > > access I can then just use something else like /dev/shm mount.
> > > >
> > > > Has there been out in the wild real world cases that noexec mount
> > > > of would have prevented?
> > > >
> > > > For me this sounds a lot just something that "feels more secure"
> > > > without any measurable benefit. Can you prove me wrong?
> > >
> > > I don't think security works that way. An attacker has various methods to
> > > choose from, some are more interesting than others. The case where rw,exec
> > > /dev would be interesting would imply that easier or more common avenues
> > > would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > > /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
> > > with no need for any file system access is getting more common. It does not
> > > mean that it would not be prudent to block the relatively easy approaches
> > > too, including /dev.
> >
> > What if we add a new mount option "chrexec", which allows exec
> > for character devices (S_IFCHR).
>
> Oh please no.
Greg's right. That's very obviously a horrible hack so this is an
instant nak from my side.
Christian
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Topi Miettinen @ 2020-12-11 11:46 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Andy Lutomirski, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <20201211104635.GD12091@kernel.org>
On 11.12.2020 12.46, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>> $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>>
>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>> executables if it is also mounted exec (W^X).
>>>>>
>>>>> UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
>>>>
>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
>>>> is not universal and the policies might not contain all users or services.
>>>>
>>>> -Topi
>>>
>>> What's the data that supports having noexec /dev anyway? With root
>>> access I can then just use something else like /dev/shm mount.
>>>
>>> Has there been out in the wild real world cases that noexec mount
>>> of would have prevented?
>>>
>>> For me this sounds a lot just something that "feels more secure"
>>> without any measurable benefit. Can you prove me wrong?
>>
>> I don't think security works that way. An attacker has various methods to
>> choose from, some are more interesting than others. The case where rw,exec
>> /dev would be interesting would imply that easier or more common avenues
>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
>> with no need for any file system access is getting more common. It does not
>> mean that it would not be prudent to block the relatively easy approaches
>> too, including /dev.
>
> What if we add a new mount option "chrexec", which allows exec
> for character devices (S_IFCHR).
I think devices are a bad match for SGX because devices haven't been
executable and SGX is actually an operation for memory. So something
like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
would be much more natural. Even better would be something that
conceptully also works for AMD version (either with the same flags or
MFD_SGX / MFD_whatever_the_AMD_version_is).
-Topi
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Zbigniew Jędrzejewski-Szmek @ 2020-12-11 11:36 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andy Lutomirski, Topi Miettinen, Jarkko Sakkinen, Andy Lutomirski,
linux-hotplug, systemd Mailing List, Jarkko Sakkinen,
Jethro Beekman, Casey Schaufler, linux-sgx, Svahn, Kai,
Schlobohm, Bruce, Stephen Smalley, Haitao Huang
In-Reply-To: <fd81b46065cd33397e38a17096a206760b7b2937.camel@decadent.org.uk>
On Wed, Dec 09, 2020 at 10:58:59PM +0100, Ben Hutchings wrote:
> I'm convinced. I've committed a change to initramfs-tools that removes
> the noexec mount option again.
Systemd counterpart: https://github.com/systemd/systemd/pull/17940.
Zbyszek
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Greg KH @ 2020-12-11 11:29 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Topi Miettinen, Andy Lutomirski, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <20201211104635.GD12091@kernel.org>
On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > > > No results. So making /dev noexec doesn't seem to have any benefit.
> > > > > >
> > > > > > It's no surprise that there aren't any executables in /dev since
> > > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > > needed) and thus a potential location for constructing unapproved
> > > > > > executables if it is also mounted exec (W^X).
> > > > >
> > > > > UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
> > > >
> > > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
> > > > is not universal and the policies might not contain all users or services.
> > > >
> > > > -Topi
> > >
> > > What's the data that supports having noexec /dev anyway? With root
> > > access I can then just use something else like /dev/shm mount.
> > >
> > > Has there been out in the wild real world cases that noexec mount
> > > of would have prevented?
> > >
> > > For me this sounds a lot just something that "feels more secure"
> > > without any measurable benefit. Can you prove me wrong?
> >
> > I don't think security works that way. An attacker has various methods to
> > choose from, some are more interesting than others. The case where rw,exec
> > /dev would be interesting would imply that easier or more common avenues
> > would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
> > with no need for any file system access is getting more common. It does not
> > mean that it would not be prudent to block the relatively easy approaches
> > too, including /dev.
>
> What if we add a new mount option "chrexec", which allows exec
> for character devices (S_IFCHR).
Oh please no.
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Jarkko Sakkinen @ 2020-12-11 10:46 UTC (permalink / raw)
To: Topi Miettinen
Cc: Andy Lutomirski, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <b1cf9503-0c1c-ab9e-3cc4-ef2b7611b280@gmail.com>
On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > > No results. So making /dev noexec doesn't seem to have any benefit.
> > > > >
> > > > > It's no surprise that there aren't any executables in /dev since
> > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > needed) and thus a potential location for constructing unapproved
> > > > > executables if it is also mounted exec (W^X).
> > > >
> > > > UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
> > >
> > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
> > > is not universal and the policies might not contain all users or services.
> > >
> > > -Topi
> >
> > What's the data that supports having noexec /dev anyway? With root
> > access I can then just use something else like /dev/shm mount.
> >
> > Has there been out in the wild real world cases that noexec mount
> > of would have prevented?
> >
> > For me this sounds a lot just something that "feels more secure"
> > without any measurable benefit. Can you prove me wrong?
>
> I don't think security works that way. An attacker has various methods to
> choose from, some are more interesting than others. The case where rw,exec
> /dev would be interesting would imply that easier or more common avenues
> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
> with no need for any file system access is getting more common. It does not
> mean that it would not be prudent to block the relatively easy approaches
> too, including /dev.
What if we add a new mount option "chrexec", which allows exec
for character devices (S_IFCHR).
> -Topi
/Jarkko
^ permalink raw reply
* Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
From: Jarkko Sakkinen @ 2020-12-11 10:40 UTC (permalink / raw)
To: Ulrich Windl
Cc: systemd-devel@lists.freedesktop.org, linux-hotplug, linux-sgx
In-Reply-To: <5FD083BC020000A10003D6A0@gwsmtp.uni-regensburg.de>
On Wed, Dec 09, 2020 at 08:58:52AM +0100, Ulrich Windl wrote:
> >>> Jarkko Sakkinen <jarkko@kernel.org> schrieb am 09.12.2020 um 01:15 in Nachricht
> <20201209001521.GA64007@kernel.org>:
>
> ...
> >
> > What's the data that supports having noexec /dev anyway? With root
> > access I can then just use something else like /dev/shm mount.
> >
> > Has there been out in the wild real world cases that noexec mount
> > of would have prevented?
> >
> > For me this sounds a lot just something that "feels more secure"
> > without any measurable benefit. Can you prove me wrong?
>
> I think the better question is: Why not allow it? I.e.: Why do you want to forbid it?
>
> Event though I wouldn't like it myself, I could even think of noexec /tmp.
On an instance of an OS you should limit whatever is appropriate for
your use case. The debate is about sane defaults.
My argument is essentially that noexec /dev is not a sane default.
For anyone to who this makes sense, does such thing anyway. For
others, noexec /dev is only artificially useful.
> Regards,
> Ulrich
/Jarkko
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Ben Hutchings @ 2020-12-09 21:58 UTC (permalink / raw)
To: Andy Lutomirski, Topi Miettinen
Cc: Jarkko Sakkinen, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang
In-Reply-To: <308AE66A-F401-4D2D-9D53-17E11EAF68E3@amacapital.net>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
On Wed, 2020-12-09 at 07:14 -0800, Andy Lutomirski wrote:
> On Dec 9, 2020, at 12:58 AM, Topi Miettinen <toiwoton@gmail.com> wrote:
[...]
> > I think we agree that there's a need for either way to allow SGX
> > (if default is hardened) or a hardening option (in the opposite
> > case). For systemd I see two approaches:
> >
> > 1. Default noexec /dev, override with something like
> > - ExecPaths=/dev
> > - MountOptions=/dev:rw,exec,dev,nosuid
> > - or even MountOptions=/dev/sgx:rw,exec,dev,nosuid
> > - ProtectDev=no
> > - AllowSGX=yes
> >
> > 2. Default exec /dev, override with
> > - NoExecPaths=/dev
> > - MountOptions=/dev:rw,noexec,dev,nosuid
> > - ProtectDev=yes
> > - DenySGX=yes
> >
> > I'd prefer 1. but of course 2. would be reasonable.
>
> I would argue for 2, for the following reason. I absolutely agree
> that hardening a system by making it impossible to create executable
> code dynamically is valuable, but I don’t think it’s a good default.
> By default, programs like gcc and clang should work, but so should
> JITs, and JITs are getting more popular and powerful all the time.
> In a default setting that allows JITs, etc, I see no benefit at all
> to making /dev noexec. To the contrary, making /dev noexec seems like
> plugging a little restricted corner of code creation (because it
> requires UID=0) while allowing the easy ways (/tmp, /home, /dev/shm,
> unshare(2), mmap(), etc). By all means let admins harden this, but I
> see no reason to apply some of the hardening when the rest is
> disabled.
[...]
I'm convinced. I've committed a change to initramfs-tools that removes
the noexec mount option again.
Ben.
--
Ben Hutchings
It is a miracle that curiosity survives formal education.
- Albert Einstein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Andy Lutomirski @ 2020-12-09 19:32 UTC (permalink / raw)
To: Topi Miettinen
Cc: Jarkko Sakkinen, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <293dd2c6-972f-b2ae-666e-aa6b01b94b26@gmail.com>
On Wed, Dec 9, 2020 at 11:22 AM Topi Miettinen <toiwoton@gmail.com> wrote:
>
> On 9.12.2020 17.14, Andy Lutomirski wrote:
> >
> Maybe also malware which can escape all means of detection, enforced by
> the CPU? Though I don't know if any malware scanners for Linux work can
> check for fileless, memory only malware.
I don't think this is really relevant to malware detection. You can't
do syscalls from SGX code, for example, and, even if you could,
malware behavior analysis would be unaffected. The concern seems to
be more that, once someone has discovered some malware, if it's
protected by SGX then it's plausible that you can't disassemble it.
>
> >
> > In Intel’s original vision, only specially licensed vendors could create SGX software, but Linux pushed back against this quite hard, and new CPUs allow unlicensed enclaves. So your Skylake CPUs support SGX, but not on Linux.
>
> Kudos to Linux for the push.
:)
I don't know if Linux gets full credit for this, but I think we at
least had some impact.
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Topi Miettinen @ 2020-12-09 19:22 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jarkko Sakkinen, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <308AE66A-F401-4D2D-9D53-17E11EAF68E3@amacapital.net>
On 9.12.2020 17.14, Andy Lutomirski wrote:
>
>> On Dec 9, 2020, at 12:58 AM, Topi Miettinen <toiwoton@gmail.com> wrote:
>>
>> On 9.12.2020 2.42, Jarkko Sakkinen wrote:
>>>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
>>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>>> $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
>>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>>>
>>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>>> executables if it is also mounted exec (W^X).
>>>>>>
>>>>>> UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
>>>>>
>>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
>>>>> is not universal and the policies might not contain all users or services.
>>>>>
>>>>> -Topi
>>>>
>>>> What's the data that supports having noexec /dev anyway? With root
>>>> access I can then just use something else like /dev/shm mount.
>>>>
>>>> Has there been out in the wild real world cases that noexec mount
>>>> of would have prevented?
>>> Typo: "of" = "of /dev"
>>>> For me this sounds a lot just something that "feels more secure"
>>>> without any measurable benefit. Can you prove me wrong?
>>> The debate is circled around something not well defined. Of course you
>>> get theoretically more safe system when you decrease priviliges anywhere
>>> in the system. Like you could start do grazy things with stuff that
>>> unprivilged user has access, in order to prevent malware to elevate to
>>> UID 0 in the first place.
>>> I think where this go intellectually wrong is that we are talking about
>>> *default installation* of a distribution. That should have somewhat sane
>>> common sense access control settings. For like a normal desktop user
>>> noexec /dev will not do any possible favor.
>>> Then there is the case when you want to harden installation for an
>>> application, let's' say some server. In that case you will anyway
>>> fine-tune the security settings and go grazy enough with hardening.
>>> When you tailor a server, it's a standard practice to enumerate and
>>> adjust the mount points if needed.
>>
>> I think we agree that there's a need for either way to allow SGX (if default is hardened) or a hardening option (in the opposite case). For systemd I see two approaches:
>>
>> 1. Default noexec /dev, override with something like
>> - ExecPaths=/dev
>> - MountOptions=/dev:rw,exec,dev,nosuid
>> - or even MountOptions=/dev/sgx:rw,exec,dev,nosuid
>> - ProtectDev=no
>> - AllowSGX=yes
>>
>> 2. Default exec /dev, override with
>> - NoExecPaths=/dev
>> - MountOptions=/dev:rw,noexec,dev,nosuid
>> - ProtectDev=yes
>> - DenySGX=yes
>>
>> I'd prefer 1. but of course 2. would be reasonable.
>
> I would argue for 2, for the following reason. I absolutely agree that hardening a system by making it impossible to create executable code dynamically is valuable, but I don’t think it’s a good default. By default, programs like gcc and clang should work, but so should JITs, and JITs are getting more popular and powerful all the time. In a default setting that allows JITs, etc, I see no benefit at all to making /dev noexec. To the contrary, making /dev noexec seems like plugging a little restricted corner of code creation (because it requires UID=0) while allowing the easy ways (/tmp, /home, /dev/shm, unshare(2), mmap(), etc). By all means let admins harden this, but I see no reason to apply some of the hardening when the rest is disabled.
Makes sense, especially if anything in theory could be expected to use
SGX. In practice, probably no system services will at least initially,
so hardening knobs make also sense.
>
>>
>>> To summarize, I neither understand the intended target audience.
>>
>> We have something in common: me neither. What's the target audience for SGX? What's the use case? What are the users: browsers, system services? How would applications use SGX? Should udev rules for /dev/sgx make it available to any logged in users with uaccess tags?
>>
>>
>
> I would certainly like it to be available to all software, with the possible exception of extra-hardened systems. Using SGX is not really an interesting attack surface. The main threat is that malware might use SGX to make itself hard to reverse engineer.
Maybe also malware which can escape all means of detection, enforced by
the CPU? Though I don't know if any malware scanners for Linux work can
check for fileless, memory only malware.
>
> In Intel’s original vision, only specially licensed vendors could create SGX software, but Linux pushed back against this quite hard, and new CPUs allow unlicensed enclaves. So your Skylake CPUs support SGX, but not on Linux.
Kudos to Linux for the push.
-Topi
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Andy Lutomirski @ 2020-12-09 15:14 UTC (permalink / raw)
To: Topi Miettinen
Cc: Jarkko Sakkinen, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <f2279f2d-f0a6-a948-9691-96f47a0bd997@gmail.com>
> On Dec 9, 2020, at 12:58 AM, Topi Miettinen <toiwoton@gmail.com> wrote:
>
> On 9.12.2020 2.42, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>> $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>>
>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>> executables if it is also mounted exec (W^X).
>>>>>
>>>>> UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
>>>>
>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
>>>> is not universal and the policies might not contain all users or services.
>>>>
>>>> -Topi
>>>
>>> What's the data that supports having noexec /dev anyway? With root
>>> access I can then just use something else like /dev/shm mount.
>>>
>>> Has there been out in the wild real world cases that noexec mount
>>> of would have prevented?
>> Typo: "of" = "of /dev"
>>> For me this sounds a lot just something that "feels more secure"
>>> without any measurable benefit. Can you prove me wrong?
>> The debate is circled around something not well defined. Of course you
>> get theoretically more safe system when you decrease priviliges anywhere
>> in the system. Like you could start do grazy things with stuff that
>> unprivilged user has access, in order to prevent malware to elevate to
>> UID 0 in the first place.
>> I think where this go intellectually wrong is that we are talking about
>> *default installation* of a distribution. That should have somewhat sane
>> common sense access control settings. For like a normal desktop user
>> noexec /dev will not do any possible favor.
>> Then there is the case when you want to harden installation for an
>> application, let's' say some server. In that case you will anyway
>> fine-tune the security settings and go grazy enough with hardening.
>> When you tailor a server, it's a standard practice to enumerate and
>> adjust the mount points if needed.
>
> I think we agree that there's a need for either way to allow SGX (if default is hardened) or a hardening option (in the opposite case). For systemd I see two approaches:
>
> 1. Default noexec /dev, override with something like
> - ExecPaths=/dev
> - MountOptions=/dev:rw,exec,dev,nosuid
> - or even MountOptions=/dev/sgx:rw,exec,dev,nosuid
> - ProtectDev=no
> - AllowSGX=yes
>
> 2. Default exec /dev, override with
> - NoExecPaths=/dev
> - MountOptions=/dev:rw,noexec,dev,nosuid
> - ProtectDev=yes
> - DenySGX=yes
>
> I'd prefer 1. but of course 2. would be reasonable.
I would argue for 2, for the following reason. I absolutely agree that hardening a system by making it impossible to create executable code dynamically is valuable, but I don’t think it’s a good default. By default, programs like gcc and clang should work, but so should JITs, and JITs are getting more popular and powerful all the time. In a default setting that allows JITs, etc, I see no benefit at all to making /dev noexec. To the contrary, making /dev noexec seems like plugging a little restricted corner of code creation (because it requires UID=0) while allowing the easy ways (/tmp, /home, /dev/shm, unshare(2), mmap(), etc). By all means let admins harden this, but I see no reason to apply some of the hardening when the rest is disabled.
>
>> To summarize, I neither understand the intended target audience.
>
> We have something in common: me neither. What's the target audience for SGX? What's the use case? What are the users: browsers, system services? How would applications use SGX? Should udev rules for /dev/sgx make it available to any logged in users with uaccess tags?
>
>
I would certainly like it to be available to all software, with the possible exception of extra-hardened systems. Using SGX is not really an interesting attack surface. The main threat is that malware might use SGX to make itself hard to reverse engineer.
In Intel’s original vision, only specially licensed vendors could create SGX software, but Linux pushed back against this quite hard, and new CPUs allow unlicensed enclaves. So your Skylake CPUs support SGX, but not on Linux.
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Jethro Beekman @ 2020-12-09 9:07 UTC (permalink / raw)
To: Topi Miettinen, Jarkko Sakkinen
Cc: Andy Lutomirski, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Casey Schaufler, linux-sgx,
Svahn, Kai, Schlobohm, Bruce, Stephen Smalley, Haitao Huang,
Ben Hutchings
In-Reply-To: <f2279f2d-f0a6-a948-9691-96f47a0bd997@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]
On 2020-12-09 09:58, Topi Miettinen wrote:
> On 9.12.2020 2.42, Jarkko Sakkinen wrote:
>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>>> $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>>
>>>>>> It's no surprise that there aren't any executables in /dev since
>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>>> needed) and thus a potential location for constructing unapproved
>>>>>> executables if it is also mounted exec (W^X).
>>>>>
>>>>> UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
>>>>
>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
>>>> is not universal and the policies might not contain all users or services.
>>>>
>>>> -Topi
>>>
>>> What's the data that supports having noexec /dev anyway? With root
>>> access I can then just use something else like /dev/shm mount.
>>>
>>> Has there been out in the wild real world cases that noexec mount
>>> of would have prevented?
>>
>> Typo: "of" = "of /dev"
>>
>>> For me this sounds a lot just something that "feels more secure"
>>> without any measurable benefit. Can you prove me wrong?
>>
>> The debate is circled around something not well defined. Of course you
>> get theoretically more safe system when you decrease priviliges anywhere
>> in the system. Like you could start do grazy things with stuff that
>> unprivilged user has access, in order to prevent malware to elevate to
>> UID 0 in the first place.
>>
>> I think where this go intellectually wrong is that we are talking about
>> *default installation* of a distribution. That should have somewhat sane
>> common sense access control settings. For like a normal desktop user
>> noexec /dev will not do any possible favor.
>>
>> Then there is the case when you want to harden installation for an
>> application, let's' say some server. In that case you will anyway
>> fine-tune the security settings and go grazy enough with hardening.
>> When you tailor a server, it's a standard practice to enumerate and
>> adjust the mount points if needed.
>
> I think we agree that there's a need for either way to allow SGX (if default is hardened) or a hardening option (in the opposite case). For systemd I see two approaches:
>
> 1. Default noexec /dev, override with something like
> - ExecPaths=/dev
> - MountOptions=/dev:rw,exec,dev,nosuid
> - or even MountOptions=/dev/sgx:rw,exec,dev,nosuid
> - ProtectDev=no
> - AllowSGX=yes
>
> 2. Default exec /dev, override with
> - NoExecPaths=/dev
> - MountOptions=/dev:rw,noexec,dev,nosuid
> - ProtectDev=yes
> - DenySGX=yes
>
> I'd prefer 1. but of course 2. would be reasonable.
>
>> To summarize, I neither understand the intended target audience.
>
> We have something in common: me neither. What's the target audience for SGX? What's the use case? What are the users: browsers, system services? How would applications use SGX? Should udev rules for /dev/sgx make it available to any logged in users with uaccess tags?
Unless the system administrator/distribution has a specific reason to disable SGX, /dev/sgx_enclave it should be generally available to any user process (mode 0666). SGX just provides a different way for an application to execute code by using the ENCLU x86 instruction. Ultimately, any application author could decide to use SGX in its design, including browsers, system services, network services, etc.
The device doesn't really provide any I/O or other hardware access. Even when the device is in use by a process, the OS has full control over scheduling and resource management. The only reason it's a device in /dev is to be able to provide an fd for use with mmap so that it can setup memory ranges for use with the ENCLU instruction.
/dev/sgx_provision provides access to CPU hardware identifier and should be root/root 0600 to preserve privacy.
--
Jethro Beekman | Fortanix
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]
^ permalink raw reply
* Re: Creating executable device nodes in /dev?
From: Topi Miettinen @ 2020-12-09 8:58 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Andy Lutomirski, Andy Lutomirski,
Zbigniew Jędrzejewski-Szmek, linux-hotplug,
systemd Mailing List, Jarkko Sakkinen, Jethro Beekman,
Casey Schaufler, linux-sgx, Svahn, Kai, Schlobohm, Bruce,
Stephen Smalley, Haitao Huang, Ben Hutchings
In-Reply-To: <20201209004214.GA64820@kernel.org>
On 9.12.2020 2.42, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>>>>> As a further argument, I just did this on a Fedora system:
>>>>>> $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
>>>>>> No results. So making /dev noexec doesn't seem to have any benefit.
>>>>>
>>>>> It's no surprise that there aren't any executables in /dev since
>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>>>>> needed) and thus a potential location for constructing unapproved
>>>>> executables if it is also mounted exec (W^X).
>>>>
>>>> UID 0 can just change mount options, though, unless SELinux or similar is used. And SELinux can protect /dev just fine without noexec.
>>>
>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux
>>> is not universal and the policies might not contain all users or services.
>>>
>>> -Topi
>>
>> What's the data that supports having noexec /dev anyway? With root
>> access I can then just use something else like /dev/shm mount.
>>
>> Has there been out in the wild real world cases that noexec mount
>> of would have prevented?
>
> Typo: "of" = "of /dev"
>
>> For me this sounds a lot just something that "feels more secure"
>> without any measurable benefit. Can you prove me wrong?
>
> The debate is circled around something not well defined. Of course you
> get theoretically more safe system when you decrease priviliges anywhere
> in the system. Like you could start do grazy things with stuff that
> unprivilged user has access, in order to prevent malware to elevate to
> UID 0 in the first place.
>
> I think where this go intellectually wrong is that we are talking about
> *default installation* of a distribution. That should have somewhat sane
> common sense access control settings. For like a normal desktop user
> noexec /dev will not do any possible favor.
>
> Then there is the case when you want to harden installation for an
> application, let's' say some server. In that case you will anyway
> fine-tune the security settings and go grazy enough with hardening.
> When you tailor a server, it's a standard practice to enumerate and
> adjust the mount points if needed.
I think we agree that there's a need for either way to allow SGX (if
default is hardened) or a hardening option (in the opposite case). For
systemd I see two approaches:
1. Default noexec /dev, override with something like
- ExecPaths=/dev
- MountOptions=/dev:rw,exec,dev,nosuid
- or even MountOptions=/dev/sgx:rw,exec,dev,nosuid
- ProtectDev=no
- AllowSGX=yes
2. Default exec /dev, override with
- NoExecPaths=/dev
- MountOptions=/dev:rw,noexec,dev,nosuid
- ProtectDev=yes
- DenySGX=yes
I'd prefer 1. but of course 2. would be reasonable.
> To summarize, I neither understand the intended target audience.
We have something in common: me neither. What's the target audience for
SGX? What's the use case? What are the users: browsers, system services?
How would applications use SGX? Should udev rules for /dev/sgx make it
available to any logged in users with uaccess tags?
-Topi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox