HN user
Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes.
I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]).
What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. The 20171215 update carried by some distros only seems to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed, are they covered by the 20171117 update, or are the new microcodes simply not ready for all models yet?
Of course, the microcode updates are meaningless without the corresponding kernel patches, but apparently only RHEL and SLES were deemed worthy of receiving those ahead of time, having already rolled them out while Linus and co are left scrambling to integrate the IBRS and retpoline code dumps after the fact.
[1] https://tracker.debian.org/news/899110 [2] https://downloadcenter.intel.com/download/27337/Linux-Proces...
It appears to be available on a few other models as well (searching 'site:dell.com "ME inoperable"' brings up service tags for a few non-rugged Latitudes and a couple of Optiplexes), despite it not being an option on their configurators.
I wonder if this means that it's also possible to disable ME on those machines after purchase (without triggering Boot Guard)?
Dell only offers a single download per firmware version per model (or group of models) to cover all configurations, so presumably it contains multiple images (i.e. AMT-enabled, AMT-disabled, ME-disabled), and the updater just uses ME status or DMI data to determine the correct one.
If that's the case, then surely it should be as simple as manually extracting and flashing the ME-disabled image, right? That's assuming it's actually included in the publicly available updaters, and that all of the images are signed with the same key, of course.
Actually, Chromium (and uBO) has supported blocking WebSockets via webRequest for a while now[1], despite the desperate protests of a MindGeek employee[2].
[1] https://chromium.googlesource.com/chromium/src/+/0f198df6bc8... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=129353...
If you're able to build Chromium yourself, here's a trivial patch which does just that (only tested on Linux):
https://gist.github.com/blockoperation/5ec91d666e670e39584d2...
Since we're talking about backdoors, how about compiler ones?
With C, there are several routes to bootstrapping your compiler of choice – there are countless implementations that can be used as intermediates (both closed and open source, for all sorts of architectures, with decades worth of binaries and sources available), and diverse double compilation is a thing.
Rust? Unless you want to go back to the original OCaml version and build hundreds of snapshots (and providing you actually trust your OCaml environment), you've got no choice but to put your faith in a blob.
I'm not against Rust as a language, but it seems counterintuitive to use a language that only has one proper implementation and requires a blob to bootstrap, as a defense against backdoors.
It would be easy for them to fingerprint it and block it at a server level, given that it uses some hardcoded headers (which are probably sent in the wrong order versus the browser it's spoofing), doesn't fetch any of the images/stylesheets/etc on the page, and probably fetches scripts/manifests/etc in a predictable order that differs from YouTube's own scripts. Maybe they already do this (fingerprinting and logging, that is), but I haven't heard of anyone being banned for it, so it's probably not something to worry about.
It would also be easy for them to just break the extraction code. The old code used to break every time the signature function changed, and while the current code solves that problem, there are still so many things that they could do to break it, and yet they don't (the current code has only broken a few times that I can think of, and I don't think any of those were intentional on Google's part).
Technically it could violate these parts of the ToS, but they're all grey areas:
- access through anything than the site or 'approved' clients (but youtube-dl does use the site, so it could just be classed as another user agent)
- running automated services against them (running youtube-dl manually is probably fine, even for whole playlists or channels, but running a 'youtube-dl as a service' site like the one in this case is almost certainly not)
- downloading videos (but youtube-dl can also be used for streaming, despite the name)
I'm guessing that Google simply doesn't give a shit, as long as you're not using using it abusively (e.g. offering it as a service or using it to do mass-scraping).
Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that many 'fun' bugs would crop up as a result.
Writing performant code by using the correct idioms, data structures, algorithms, etc, from the start is just common sense rather than 'premature optimisation'.
Writing unreadable, micro-optimised code in the name of performance without even attempting to profile it first is another matter.
My personal rule (as a not-very-good hobbyist) is that if I have to refactor everything in order to accommodate an optimisation in a path that's already 'fast enough', or introduce some arcane hackery that only makes sense with comments into otherwise clean code, then it must be backed up with realistic benchmarks (and show a significant improvement).
Adolescents are horrible at consequence extrapolation: it's why they're famously risk hungry and blasé about doing stuff grownups would be terrified of. Why they never think they'll be the ones who die or get pregnant or fail.
With that in mind, I think the worst effects of smartphones/social media/etc are yet to come.
Kids these days broadcast every last embarrassing detail of their lives all over the internet, and smartphones make it possible to do so conveniently from any location, so there's no time to reflect or consider whether it'll come back to bite you. When these kids grow up and realise the extent of the embarrassing (or possibly incriminating) information they've shared about themselves (and how little control they have over that data), it's going to hurt.
Whether smartphones themselves have 'destroyed' a generation is debatable, but the combination of smartphones and social media is certainly going to cause some mental health issues in the future (if it hasn't already).
Resources/frames/XHRs/etc from 'file://' might be blocked, but what about top-level redirects?
At the very least, user-initiated top-level navigations should bypass any policies. If you're out to cause mischief, you could just link to the dodgy path on forums/comments/etc – there'll always be people out there who are careless and/or clueless enough to click on it.
Samples are just instruments, and sequencers are just composition tools. It's the end result that matters.
I'm surprised it took this long for her to bring up the subject – Theresa May would've had her soundbites prepared in advance and released within hours of the attack if she was still Home Sec.
That is my view - it is completely unacceptable
You know what else is completely unacceptable? Technologically illiterate, authoritarian jobsworths capitalising on tragedy to push through their agendas. But that's just my view.
Home Office always seems to attract the nastiest and dumbest of politicians, but this is a whole new level of dumb, and sadly will only gain her more support, because the general public either have no idea about the implications of backdoored crypto, or simply don't have any expectation of privacy and are happy to give up what little they have left in order to feel safe.
I'm still waiting for Chromium to add a per-site switch for WebGL (just like for JS, cookies, Flash, etc). Enabling WebGL globally seems like a disaster waiting to happen, even with sanitisation and sandboxing.
Renoise is great, especially for breakbeat/jungle drum programming. Just load up your break of choice, put in some slice markers (or play it with offset commands like on old trackers), and you're set.
I do find the pattern-based workflow a bit of a productivity killer though (I usually get stuck on perfecting the same 8/16 bar loop).
I haven't tried an XPS, but the Precision 7xxx stuff definitely qualifies. My 7510 came with Ubuntu, and the experience was just as polished as any Windows machine (better in some ways, as they had configured their way around some Skylake-specific issues that still affected Windows at the time).
sesearch is one way of doing it, for example:
$ sesearch -A -s some_app_t -c file -p read -p write
allow some_app_t some_type_t:file { read write };
allow some_app_t some_other_type_t:file { read write };
allow some_attribute_of_some_app_t yet_another_type_t:file { read write };
$ sesearch -A -t some_type_t -c file -p read -p write
allow some_app_t some_type_t:file { read write };
allow some_other_app_t some_type_t:file { read write };
I don't see why you should get to run random, unauditable code on my machine or decide for me how I consume your content.
The Google Cloud status page had a message about some 'long-lived' OAuth tokens being invalidated on the same day that the mass logouts occurred. They took it down quite quickly, and it doesn't appear in the incident history.
FWIW, I only use Gmail via browser (with the regular web-based sign-in, not through Chrome/Chromium), and all of my sessions stayed intact.
It's available on my laptop at least:
$ egrep '^(model name|microcode)' /proc/cpuinfo | head -n2
model name : Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
microcode : 0x9e
$ egrep -o ' (hle|rtm) ' /proc/cpuinfo | head -n2
hle
rtm
Multiple accounts can be quite usable if you get the separation right. Separate uids for personal emails/banking and porn browsing should be a given, at least.
I'm familiar with grsec (having an interest, albeit not as an expert, in some of the issues it addresses, and as a long-time Hardened Gentoo user), but that doesn't override my point that 'CONFIG_MODULES=n' seems neater than 'echo /bin/false > /proc/sys/kernel/modprobe'. If you only need a predefined set of modules and have no need to load them after boot, why not just disable the facility altogether?
I can see why it might be a burden when you're dealing with hundreds of servers, but on a personal machine, where the occasional disruption won't get you sacked, it's pretty straightforward (though I say this as someone who follows kernel development as a hobby and has the time to track down bugs).
...or just roll your own kernel with CONFIG_MODULES=n.
If you only need a specific set of modules, you might as well just build them in and just forget LKMs altogether.
It's not very convenient when you run into some obscure hardware/fs/protocol, but depending on your use case, that might not be an issue (and even in the rare case where it does come up, it's not the end of the world – a minimal kernel build only takes a couple of minutes on a reasonably fast machine).
The only case where LKMs really seem necessary (besides in generic distro kernels) is for module development/debugging, but you're probably not going to do that with a production kernel anyway.
It must be used with care though, otherwise you'll end up with so many holes in your policy that you defeat whole point of using SELinux in the first place. Definitely don't use the output directly.
ECC could also help to raise the alarm when you're under attack – the chances of flipping enough bits to evade ECC (and have them be the right bits to pull off your exploit) without getting a few detectable flips in the process must be quite slim.
Some video streaming sites do the whole per-connection limiting thing, which is annoying when you want to download multiple things to watch later (especially really long playlists).
Normally I'd say that accelerators are abusive, but being forced to download hours of video in near-realtime is such a pisstake that I'm willing to make an exception (the alternative is to download multiple videos in parallel, which is even more abusive, yet less frowned upon).
Also where can I download the "public RAP demo"?
I assume that's the version that comes with the PaX/grsec kernel patches, in which case it's this:
https://github.com/minipli/linux-grsec/tree/v4.8.17-pax/scri...
You've missed out another benefit (of Gentoo specifically): the ability to conveniently apply your own patches – just copy them to /etc/portage/patches/category/package-version and then re-emerge the offending package.
Most users will probably never need to do this, but I find it invaluable.
I maintain my own patches for dozens of packages in order to fix quirks/WONTFIX bugs, add features that upstream refuse to touch, remove intrusive/unwanted features that piss me off, etc, and being able to do this without also having to maintain my own deb/rpm/<some other package format> makes it much less painful.
It's also nice for applying emergency security fixes without waiting for your distro to pick them up.
I use parallel for pretty much all batching these days. It's useful even when you don't need parallelisation – here's a simple transcoding example:
parallel -j1 'ffmpeg -i {2} -c:v libx264 -tune film -preset veryslow -crf 18 -vf scale={1} -c:a libfdk_aac -vbr 5 conv/{2.}-{1}.mp4' ::: hd480 hd720 hd1080 ::: *.mp4