Slashdot Mirror

I think you missed my point, which was that yes, you could do exactly what you're suggesting, but it would be just as easy to do that at any router along your data's path to its destination. As soon as the data leaves your intranet, it's like sending a postcard.

But your router is an integral part of your intranet. With a little more paranoia, I can imagine a router doing vulnerability scans, or proxying a device with more memory that can do the vulnerability scans, and giving some third-party access to your computing devices. Systems are often set up to share a lot on the local network, for convenience and because the intranet is considered to be "safe." If you don't want to be in a position to trust your router, then you really should consider your security boundary to be your computer, and distrust anything that leaves or enters your NIC.

Which really is not that bad of an idea. "Hard and crunchy on the outside; soft and chewy on the inside" is how some people describe networks where they trust the firewall. Now that sort of attitude is especially useful for an environment with BYOD and APT; most recently, Google is famously structuring their network so they don't have to trust their intranets.

Just because there are many threats, doesn't mean you should bring untrustworthy devices onto your own premises. You should do defense in depth.

You can run it in the cloud too. You'll have the same/similar latency problems as with "native" could storage. If your storage is distributed across different AZ's, latency will be worse. Depends on your provider too. Jeff Darcy gave a talk about this at LISA:
https://www.usenix.org/conference/lisa13/storage-performance-testing-cloud

GlusterFS has proper, geo-replication which is becoming much better and HA in 3.5 (coming soon).

Cheers!

I was hoping someone would mention James Mickens' epic rant.

This is very similar to the Pico concept that Frank Stajano came up with a couple of years ago - though his is rather more complete than Steve Gibson's.

You can see Frank's (entertaining) talk from the 2011 Usenix security conference here:

https://www.usenix.org/conference/usenix-security-11/pico-no-more-passwords

There's a team at Cambridge University implementing this right now, and, like Gibson, Stajano has always pledged that it will be an open and patent-free standard.

You'll be more let down when you read that Windows leaks so much info that the binaries are only part of the problem:
http://www.usenix.org/event/hotsec08/tech/full_papers/czeskis/czeskis_html/

Can you show some examples of Microsoft research?

Pick any top-tier CS conference. They'll probably have something there.

For example, OSDI '12 (MSR personnel on 5 papers, 2 of which all coauthors worked at MSR), PLDI 2012 (MSR personnel on 6 papers), SIGGRAPH 2013 (harder to sort through, but I count 16 papers with at least one MSR co-author), VLDB 2011 (8 research papers as well as several other things like demos, a keynote, an industrial paper, and a 10-year-retrospective best paper award), STOC 2013 (16 papers if I counted right!), etc.

Seriously, I was not being choosy with those conferences -- the only choosy things I did was pick years for which there was an obvious page that listed the institutions with the authors instead of just the authors (e.g. VLDB 2013) because I'm lazy. If you pick a conference that covers a topic of interest, MSR has had something there. :-)

Out of 15 SSD tested, only 2 are failure proof under power fault (only one maker and model).
(yes, I've read the pdf)

I'd like to know who is the winner, the anonymous vendor/model called "A-2".
It is not the most expensive, almost the cheapest, but it has at least a power-loss protection.
Another vendor has power-loss protection but his models failed the tests.

Direct link to pdf and figures erratum.

Bit Corruption: SSD#11, SSD#12, SSD#15
Flying Writes: none
ShornWrites: SSD#5, SSD#14, SSD#15
UnserializableWrites: SSD#2, SSD#4, SSD#7, SSD#8, SSD#9, SSD#11, SSD#12, SSD#13, HDD#1
Metadata Corruption: SSD#3
Dead Device: SSD#1
No failure: SSD#6, SSD#10, HDD#2

Their last word conclusion :

We recommend system builders either not use SSDs for important information that needs to be durable or that they test their actual SSD models carefully under actual power failures beforehand. Failure to do so risks massive data loss.

Thanks again for this link to the Usenix study, too bad you posted anon (patent need mod up).

Out of 15 SSD tested, only 2 are failure proof under power fault (only one maker and model).
(yes, I've read the pdf)

I'd like to know who is the winner, the anonymous vendor/model called "A-2".
It is not the most expensive, almost the cheapest, but it has at least a power-loss protection.
Another vendor has power-loss protection but his models failed the tests.

Direct link to pdf and figures erratum.

Bit Corruption: SSD#11, SSD#12, SSD#15
Flying Writes: none
ShornWrites: SSD#5, SSD#14, SSD#15
UnserializableWrites: SSD#2, SSD#4, SSD#7, SSD#8, SSD#9, SSD#11, SSD#12, SSD#13, HDD#1
Metadata Corruption: SSD#3
Dead Device: SSD#1
No failure: SSD#6, SSD#10, HDD#2

Their last word conclusion :

We recommend system builders either not use SSDs for important information that needs to be durable or that they test their actual SSD models carefully under actual power failures beforehand. Failure to do so risks massive data loss.

Thanks again for this link to the Usenix study, too bad you posted anon (patent need mod up).

See also this paper/presentation: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf https://www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault

See also this paper/presentation: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf https://www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault

One time pads are unbreakable if used properly.

For that you need a good random noise generator (that has not been corrupted by someone), a way to distribute the key material and relatively trivial amount of code. (XOR may be good enough.)

I don't know what is being used recently for random noise. I might want the key generator to be a dedicated hardware box with a couple of storage devices plugged into it, though for a start, a program to run on PCs might be ok.

One problem is key management. You want to delete the used part of the key store, both so you don't reuse it and to keep it from falling into the wrong hands. The obvious way would be to make up USB sticks with files of key material and delete/overwrite the used file blocks. The problem is that secure erasing of files on a USB stick is hard to do.

http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_peril/
http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf

For casual use for unimportant matters, it might be ok. A more secure method would be to put the key files on a hard drive and use multiple overwrites to erase the used key material.

Eventually someone might make dedicated read once sticks with automatic erasure. Then you would only have to worry about physical security.

Presentation slides (view online or download PDF), and links to the paper (PDF) and "dedrop" source code (GitHub):
http://www.openwall.com/presentations/WOOT13-Security-Analysis-of-Dropbox/

USENIX WOOT '13 web page dedicated to this talk, including video and audio (view/listen online or download the video .mp4 via a direct link from there):
https://www.usenix.org/looking-inside-drop-box

(Somehow the Slashdot story only links to a third-party article and to the paper PDF, but not to any of the authors' and the conference's web-based content.)

This only worked with iOS 5

Some items only worked in iOS 5.

Based on Table 1 from their paper here, the following items could be accomplished by their app on iOS 6:
- posting tweets
- using the camera
- dialing
- using bluetooth
- crashing safari
- stealing device

It was only sending SMS messages, sending email, and rebooting the system that were limited to iOS 5.

Extraordinary claims, like a complete breaking of the sandbox, require more proof than they have presented.

No, they do not. Their claims require more proof than the reporter presented in the article.

The researchers wrote a fairly in-depth paper on the attack which can be read here

In the case of tweets, they make use of "private API's" to avoid notifying the user:

the public API called by the app will present a tweet view to the user, and let the user decide whether to post it or not, as shown in Figure 9. However, we find that the tweet view in Figure 9 can be bypassed by using private APIs, i.e., ourapp can post tweets without the user’s knowledge. Next,we describe how we discover the private APIs needed for achieving this goal

Their POC app apparently performs the exact malicious tasks they indicate all without user notification.

Only a moron would believe that.

Check your facts:
http://en.wikipedia.org/wiki/Tor_(anonymity_network)#History
https://www.usenix.org/legacy/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html

Why do you think almost 2/3rds of all TOR sited portal to the net in Virginia?

If you follow the phrase "Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobiliser" you get:

That link I didn't post, it comes with the copy and paste kinda neat, kinda freaky. A self writing copy and paste so I don't get it wrong.

Enamored so by the self writing javascript I posted the wrong address
https://www.usenix.org/conference/usenixsecurity13/session/attacks and what this ruling blocks.

This is already reality. So called "red pills" allow malware to find out if its are running in an emulator or virtual machine.

Here's a paper that describes automatically generating such red pills:

"A fistful of red-pills: how to automatically generate procedures to detect cpu emulators" by R. Paleari, L. Martignoni, G. F. Roglia, and D. Bruschi
https://www.usenix.org/legacy/event/woot09/tech/full_papers/paleari.pdf

The authors found more than 23k red-pills to detect QEMU and/or BOCHS.

At the USENIX "Hot Topics in System Dependability 2012" conference Gerard Holzmann of JPL labs gave a fantastic talk about how they developed the software for the Curiosity rover. (spoiler: Having to display a Bieber poster in your cubical if break the nightly build, is a great motivator.)

And where is the problem with that? People have no idea what security is and how all pieces of it are implemented, however they are told by banks (for example) that they must have the 'https' connection (or the secure icon) and if it's not there, then they shouldn't use it.

User studies have shown that users don't pay attention to HTTPS warning messages or to the secure icon (e.g., https://www.usenix.org/legacy/event/sec09/tech/full_papers/sunshine.pdf).

Worse, how is the user supposed to know whether to check for the icon?! If you're going to bank.com it's reasonable to assume that HTTPS should be used. What about other websites? You know, the kind that the govt would actually be interested in intercepting traffic to. There would be no way to know if HTTPS _should_ be present if the attacker performs a mitm to replace the CA-signed cert with a self-signed one. With the current system the user at least receives the self-signed warning page.

Jon gave a talk at LISA a couple of years ago about this same project:

https://www.usenix.org/conference/lisa11/project-cau%C3%A3

Well, it's definitely for nerds, but the Tesselation paper was published in 2009, so hardly news. For those that don't have ACM DL access, the paper is interesting, but suffers from many of the same problems as LibOS / Exokernel approaches.

It's not the users you should be worried about, it's the developers:
https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be
https://www.youtube.com/watch?v=RHIkb9yEV1k&list=PLOcrXzpA0W81zc6BiXpwEBx14w9nmtG2r&index=49

If you're looking for inexpensive and simple, you should consider Google's Ganeti.

Google uses it pretty heavily in their offices. It's simple to manage (command-line) and has some unique features, like being based on DRBD so it uses local storage and doesn't need anything like a SAN, and reads (but not writes) going as fast as local storage, rather than bottlenecked by the interconnect you're using.

See the interesting hour-long speech about how they're using it, available in MP4 and WebM:

https://www.usenix.org/conference/lisa12/ganeti-your-private-virtualization-cloud-way-google-does-it

Or just the PDF of the slideshow: http://whatexit.org/tal/PICC12/Ganeti-90.pdf

Unless it's an SSD drive, in which case you will end up with about 1% of data still left on the drive. For a terabyte drive, that's 10 gigs of your favorite home movies, on eBay: http://static.usenix.org/events/fast11/tech/full_papers/Wei.pdf

Name two.

1. Martinovich I., Perito, D., et al.
2. House, P., Greger, B.

Notes:
- these are only two papers that made it into the public media in recent times
- it is a very conservative estimation to assume that each one of them involved the work of tens of peoples
- it is also safe to assume that there are many others that are still "pushing the boundaries of Knowledge" on the matter but are not enough "media-chewable" so they never reach the notoriously sloppy AC's attention

I would suggest to anyone who thinks that USENIX conferences are solely for graybeards who walk around wearing suspenders, flipping nickels at people, then you should take a few minutes to read through the training program from LISA12. Not only is there the old standard Linux stuff, there are also great classes on building AWS infrastructures, cloudstack, PowerShell, and tons more. It's really pretty great.

I respectfully disagree. I've been to four LISA conferences (sysadmin conference run by USENIX) since 2006, and I see very little that is comparable; there are the various LOPSA conferences (LOPSA-EAST, Cascadia IT Conference), but they're simply not at LISA's scale. Want to hang out with a thousand other sysadmins? Get training from Ted T'so on recovering borked disks? See what Google is up to -- or the small IT shop at the university down the coast with 1/20000th the budget? There's simply nothing else out there that matches it.

As for the rest of the conferences, all I know is the summaries I've read in ;login: and the material that I've watched/listened to on their website. (And btw, HUGE kudos to USENIX to opening access to their proceedings, talks and papers.) But at the very least, they make damned interesting reading, and have made me very curious about things that are going on outside my narrow focus.

I don't have the breadth of experience you do; I concentrate on system administration because I love it, and I've been doing it less than ten years. I'm definitely an interested amateur (at best) when it comes to topics like security, or file systems, or OS design. But I'm always surprised how much of USENIX conference material touches on areas of interest or direct relevance to me, and at the very least browsing their papers is a wonderful introduction to some research and work I'd miss otherwise. I'm sure (with the exception of LISA) there are more focused conferences, or better known ones (DefCon is one that springs to mind). But I can't agree that USENIX is "past its sell date".

(And in passing, thanks very kindly for all the work you've done for the Open Source/Free Software community. Kinda boggles my mind that I'm debating you...)

What we really need is a formal standard based on end-to-end auditable voting. Some really outstanding work has been done in this space in the last couple of decades, applying the principles of cryptographic security to design and implement voting schemes that are provably secure and still provably anonymous while still eminently practical. These schemes, like Punchscan, Scantegrity and Scantegrity II allow voters to prove to themselves that their ballot was not only not modified or lost, but even that it was counted correctly -- but without giving them the ability to prove that to anyone else (to avoid vote coercion/buying). The systems can be automated for efficiency without losing their fundamental character and are designed to be 100% auditable and verifiable. Well, to be precise, they can be audited and verified to any desired degree.

http://en.wikipedia.org/wiki/End-to-end_auditable_voting_systems

http://static.usenix.org/event/evt08/tech/full_papers/chaum/chaum.pdf

http://www.economist.com/node/12455414?story_id=12455414

It's mildly amusing that Windows 8 is the first version to gain dynamic ticks, something Linux has had working since around 2007.

Windows CE and PocketPC has had dynamic ticks far longer actually - it was a BSP option you could have. The scheduler supported it (it told you how long to idle, you told it how long you actually idled (so your interrupts had to determine the time idled).

OS X has supported dynamic ticks for god knows since when - I think pratically from the beginning. It was immune to the CPU time-cheating attack as a side effect. (It uses one-shot hardware timers, but it's still ticking based on that more so than a regular periodic tick).

Though, technically, we can say Microsoft is learning all over again techniques it had already used before. It's just that Windows CE and PocketPC ended up being the red-headed stepchild - never being accepted because Microsoft was more concerned about its mainline Windows and Office products

Here's how: Helios: Web-based Open-Audit Voting

Jeremy Hansen

Network Cards & PCI Cards Firmware: No protection or detection of rootkits / malware, & AMD CPU issue

# Designing and implementing malicious hardware

"Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one speciïc attack, can instead design hardware to support attacks. Such flexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware. We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well. Malicious processors are more practical, more ïexible, and harder to detect than an initial analysis would suggest."

https://db.usenix.org/event/leet08/tech/full_papers/king/king_html/

# Attacking network cards

"I've reached my goal of writing a totally transparent firewall bypass engine for those firewalls which are PC-based: you simply overwrite the firmware in both NICs and then perform PCI-to-PCI transfers between the two cards for suitably formatted IP packets (modern NICs have IP "offload engines" in hardware and therefore can trigger on incoming and outgoing packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools, amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of course obvious as none of them check PCI-to-PCI transfers. "

https://lwn.net/Articles/284162/
http://www.links.org/?p=330

# 'Super-secret' debugger discovered in AMD CPUs
# Password-protected feature goes beyond x86

http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/

# Super-secret debug capabilities of AMD processors !

http://www.woodmann.com/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_!

# Hidden Debug Mode Found In AMD Processors

http://hardware.slashdot.org/story/10/11/12/047243/Hidden-Debug-Mode-Found-In-AMD-Processors

# A microcode reliability update is available that improves the reliability of systems that use Intel processors

http://support.microsoft.com/kb/936357

# Google: attacking network cards malware, PCI rootkit, PCI rootkits, rootkit firmware, etc.

Network Cards & PCI Cards Firmware: No protection or detection of rootkits / malware, & AMD CPU issue

# Designing and implementing malicious hardware

"Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one speciïc attack, can instead design hardware to support attacks. Such ïexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware. We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well. Malicious processors are more practical, more ïexible, and harder to detect than an initial analysis would suggest."

https://db.usenix.org/event/leet08/tech/full_papers/king/king_html/

# Attacking network cards

"I've reached my goal of writing a totally transparent firewall bypass engine for those firewalls which are PC-based: you simply overwrite the firmware in both NICs and then perform PCI-to-PCI transfers between the two cards for suitably formatted IP packets (modern NICs have IP "offload engines" in hardware and therefore can trigger on incoming and outgoing packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools, amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of course obvious as none of them check PCI-to-PCI transfers. "

https://lwn.net/Articles/284162/
http://www.links.org/?p=330

# 'Super-secret' debugger discovered in AMD CPUs
# Password-protected feature goes beyond x86

http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/

# Super-secret debug capabilities of AMD processors !

http://www.woodmann.com/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_!

# Hidden Debug Mode Found In AMD Processors

http://hardware.slashdot.org/story/10/11/12/047243/Hidden-Debug-Mode-Found-In-AMD-Processors

# A microcode reliability update is available that improves the reliability of systems that use Intel processors

http://support.microsoft.com/kb/936357

# Google: attacking network cards malware, PCI rootkit, PCI rootkits, rootkit firmware, etc.

writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many .

An interesting comment, but not the focus of the linked article.

Its not about the size of applications. Large reads into memory of big applications is not the problem, as this happens with sequential reads, which are very fast on the media type they were looking at.

Its the small RANDOM read/write units that cause the problem, the small sqlite database updates to databases stored on the MicroSD card that are the problem.
The recommendations for placing often used sqlite databases in RAMdisk yielded a tremendous performance increase because it eliminates tons of little random read and write operations that tend to be scattered all over the microSD card. This is buried in page 10 of the Actual Research document, but pretty much glossed over in the linked article. This would require a bit of an OS re-engineering, on the part of smartphone OS designers, such as offering APIs to do much of the routine data storage that these apps all end up using. That storage would be in ram, backed up to MicroSD in a more efficient manor.

Programmers tend to heavily use the general-purpose
“all-synchronous” SQLite interface for its ease of use but
end up suffering from performance shortcomings. We
posit that a data-oriented I/O interface would be one that
enables the programmer to specify the I/O requirements
n terms of its reliability, consistency, and the property of
he data, i.e., temporary, permanent, or cache data, with-
out worrying about how its stored underneath.

Yes, ramdisk can go away on a un-planned phone reboot, but if the RAMdisk was used as a cache, and occasionally written to disk performance would be much better, because you find these little sqlite databases used all over Android and IOS.

I'd much rather the link layer provided no security than broken security like Bluetooth. If the link layer provides no security, higher layers will provide their own. If the link layer provides an illusion of security, higher layers might make the mistake of trusting it.

I'm sure 'itwbennett' would rather everyone go to his employer's website to read that article, but it is clearly not written (or edited) by anyone who has any basic clues about spam-fighting. Just reading the subtitle makes me cringe for the unfortunate "journalists" lassoed into writing it, as it was clearly done by spam neophytes in a desperate scramble for click-scrounging content. The article is vaguely about a paper presented almost a year ago at LISA '11. There are links to an abstract and the original paper at the LISA '11 site: http://www.usenix.org/events/lisa11/tech/

The general space of sniffing out spam by looking at TCP characteristics has been mined for years usefully with Symantec and MailChannels both offering proprietary tools that use such techniques and some open DNSBL's using TCP sniffing to identify sources, but it would be incorrect to believe that any one methodology will ever be a magical silver bullet against spam.

@ http://www.usenix.org/publications/multimedia/ and http://www.youtube.com/user/USENIXAssociation?feature=watch

I'm doubting this story.

Admittingly, the following two clues as to who the author(s) of Conficker are, are circumstantial, but i would like to offer them to you guys for consideration since this behavior from Conficker has been observed and documented -

1.

"Once Conficker [A] infects a system, it includes a keyboard layout check, via the GetKeyboardLayout API, to determine whether the victim is currently using the Ukrainian keyboard layout. If so, [A] will exit without infecting the system. This suicide exit scheme has been observed in other malware-related software, such as Baka Software's Antivirus XP Trojan installer."

The suggestion is that Conficker's author(s) were trying to avoid violating the local laws of their native country. Presumably Ukraine (who's laws concerning computer crime seem to have several loopholes).

Source

2.

In a honeynet, there was a connection observed of the [B] variant of Conficker using variant [A]'s protocol to take over a machine already infected with Variant [A]... so it was Conficker trying to replace variant [A] with Variant [B]. For several reasons (located in the source link below), it is suggested the packet captured was an instance of Conficker testing it's own robust nature to not be taken over by another author or virus.

The significance of this is the "hybrid" packet described above came from an address owned by, again, Baka Software in the Ukraine.

Source

Yeah, I upgraded my FreeBSD 8.1 box to 9.0-RC2 so I could start playing with ZFS v28. Madly sacrificing chickens in triplicate, after a Gentoo-like recompile of 400 ports, freebsd-upgrade left me a somewhat hosed system where basic services (startx, portupgrade) won't run complaining that libz.so.5 is missing. I guess I'm looking at a fresh install.

As far as I got with ZFS, it totally rocked. In my test I set up a three drive mirror (which I think of as a plain mirror with a presilvered hot spare). Seeing 35MB/s copying over the LAN with rsync/ssh. A test involving recursive scp starting following symlinks recursively on a 20GB file set, which put the gears to deduplication. It ran great. I finally killed it at a duplication level of 7.8. Doubt dedup will do much for me in production on my little LAN.

My biggest worry is that you really need ECC to protect the long-duration content in the ARC cache, not to mention critical ZFS memory structures themselves. On the Intel side, for ECC you're looking at an X3400 chipset, or an expensive Xeon chip. Apparently there are somewhat cheaper solutions on the AMD side. For the ZIL cache, people recommend mirrored SLC.

For a while we enjoyed 60% annual drive capacity growth rate, but this is projected to fall to 20% annual growth as we head toward bit patterned media. I wouldn't assume vastly greater capacities in the near term.

Here is a nice paper, sans authorship date (which the author will regret when his time comes in the Beetlejuice afterlife lobby) :
End-to-end Data Integrity for File Systems: A ZFS Case Study

He cites a recent analysis of Google server farm metrics:
DRAM Errors in the Wild: A Large-Scale Field Study

It's a little unclear how to translate this for a home-use ZFS box. Error rate is usage dependent and seems to depend on the quality of the mainboard memory access path.

A feature that might help ZFS outside of the enterprise is an ARC cache scrubber using the ZFS checksum data.

I'm still figuring this stuff out, but my impression so far is that ZFS makes the most sense where data preservation must coexist with high availability and there are fall-back measures in place on the preservation front.

Is the display really that much of a hog on a cell phone? Those numbers sound like laptop numbers, but I thought we were talking cell phones.

My phone has a battery that holds around 1300 mAh at 3.7v. That means I can draw 4.8W for 1 hour. If my phone's display really sucked down even 10W, then I wouldn't be able to have the display on for more than about 28 minutes total, which doesn't match my experience at all. I regularly browse the web from my phone for a half hour at a time, without making much of a dent in the battery.

A quick scan through this paper suggests backlight power for the phone they analyzed tops out at 414mW, and the LCD display power ranges from 33.1mW to 74.2mW. If you drop the brightness back just a few notches, the total display power is around a quarter Watt or so, which sounds far more reasonable.

I don't think Intel is standing still on power consumption. Their desktop CPUs are hogs, sure, but they can bring a lot of engineers to bear optimizing Atom-derived products. (We might get an early read from Knight's Corner, actually, although I expect it to still be on the "hot" side. I'm waiting to hear more about it.) Also, ARM's latest high-end offerings (including the recently announced A15) aren't exactly as power-frugal as some of their past devices. In the next couple years, I think the scatter plot of power vs. performance for ARM and x86 variants will show a definite overlap in the mix, with some x86s pulling less power than some ARMs.

I'm a Canadian sysadmin. I love -- LOVE -- the LISA conference (http://www.usenix.org/lisa11/). It's wonderful, informative, and fun; I've made great friends there, learned an incredible amount and generally enjoyed myself enormously.

Last year was the third time I went. The conference was in San Jose. I took a bus and a train -- which took over 24 hours -- from Vancouver to San Jose, rather than fly and go through a naked body scanner. I figured if I'm going to talk the talk, I should walk the walk.

I'd already decided to skip this year's conference; it's in Boston, which is a long way to go by train or bus. I didn't want to be away from my family for that long. But I had been thinking about going next year, when it's going to be in San Diego.

I'm not going now. Not if this crap keeps up. I'll watch the video on my workstation, I'll listen to the MP3s on the bus, and I'll stay here in Canada. We have problems of our own -- but random searches and "papers, please" for the crime of taking the goddamned train are not one of them.

I'll miss y'all.

For those without access to the ACM paywall, this is an extension of Rizzo-Duong practical padding oracle attack published last year (citation needed in the ACM paper?)

http://db.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html

Scroll down to the table and see for example a 1 million hour MTBF drive with a real-world annual replacement rate (how many die every year) one-sixth that of a 1.5 million MTBF drive.

http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf paper quoted is the only real missing link.

From the paper "Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?" by Bianca Schroeder Garth A. Gibson

In our data sets, the replacement rates of SATA disks are not worse than the replacement rates of SCSI or FC disks.

So the annual failure rates are apparently similar, regardless of vendor claims

I don't think Telex is the right approach, but it offers one important benefit over the proxy approach: deniability. It may be true that regimes don't block all proxies. But if they decide to check up on you, they can see that you are using one of the censorship evasion proxies and punish you. With Telex, it appears that you are communicating with a legitimate web site; the only way to know otherwise is to crack the encryption and see that there's a message intended for Telex.

Getting help from ISPs isn't the only way to accomplish that. For example, if you could convince major players on the internet to run Telex-like systems _on their own machines_, then a user would have deniability because they could claim they were using the legitimate services on those machines. E.g. this might be a nice thing to put Google's 900,000 servers to work on, and would be a nice payback for last year's China hacking scandal.. Or something that all American universities could do in the name of free speech. The obvious way to block such a system would be to block the hosting site, but that may force the censor to cut off access to useful material (e.g. the teaching content on American university sites).

But it doesn't stop there; a censor could set up an SSL proxy and force all https traffic through it, which would allow them to decrypt any communication and look for suspicious side-requests. That's why we built a system a few years ago that disguises the subversive request in plain sight as a sequence of standard web browsing requests (and hides the response in images), without relying on SSL at all.

Even if I don't end up using that software, simply learning about smudge attacks made that link worth following.

Well. Luckily everything is save and nobody would ever use Bittorrent...

https://www.usenix.org/events/leet11/tech/full_papers/LeBlond.pdf

I did not know this paper when posting, but what i know is that giving streams to arbitrary unknown exit nodes is not very wise. I imagine that if a research group can replace a small nuber of exit node, then i dont know what one of the big North American buyers of computational power (the NSA) can do (does anybody know if there is "critical" number of Tor nodes to reconstruct traffic reliably in a given time? ).

Keep in mind that porting, in this case, is just a recompile away, since all APIs remain the same, and most architecture assumptions like sizeof(void*) are identical to x86; the only difference is in unaligned pointer access, and even that can be trapped/emulated by OS.

All that was true for Mips, Alpha and PPC. And yet very few people bothered to port because few people bought the machines. And few people bought the machines because there was no native software and emulation sucked. Actually emulation didn't suck on Alpha - they had a very cool emulator called FX!32

http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf

DIGITAL FX!32 had two primary goals: transparent execution of 32-bit x86 applications, and performance that was roughly equal to a high-end x86 platform when running the same applications on a high-performance Alpha system. Both objectives have been meet.

Transparency is provided by the DIGITAL FX!32 agent and a runtime environment which will load and execute an x86 application without a translation step. Applications launch and execute on an Alpha running DIGITAL FX!32 just like they do on an x86.

DIGITAL FX!32 also meet its performance objectives. Figure 1 shows the relative performance on the Byte Benchmark of a 200Mz Pentium Pro and a 500 Mz Alpha running DIGITAL FX!32. For this benchmark, the Alpha running DIGITAL FX!32 provides about the same performance as a 200Mz Pentium Pro. Figure 1 also shows that the Alpha native version of the benchmark runs twice as fast as the Pentium Pro.

A top of the range 500Mhz Alpha got about the same performance running x86 code via FX!32 as a top of the range 200Mhz Pentium Pro got running it natively. If you recompiled things got 2x faster.

So any app for which there is active development would likely do just that - and that's a huge chunk of applications being used on Windows desktops today (Photoshop, various tax/accounting software etc).

Well there's a question if Photoshop would be much use on an Arm netbook or tablet. Bear in mind people who run it tend to have very fast x86 machines. Most Arm chips are probably slower than an Atom. People don't run Photoshop on Atom machines and especially not on tablets.

In fact the situation is much worse than it was for Alpha. Alpha machines were about 2x faster than the fastest x86 at one point. They tended to have more and faster Ram and bigger caches. Arm ones are likely to be at the same speed or slower than the slowest one and have smaller caches and slow memory. A top end x86 is much, much faster than a top end Arm. Of course you can fry eggs on a high end x86 and a high end Arm is low power. But low power tends to mean low performance. Alpha was hotter than x86 and higher performance - it had enough of a lead for emulation to be viable and was much better running native code. That's not the case for Arm.

Frankly you'd be better off running Android on a high end Arm tablet. The apps there was designed for a much slower machine and would fly. Photoshop and the like were designed for a much faster machine and will be horrid even if ported. And even worse in emulation.

Read the paper. Some of the sites use sequential identifiers for files, and they used honeypots to verify that criminals would indeed grab files they placed on some of the sites without sharing the locations of those.

About 5 years ago, I contributed to a paper that brought up a particularly brain-dead thing they did with the auto-update mechanism for their then-current consumer version of VirusScan:

http://www.usenix.org/events/hotsec06/tech/full_papers/bellissimo/bellissimo.pdf

Long story short -- their ActiveX control exported a wrapper around the Win32 ShellExecute API. What could possibly go wrong? The XSS thing in their help here seems to be of the same "do the simplest thing, damn the consequences" variety; it looks like they've tried to patch the XSS issue but it's pretty weak sauce. Hint to McAfee: Did you know most browsers will load "HTTP://example.com" as readily as "http://example.com"?