April 2017 - Arch-general - lists.archlinux.org

[arch-general] Gnome crash
by Frank Zimmermann 29 Apr '17

29 Apr '17

Good evening, since yesterday my Gnome Shell crashes at start with the following message in the log: gnome-session-f[1207]: segfault at 0 ip 00007f01adab3cc9 sp 00007ffd261ce930 error 4 in libgtk-3.so.0.2200.6[7f01ad7d1000+6fa000] Is this a problem other Gnome users see as well? KR Frank

7 7

[arch-general] Arch Wiki Professional_audio
by Ralf Mardorf 28 Apr '17

28 Apr '17

Hi, the Wiki [ https://wiki.archlinux.org/index.php/Professional_audio ] opens with... "This article or section needs expansion." and a link to the discussion, but I still don't understand what actually is missing. ...followed by an unrealistic claim about grotesque low latency. The article included wrong information, I already removed "If you want to use any MIDI hardware you need to ensure the ALSA MIDI driver is loaded. You can set the MIDI driver to load at boot by creating the file /etc/modules-load.d/alsamidi.conf containing:" IIRC apart from a bug that caused that the driver wasn't loaded, the driver always gets loaded automatically. There are claims about rtc, 1000Hz. This was valid, but IMO should be obsolete now. Etc., pp. ... I don't want to rewrite the Wiki, especially because I won't and/or can't test every hint. Please contribute to the Wiki and/or to the "This and that" discussion [ https://wiki.archlinux.org/index.php/Talk:Professional_audio ]. Regards, Ralf

5 7

[arch-general] End of official PaX and grsecurity support in Arch Linux
by Daniel Micay 28 Apr '17

28 Apr '17

The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended: https://grsecurity.net/passing_the_baton.php https://grsecurity.net/passing_the_baton_faq.php I'll be clearing out the AUR packages for PaX and grsecurity soon since the current 4.10 patches are not accessible. Providing out-of-date packages with known vulnerabilities and without the current set of mitigations is infringing on how they want their trademarks used. If people want to maintain forks, either a 4.9 LTS or porting it forward to newer kernels, they'll need to make a new project with a new name rather than using "PaX" or "grsecurity" as the naming. If it's serious and done by people that know what they're doing, official support for it can be considered. There are few people that are capable of truly taking over maintenance of the whole patches and I expect that they won't have time to do it. Don't be optimistic about this happening. There are no viable alternatives to PaX and grsecurity. Their focus is on kernel self-protection i.e. protecting the kernel from exploits, and we don't have anything for users to migrate to from these. There are plenty of alternatives to grsecurity RBAC but that's only a small portion of what the patches provide. Any form of access control (whether it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely bypassed with a single kernel exploit, so the only good way to use other MAC implementations like TOMOYO, AppArmor or SELinux was with grsecurity. We don't actually provide official support for any of these alternatives, but it's all little good without a hardened kernel anyway. A small subset of the kernel self-protection features have landed upstream as part of the Kernel Self Protection Project. The core/linux package doesn't enable the bulk of these features, and it probably doesn't make sense for it to turn everything on because a subset of them do have a significant performance cost. It would be possible to provide a linux-hardened package doing that but it would only offer a tiny portion of the kernel self-protection that grsecurity does. I may end up doing that, along with enabling support for all of the LSMs, etc. there but it's really not at all comparable to what has been lost. The LSMs are also little good without people working on providing userspace integration and policies for them. There are no good answers here. It would be possible to maintain a fork of grsecurity, especially if all kernel architectures other than x86_64 (and arm64, but it's not currently supported) were dropped along with grsecurity RBAC and anything that has a proper equivalent upstream. i386 and armv7 can still be supported as userspace archs, since dropping them as kernel archs is what would save most of the maintainance work and would eliminate a bunch of complex code only currently fully understood by the PaX and grsecurity authors. It might also make sense to start dropping support for old CPUs, beyond just only supporting 64-bit kernels. Intel Broadwell and later provide SMAP and there's also SMEP, so those could be used as substitutes for UDEREF and that portion of the KERNEXEC feature. The problem is that there aren't capable people with the time and willingness to dedicate a huge amount of their time to a volunteer project without pay. I already maintain/develop hardened Android LTS kernels as a significant but overall quite small part of CopperheadOS. It's not comparable to this because it's my job. I spend far more than 40 hours a week on CopperheadOS, and it's actually quite a relief to not need to worry about maintaining PaX and grsecurity for Arch Linux anymore especially since I had to do it on my own. I've been aware that the test patches becoming private was a very real possibility even before spender started talking about it on IRC weeks ago, so it's really not a surprise.

3 6

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux
by Alexander Harrigan 27 Apr '17

27 Apr '17

It would be great if you can provide linux-hardened kernel with everything what KSPP has enabled by default. Even in AUR so you won't have to rebuild it constantly and random stack option would have more sense. Two questions: 1\. Do you think maintaining 4.9 lts grsec kernel would be doable until it gets EOL from upstream? Are there many incompatible changes with minor kernel releases? I heard gentoo (maybe debian?) are considering this. 2\. Why hidepid was removed? I saw "lack of time" comment but...there wasn't much to maintain as it worked flawles for long time. Thank you for your great effort in maintaining grsec for all that years. I'm looking forward to being your customer (Copperhead) when it will be avalaible overseas :) On On Thu, Apr 27, 2017 at 08:17 PM, Daniel Micay via arch-general <arch- general(a)archlinux.org> wrote: > On Thu, 2017-04-27 at 19:12 +0000, Carsten Mattner wrote: > > Is CopperheadOS using grsec or something derived from it? > > It starts from the baseline provided by Google and ports features from > PaX and grsecurity as needed to the kernels. It used to use a full PaX > port on ARM devices but that hasn't made sense for quite some time. > > Android is much a different target. CopperheadOS is starting from a base > system that's already quite hardened. PaX / grsecurity kernel self > protection features are applicable to Android but the bulk of them don't > support arm64 in grsecurity at the moment so it's no use beyond as a > source for porting / inspiration. The features that landed upstream > ended up being ported to arm64. The grsecurity test patches becoming > private has no impact on CopperheadOS. There's a significant indirect > impact in that the source of 95% of Linux kernel security research / > innovations is now no longer publicly available. KSPP no longer has an > incredible source to copy ideas and code from and neither do we. > > grsecurity RBAC and all but a few of the miscellaneous features aren't > relevant to Android. It already has the baseline per-user, per-app > uid/gid separation reinforced with a full system SELinux policy that's > far beyond what RHEL / Fedora provide, since there's a well-defined base > system (no system administrator choosing packages / configuration) and a > well-defined app sandbox for all third party code. Devices handle their > drivers and hardware-specific services/libraries via device-specific > policy extensions. For example, SELinux ioctl filtering is used for > kernel attack surface reduction by whitelisting ioctl commands per- > device including whitelisting only the set of GPU driver ioctl commands > used by the device in practice. They're also making increasingly good > use of seccomp-bpf. > > Even some of the most basic security features like full verified boot > for the whole OS and always enabled encryption are pipe dreams for > traditional distributions. Android's linker doesn't support non-PIE and > text relocations are only supported for legacy API level 32-bit apps. > Full RELRO, strong SSP and _FORTIFY_SOURCE=2 (beyond what glibc > provides) are globally enabled. > > The AOSP kernels are very minimal, i.e. no modules enabled and only a > small set of drivers, etc. needed for the platform. Features like System > V IPC and now AIO aren't enabled. Google already has KSPP features > backported and enabled in their LTS kernels like HARDENED_USERCOPY > (incomplete KSPP implementation of PaX USERCOPY), __ro_after_init > (incomplete KSPP implementation of PaX __read_only) and PAN (UDEREF > equivalent) emulation for ARM and ARMv8.0 where PAN isn't yet available. > They also have kernel security features that were rejected upstream like > perf_event_paranoid=3 which we upstreamed to AOSP. > > In addition to that much different starting point, CopperheadOS also has > full control of the entire base system. There's a unified build system > and all of the sources are in one tree like a *BSD OS. It's so much > different than trying to deal with bringing desktop Linux security on > par with 2008 security standards, which is still so far away as a goal. > One day perhaps flatpak / wayland will have caught up to providing a > basic security model for desktop Linux and some day Arch will finally > get PIE enabled by default but all of those kind of things are already > provided by the baseline OS that CopperheadOS starts from. \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

2 1

[arch-general] arch-audit didn't survive the openssl upgrade to 1.1.0
by Ricardo Band 27 Apr '17

27 Apr '17

Ahoi, arch-audit in version 0.1.8-2 still looks for openssl 1.0.0: arch-audit: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory After installing openssl-1.0 it works again. I see 2 solutions here. Update arch-audit to use OpenSSL 1.1 or add openssl-1.0 as a dependency to arch-audit package. -- Greetings Ricardo Band https:// www.ricardo.band mailto:// email(a)ricardo.band

3 2

[arch-general] Add new screen resolution in Wayland
by Mauricio Baeza 26 Apr '17

26 Apr '17

Hello everybody... I format mi PC, and install Wayland, Winston and Gnome, before I used Xorg, and add new resolution screen with xrandr xrandr --addmode HDMI-1 2560x1080_60.00 xrandr --output HDMI-1 --mode 2560x1080_60.00 now, with Wayland, xrandr not work, my card graphic is Nvidia and used driver nouveau my config weston is: name=XWAYLAND0 mode=230.00 2560 2720 2992 3424 1080 1083 1093 1120 -hsync +vsync I search in wiki, forum and www but any solution work for me. ¿Who to add new screen resolution in Wayland? Thanks in advance -- Todo lo que no es dado es perdido...

1 0

[arch-general] sysdig downgraded without adding a new era?
by Neven Sajko 25 Apr '17

25 Apr '17

Anybody else got a "warning: sysdig: local (0.15.1-1) is newer than community (0.15.0-2)" ?

4 5

[arch-general] Video output failure still
by pete nikolic 23 Apr '17

23 Apr '17

Still no joy with this video problem i can play all videos via Firefox no problem can not do TV via FF . Every application to play TV or a recorded film fails with the same report this started happening around 2 months ago but have not been able to pin down exactly which update caused the failure the system is fully updated every day . ### uname -a Linux ds9 4.10.11-1-ARCH #1 SMP PREEMPT Tue Apr 18 08:39:42 CEST 2017 x86_64 GNU/Linux ### lspci -v 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT 220] (rev a2) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 34d8 Flags: bus master, fast devsel, latency 0, IRQ 27, NUMA node 0 Memory at f9000000 (32-bit, non-prefetchable) [size=16M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at ce000000 (64-bit, prefetchable) [size=32M] I/O ports at d800 [size=128] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau ### lsmod |grep nouveau nouveau 1544192 12 led_class 16384 2 input_leds,nouveau mxm_wmi 16384 1 nouveau wmi 16384 2 mxm_wmi,nouveau video 36864 1 nouveau ttm 86016 1 nouveau drm_kms_helper 126976 1 nouveau drm 303104 15 nouveau,ttm,drm_kms_helper i2c_algo_bit 16384 3 cx88_vp3054_i2c,cx88xx,nouveau button 16384 1 nouveau ### dmesg |grep nouveau [ 13.222319] nouveau 0000:01:00.0: NVIDIA GT216 (0a5000a2) [ 13.358327] nouveau 0000:01:00.0: bios: version 70.16.39.00.0f [ 13.358663] nouveau 0000:01:00.0: bios: OOB 1 d7500086 d7500086 [ 13.358866] nouveau 0000:01:00.0: bios: OOB 1 b42800b3 b42800b3 [ 13.359058] nouveau 0000:01:00.0: bios: OOB 1 adb75814 adb75814 [ 13.359250] nouveau 0000:01:00.0: bios: OOB 1 adb75814 adb75814 [ 13.359439] nouveau 0000:01:00.0: bios: OOB 1 adb75814 adb75814 [ 13.360092] nouveau 0000:01:00.0: fb: 1024 MiB DDR2 [ 14.441658] nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB [ 14.441659] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 14.441664] nouveau 0000:01:00.0: DRM: TMDS table version 2.0 [ 14.441665] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 14.441667] nouveau 0000:01:00.0: DRM: DCB outp 00: 01000302 00020030 [ 14.441670] nouveau 0000:01:00.0: DRM: DCB outp 01: 02000300 00000000 [ 14.441671] nouveau 0000:01:00.0: DRM: DCB outp 02: 01032310 00000000 [ 14.441673] nouveau 0000:01:00.0: DRM: DCB outp 03: 02021362 00020010 [ 14.441674] nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030 [ 14.441675] nouveau 0000:01:00.0: DRM: DCB conn 01: 00002161 [ 14.441676] nouveau 0000:01:00.0: DRM: DCB conn 02: 00000200 [ 14.444620] nouveau 0000:01:00.0: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [ 14.464244] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies [ 14.524032] nouveau 0000:01:00.0: DRM: allocated 1280x1024 fb: 0x70000, bo ffff880130211400 [ 14.524777] fbcon: nouveaufb (fb0) is primary device [ 14.681857] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device [ 14.694858] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0 ### dmesg |grep vga [ 0.637534] pci 0000:01:00.0: vgaarb: setting as boot VGA device [ 0.637536] pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [ 0.637538] pci 0000:01:00.0: vgaarb: bridge control possible [ 0.637538] vgaarb: loaded Running kaffeine from a terminal calling tv sound ok no video [00007f8fa4001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f8fa4001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f8fa4001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. same again but trying to play a video stored on the system [00007f1598001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f1598001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f1598001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f1598001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. [00007f1598001268] vdpau_display vout display error: output surface creation failure: A catch-all error, used when no other error code applies. with exactly the same respomse from VLC as well this has now been in this brain dead state for a couple of months the system is updated daily with pacman -Syu Help needed to get this problem flattened . Hope someone can spot the problem or if not what more info do you need . Thanks Pete .

3 4

[arch-general] arch health
by fnodeuser 23 Apr '17

23 Apr '17

ITwrx.org, health? AL is not an organism, it is an OS. what you meant to say is problems. yes, it is true. there are a few problems, but these problems were not caused by a lack of funds. these are the reasons there are problems: 1. there are a few AL TMs (team members), that wanted to become, became, and still are AL TMs because they are selfish. these TMs are here, because they want to indirectly benefit financially from this membership, and/or for the 'bragging rights', and/or because they want to continue to have the 'power' that an AL TM has. the rest of the TMs are here because they care about AL, the community, and progress. 2. both groups of AL TMs have different workloads and not always a lot of free time. changes in circumstances can and will determine how much work must be done and how much free time a TM has to do AL work. 3. ignorance and/or stupidity. now, the good thing is that these problems have solutions. one of the things we can do to help solve these problems (and make their workloads smaller), is with user sign-offs.[1] this way, Tobias Powalowski, for example, will stop placing the linux pkg in testing for stable minor releases. _ [1] https://lists.archlinux.org/pipermail/arch-general/2016-June/041510.html

2 1

[arch-general] arch health
by ITwrx.org 22 Apr '17

22 Apr '17

i'm a little concerned about arch's overall health and i was wondering if there's anything we can do about it. why am i concerned? Many users tested to demonstrate that PIE would not cause an undue performance burden but it has still not been implemented due to dev's lack of time. Now said dev is also resigning from packaging due to it becoming a chore. Is PIE on the menu of the adopter of those packages? There are also many official packages that have been out of date for a while. At least one of the devs seems to have too many packages to maintain. Probably because packages were orphaned and someone had to pick up the slack. There are probably many packages in aur that should be moved to official if there were devs who had time to deal with them. There are probably some bugs that need to be fixed too. Maybe we can use some % of donations to pay a dev/devs? Can we modernize the donations system? I sent a message to SPI's web dev email asking about improvements to project's pages but i haven't heard back. IMHO, a general donate method doesn't cut it. Crowd funding should demonstrate clearly that people will donate much more when they have input and can see goals, progress, etc. Donors and devs should be able to designate goals (devs could have approval/veto power) and/or donors should be able to donate towards approved goals. It would be nice if we could fund developers or maybe just a rewards pool where devs get some appreciation money each month. Crypto currency could be an option. Devs could choose what they want to receive. If nothing else, maybe we could crypto tip individually or to an Arch address. Some way to make arch development more practical for people. I know in the past arch devs have said roughly that "he who does the dev makes the decisions" but maybe us users can buy our way in just enough to influence the speed or goals of the distro's dev? It doesn't seem like the current state of things can keep up with threats, new features, etc. I think i am not alone in being willing to pitch in money, when i can, to make it easier or more worthwhile for devs, new or current. At least we could see what the current funding levels for goals were so we would know if more needs to be done. Some other distros have large corps that can foot the bill to get things done. I'm sure Arch could use some help too, even if we already have donation funds for infrastructure needs. thanks -- Information Technology Works https://ITwrx.org @ITwrxorg

16 35