On Sun, 07 Feb 2016 14:47:54 +0000, Rainer wrote in message
<87pow84lwl.fsf@???>:

> Arnt Karlsen <arnt@???> writes:
> > On Sun, 7 Feb 2016 10:42:04 +0000, Dave wrote in message
> > <56B71F7C.9060708@???>:
> >> My new Asus laptop is EFI.
> >> Running debian sid, no dual-booting or anything like that.
> >> and cat /proc/mounts has this:-
> >>
> >> efivarfs /sys/firmware/efi/efivars efivarfs
> >> rw,nosuid,nodev,noexec,relatime 0 0
> >>
> >> DaveT
> >
> > ..you missed:
> > /dev/sda1 /boot/efi vfat
>
> That's the EFI boot partition. Since that's a specfication written by
> hardware guys, EFI using global variables for inter-module
> communication and the FAT filesystem (and god-only-knows what other
> kinds of deficient 1980s technology --- edge-triggered interrupts,
> anyone?) shouldn't come as a surprise.

..right, so the key to your boot is in /dev/sda1 alias
/boot/efi, or in a chip on the board, or is it Facebook
style "complicated"?

> [...]
>
> > securityfs /sys/kernel/security securityfs
>
> FS-interface for configuring kernel 'security modules'.

..controlled by what???

..or by whom, the kernel guys or the systemd boys?

> [...]
>
> > pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
> > #..wtf _is_ this???
>
> 'Persistent storage fs' for storing kernel crashdump information such
> that it survives a reboot./

..sounds abuseable, e.g. "crashdump" a "suspend-image" and
kexec boot it to e.g. "edit" Ian Murdock's autopsy report?
Etc?

> > efivarfs /sys/firmware/efi/efivars
>
> [...]
>
> > #..you found this, wtf _is_ this???
>
> The filesystem providing access to the EFI variable service.
>
> > cgroup /sys/fs/cgroup/freezer cgroup
> > rw,nosuid,nodev,noexec,relatime,freezer 0 0
> > #..wtf _is_ this???
>
> [...]
>
> Altogoether, some bizarre 'control group filesystem' arrangement
> chosed by systemd. 'Control groups' (originally implemented by SGI)
> support putting processes in - well - control groups. This is
> (together with namespace support) the base for 'Linux containers'
> virtualization (another feature systemd usurped[*]).
>

> [*] Disclaimer: I'm getting paid to work on a product which uses this
>     technology such that it cannot possibly coexist with systemd. As
>     such I'm one of these morally repugnant closed-source developers
> and RedHat using money made from Linux for subsidizing Poettering et
> al breaking out stuff is obviously just what we deserve.

..good to know. ;o)

> > systemd-1 /proc/sys/fs/binfmt_misc autofs
> > rw,relatime,fd=23,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
> > #..wtf _is_ this, a new /proc root tree???
>
> Automounter filesystem.

..automounting everything behind the scenes?

> [...]
>
> > mqueue /dev/mqueue mqueue rw,relatime 0 0 /dev/sda4 /home ext4
> > rw,noatime,data=ordered 0 0
> > #..wtf _is_ this, systemd's sensoring your root's email???
>
> Pseudo-filesystem which is part of the POSIX message queue
> implementation.

...which can or cannot be used to censor root's etc email???
Etc?

..I used to help teach AA gunnery flying target "drones."
AA gunnery is done "leading the target", aiming ahead of
"where it is now" far enough so your ammo can make it into
your target and bring it down or scare it away.

..lots of guesswork involved in AA gunnery, some can be
guesstimated, and ofcourse you'll miss if you guess your
target's manouvering wrong, and ofcourse his ammo can hit
you pretty badly.
AFAICT, systemd is no different.


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.