- luv-main - luv.asn.au

Re: [luv-main] Microsoft requires Windows 8 logo systems to not bootunsigned OS's
by Jason White 23 Sep '11

23 Sep '11

Daniel Pittman <daniel(a)rimspace.net> wrote: > There was recently announced a root-kit that would infest Award BIOS > implementations: > http://www.symantec.com/security_response/writeup.jsp?docid=2011-090609-455… > > So, fairly high risk for the next little while, until vendors do > something to harden against firmware updates? Short of disallowing them at all, or requiring signed firmware, it isn't clear what could be done. Obviously, the attacker needs a local root exploit (or whatever the Microsoft equivalent is) in order to modify the firmware, but I agree that having a root kit in the firmware would be a very bad position to occupy. > So, the biggest advantage is that it does work against all those > attacks that compromise the kernel and/or drivers to get into the > kernel after a restart. Which, indeed, is where many of the "root > kit" tools hit, on Windows. That's interesting... and the proposed solution just happens to be the one which also has potential to disadvantage competitors...

1 0

Re: [luv-main] Microsoft requires Windows 8 logo systems to not bootunsigned OS's
by Jason White 23 Sep '11

23 Sep '11

Daniel Pittman <daniel(a)rimspace.net> wrote: > More so, even, if Microsoft are not responsible for the restriction – > if they specify that their key, or the OEM key, need to be present to > run Windows, but do not restrict other keys being included. > > ...and I suspect that the vendors, also, will not be on the hook here: > there are plenty of other hardware vendors, and their choice not to > support Linux will not be substantially different to their choice not > to support ARM operating systems: a business decision, allowing their > competition to "take" that market share. I'd be worried if most vendors were to take that option, however. In general, consumer systems are becoming increasingly locked-down (phones, tablets, now laptops and desktops too). Obviously, the freedom to run whatever kernel you want, including one compiled by you, is fundamental to Linux usage and development, hence it is vital to protect. > > Personally, I would be finding a tame SuperMicro vendor in the region, > who are extremely unlikely to stop selling Linux compatible systems, > what with their business market using it and all. We do need vendors who are committed to Linux, in addition to pursuing whatever can be gained through competition law. To play my part, I always choose hardware whenever I can for which the vendor claims Linux support (after doing the proper checking to ensure that it really is likely to work reliably). For example, my desktop machine is a workstation product certified to run Red Hat. I'm actually running Debian on it, but at least it is hardware that could be bought with Linux pre-installed. I think the people who are more likely to be affected by Microsoft's strategy, in the short term, are those running Windows who want to switch to Linux on their existing hardware, as well as Linux users who buy Windows machines for the purpose of installing Linux. Laptops would be particularly problematic.

2 2

Microsoft requires Windows 8 logo systems to not boot unsigned OS's
by Chris Samuel 22 Sep '11

22 Sep '11

[Apologies to those who've got multiple copies of this] This looks like something to keep an eye on.. Matthew Garrett (the guy who makes peoples laptops work with Linux and has to deal with EFI & Linux - makes you wonder what awful thing he did in a past life) writes about a worrying requirement for Windows 8 logo certification for hardware vendors.. http://mjg59.dreamwidth.org/5552.html # Microsoft requires that machines conforming to the # Windows 8 logo program and running a client version # of Windows 8 ship with secure boot enabled. The two # alternatives here are for Windows to be signed with # a Microsoft key and for the public part of that key # to be included with all systems, or alternatively for # each OEM to include their own key and sign the # pre-installed versions of Windows. The second approach # would make it impossible to run boxed copies of Windows # on Windows logo hardware, and also impossible to install # new versions of Windows unless your OEM provided a new # signed copy. The former seems more likely. # # A system that ships with only OEM and Microsoft keys will # not boot a generic copy of Linux. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

7 8

Keyboard lagging in X
by Tim Connors 22 Sep '11

22 Sep '11

I have a USB-serial cable connecting my laptop (running 2.6.39 from Debian) to a weather station. My keyboard is connected to a different USB port on the laptop. Whenever the met software is reading and/or writing to the serial port (I haven't yet debugged whether it only happens during read or write), the keyboard badly lags when in X, but not at the console. I don't *think* the mouse is affected, most of the time, unless X is waiting for the keyboard to catch up. I'm apparently using the evdev driver. In xorg.conf, synaptics is configured for the mouse, talking on /dev/psaux, and not as core pointer. corekeyboard and coremouse are left as default. So now, given the bloat (sorry, abstraction) that has been thrown at X/HAL/udev over the last few years, where do I start debugging this one? (friggin give me back XFree86 and a keyboard driver understood by more than 3 people on the damn planet!). Can anyone else reproduce this? You probably don't need a USB-serial converter. It's probably just some conflict reading things from /dev/input/* or in the kernel TTY layer or something, and so any old serial connection busily talking will do it. I think this is only a recent occurence. Being my main desktop, I'm not ready to git bisect it yet, and don't know whether 2.6.39 brought this behaviour in. It could have been back in April: [UPGRADE] xserver-xorg 1:7.6~2 -> 1:7.6+6 [UPGRADE] xserver-xorg-core 2:1.7.7-11 -> 2:1.9.5-1 [UPGRADE] xserver-xorg-input-evdev 1:2.6.0-1 -> 1:2.6.0-2 [UPGRADE] xserver-xorg-input-kbd 1:1.4.0-2 -> 1:1.6.0-1 (god knows why I upgraded. Oh yeah, squeeze. I should have learnt by now). -- Tim Connors

3 9

tcpdump catch incorrect checksum
by James Harper 21 Sep '11

21 Sep '11

Does anyone know how to make a rule for tcpdump to catch only packets with a bad checksum? A google search on such things is full of noise from people who don't understand tcp checksum offload... Thanks James

2 1

Re: [luv-main] SELinux
by Andrew Spiers 20 Sep '11

20 Sep '11

Thanks for the advice. It turns out that the red hat documentation itself wasn't too bad, and our teacher was pretty good, for the limited scope of selinux things we were required to know for the exam. I've got a question though: I installed Adobe's Flash plugin, and the file now looks like this: -rwxr-xr-x. root root unconfined_u:object_r:lib_t:s0 libflashplayer.so object_r and lib_t both match other libraries in the same directory, so I think those are right. Everything else says 'system_u' in that directory, which I think means that system users are meant to be able to access it. And I think I've got unconfined_u in there because I created the file as root. Is there a semanage command to set which users can access this file? I can't figure it out from the man page.

3 4

Luv mailing list domains
by Jason White 20 Sep '11

20 Sep '11

I just realized (too late, unfortunately) that Mutt's reply to list feature is now generating a "To" field like this: luv-main(a)lists.luv.asn.au, luv-main(a)luv.asn.au I think the cause may be this header in messages distributed via the list: List-Post: <mailto:luv-main@lists.luv.asn.au> whereas the "To" header gives luv-main(a)luv.asn.au as the address. Would it be possible for our hard-working and diligent administrators to get rid of the lists.luv.asn.au domain in the headers? I don't know enough about mailman configuration to appreciate how much work this would require. I might be able to work around this in my Mutt configuration, but I think it's best fixed at the source, if possible.

2 1

Re: [luv-main] Bought a laptop with optimus, doesn't work (nice false advertising nvidia). Now wanting to murder nvidia via Open Letter.
by Jeremy Lunn 19 Sep '11

19 Sep '11

On 12/09/2011, at 6:50 PM, Trent W. Buck wrote: >> this has to be illegal. > > Under what law? Depending on the claims being made (and perhaps where/how), it could be a form of misleading or deceptive conduct under the Competition and Consumer Act 2010 (formerly Trade Practices Act 1974). There is a bit of info here on misleading and deceptive conduct under Australian consumer law at: http://www.accc.gov.au/content/index.phtml/itemId/815335 Jeremy

1 0

Default grub options for RHEL6 ?
by Chris Samuel 19 Sep '11

19 Sep '11

Hi folks, Anyone know what the default grub options you get on a RHEL6 box are ? Do they include acpi=off ? If so, is that conditional upon something that Anaconda/kickstart detects ? Or something that must be explicitly selected ? (Got a friend in the US who has found a box with acpi=off set, which is bad for NUMA hardware if the kernel is relying on ACPI to get that info). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP

3 3

PostgreSQL benchmarked on XFS vs ZFS vs btrfs vs ext4
by Toby Corkindale 18 Sep '11

18 Sep '11

Resending this now the LUV list seems to be back up, as I never saw it come through yesterday. Apologies if this is a duplicate. -------- Original Message -------- Hi, Some months ago, I ran some (probably naive) benchmarks looking at how pgbench performed on an identical system with differing filesystems and mount options. Since then some of you have pointed out that ZFS is looking pretty good on Linux now, and I'm sure there's been a bunch of btrfs fixes too, and no doubt various updates in the Linux kernel and PostgreSQL that should help performance. I ran the tests on Ubuntu 11.04 with Pg 9.0 first, then upgraded the system to Ubuntu 11.10 (beta) with Pg 9.1 and ran them again. The latter combination showed a considerable performance improvement overall - although I didn't investigate to find out whether this was due to kernel improvements, postgres improvements, or virtio improvements. The results are measured in transactions-per-second, with higher numbers being better. Results: ext4 (data=writeback,relatime): natty: 248 oneiric: 297 ext4 (data=writeback,relatime,nobarrier): natty: didn't test oneiric: 1409 XFS (relatime): natty: didn't test oneiric: 171 btrfs (relatime): natty: 61.5 oneiric: 91 btrfs (relatime,nodatacow): natty: didn't test oneiric: 128 ZFS (defaults): natty: 171 oneiric: 996 Conclusion: Last time I ran these tests, xfs and ext4 pulled very similar results, and both were miles ahead of btrfs. This time around, ext4 has managed to get a significantly faster result than xfs. However we have a new contender - ZFS performed *extremely* well on the latest Ubuntu setup - achieving triple the performance of regular ext4! I'm not sure how it achieved this, and whether we're losing some kind of data protection (eg. like the "barrier" options in XFS and ext4). If ext4 has barriers disabled, it surpasses even ZFSs high score. Perhaps some of you can shed some light on this for me? Oddly, ZFS performed wildly differently on ubuntu 11.04 vs 11.10b. I can't explain this, as the ZFS kernel module was identical (coming from a third-party apt repository). Any ideas? Cheers, Toby

5 13