News for hackers. Stuff that matters.

language

Re:Reading privileged memory with a side-channel on Wednesday January 03, 2018 @10:08PM (#16067714)
iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0.

https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...

Re:Reading privileged memory with a side-channel on Wednesday January 03, 2018 @08:43PM (#16067295)
Text and patch start here: https://lkml.org/lkml/2018/1/3/780

Also, see Linus' response here: https://lkml.org/lkml/2018/1/3/797

Seems healthy leaving it to the user.
Re:Let's enable AppArmor by default (why not?) on Thursday October 12, 2017 @04:40PM (#15461143)
Thanks for the clarification, although I recall messing with eBPF and kprobes before - pretty sure you can dereference pointers?

editx2: Oh, guess seccomp doesn't use eBPF yet? Suppose that raises a bunch of questions about permissions necessary for specifying programs that might dereference kernel pointers and such by emitting `bpf()` calls.

Re:Let's enable AppArmor by default (why not?) on Thursday October 12, 2017 @10:52AM (#15458383)
I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in userspace? I've only played around with it a tiny bit.

Also, both kinds of policy are resident in files. I don't understand your point there.

Re:Let's enable AppArmor by default (why not?) on Wednesday October 11, 2017 @11:04PM (#15455375)
How so? I understand they're different, but I thought there was some overlap. Don't LSMs work by hooking syscalls anyway?
Re:Let's enable AppArmor by default (why not?) on Wednesday October 11, 2017 @06:39PM (#15454173)
> Update: they just managed to get this done with stretch, released 4 months ago! That's only like 7 years late for a crucial actual security feature)

Dunno, taking @revelation's word for it? Mentioned they were missing it. It sounds funny to me though. I'm not a Debian user.

edit: The Debian page on security features confuses me (https://wiki.debian.org/Security/Features).

Re:Let's enable AppArmor by default (why not?) on Wednesday October 11, 2017 @06:19PM (#15454028)
There's some kind of bind here between "putting burden on end-users" and "putting burden on application developers." Either you (a) ship $LSM with some defaults that are necessarily general (so as to avoid breaking applications) and let the user fit filters to their circumstances, or; (b) push for developers to write/maintain filters baked into their applications (ie. using some kernel features like `seccomp` and what-have-you).
Re:Let's enable AppArmor by default (why not?) on Wednesday October 11, 2017 @05:52PM (#15453824)
Huh, didn't know that Debian was missing ASLR. Any idea about the reasoning there?
Re:Microsoft Becomes Sponsor of Open Source Initiative on Wednesday September 27, 2017 @09:51AM (#15347774)
I can't tell. If you remember they became a platinum member of the Linux Foundation last year too.
Re:Linux System Call Table on Monday September 25, 2017 @04:25PM (#15333805)
Ah, this is neat! Would be nice to have a script for this that you could just point at a local copy of the source tree too!
Re:A Quick Introduction to Graphviz on Sunday September 24, 2017 @01:58PM (#15325743)
Love Graphviz, been using it for some time now. It's kind of painful rendering large graphs. Does anyone know the particular reason why `dot` and friends only seem to take advantage of one CPU core when drawing graphs? Multi-threading unimplemented? - or impossible to implement for some reason?
Re:PulseAudio under the hood on Friday September 22, 2017 @09:53AM (#15312147)
I've only dealt with this on Intel chipset HDMI - if I'm remembering correctly there's some part of the snd_hda_intel kernel modules you can blacklist in order to disable this.
It applies to Macs. I think AMT is just one particular application/feature of ME. ME is a piece of hardware on Intel chipsets.
Re:Consciousness Goes Deeper Than We Think on Wednesday September 20, 2017 @10:53AM (#15294378)
Is difference (the distinction in question) something intrinsic to the world, or something imposed upon the world?
Re:Consciousness Goes Deeper Than We Think on Wednesday September 20, 2017 @10:11AM (#15293889)
>The problem of looking at human consciousness is similar to someone that knows little about computer processors pulling apart an I7 and trying to figure meaningful things about what is going on inside. Without knowing the history of processor design, there will be huge information gaps on why some parts work the way they do.

I don't think the analogy is adequate. A processor is an object - it "objects" to all of us. It appears to have an existence independent of the thing that recognizes it as such. When we embark on an empirical investigation of something, we make a distinction between the scientific observer and the scientific object. We come to an agreement about the boundaries of the object. This does not appear to be the case if you want to call consciousness "that special [condition, or process, or property, or pattern, etc.] of being a scientific observer" (which we would ideally want because it seems to encapsulate all those special things that distinguish human beings from other organisms with nervous systems).

In that domain, we cannot make a distinction between subject and object. In order to even speak intelligibly about things, we must all draw the boundary of the thing we're talking about - but we are in the peculiar position of being the very act of drawing the boundary.

Re:Consciousness Goes Deeper Than We Think on Tuesday September 19, 2017 @11:47PM (#15290654)
> .. that perhaps 'our ability to think about the issue is constrained by our language' and '[consciousness] workings being inaccessible to introspection' are the same thing.

I like to think about it that way, but it makes the problem feel intractable.

The problem is that we want to describe consciousness as "that thing that allows an organism to describe consciousness as 'that thing that allows an organism to describe consciousness as ´that thing that allows an organism to describe consciousness as [...]´'"

Re:Consciousness Goes Deeper Than We Think on Tuesday September 19, 2017 @10:57PM (#15290432)
> But our consciousness goes beyond simple self-awareness: having a theory of mind is a step beyond (and is realizing that others have a theory of mind a step beyond that?)

That [and this] whole space [of considerations, here] appears to be fraught with circularities like this:

Step 1. Draw a distinction between consciousness and meta-consciousness.

Step 2. "From what vantage point, and with what 'machinery' do we make a distinction?"

Step 3. Go back to Step 1.

> .. that our ability to think about the issue is constrained by our language.

I think I agree, otherwise I'm tempted to think that we would have already arrived, trivially, at some clearer kind of agreement about it.

Blade Runner means so much to me. I'm very glad that this is a thing, although, like with all sequels and re-interpretations of experiences that are near-and-dear to me, I'm struggling through "trying not to have too many expectations." I'd like to see the way that this is re-interpreted - but there's a very particular aesthetic and air about the original that I'd love to see kept around.
I think DirtyCOW (CVE-2016-5195) had been dormant in the kernel for a long time. If I remember correctly the PoC demonstrated writing on root-owned files. Might be relevant.

https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...

If by class of bugs you mean "munging the stack," yes - but the difference is in the effect on integrity of the total system. In monolithic kernels, if an attacker can monopolize on the situation (by defeating mitigations, if any) and control execution-flow, they can run code on ring 0. This isn't the case if you're on a microkernel where a bluetooth driver lives in userspace.
Re:The Limitations of Deep Learning on Monday July 17, 2017 @03:01PM (#14791375)
"Machine learning models have no access to such experiences and thus cannot "understand" their inputs in any human-relatable way"

It may be that distinctions like the one you're describing here are useful to make, but I don't think this claim refutes the possibility of ML "fitting a particular piece within a larger, yet unarticulated model."

I think the assertion is more that our current ways of representing elements of human experience are necessarily very lossy - or that there's some aspect of the situation that you can't describe/implement in terms of models of neural nets.

Re:The Strange Loop in Deep Learning on Wednesday July 12, 2017 @11:03AM (#14753110)
However, as we are all now beginning to discover, the employment of ‘feedback loops’ are creating one of the most mind-boggling new capabilities for automation. This is not hyperbole, [...]

Always glad to see references to Hofstadter's work, but this sounds like hyperbole. I don't think that mere feedback loops are "strange" enough to invoke his name. I think the idea refers to loops in systems which are heterarchical. I don't think there are any interesting crossings over different layers of abstraction here.

Interestingly, these ideas have been around for quite some time. For example, the work of Warren McCulloch (and Walter Pitts) predates Hofstadter's thought in this space. Relevant passage from his 1945 article, "A Heterarchy of Values Determined by the Topology of Nervous Nets":

"[..] three heterodromic branch­es link the dromes so as to form a circle in the net which is distin­guished from an endrome in that it is not the circuit of any drome but transverse to all dromes, i.e., diadromic. The simplest surface on which this net maps topologically (without a diallel) is a tore. Cir­cularities in preference, instead of indicating inconsistencies, actually demonstrate consistency of a higher order than had been dreamed of in our philosophy."

Re:Unikernels are secure on Monday July 10, 2017 @05:27PM (#14739851)
> one could imagine a boot loader that loads the main unikernel at a random address, sets up page tables with NX, and then makes a one-way transition to ring 3

True - I suppose I'm trying to hold onto the "kernel:hypervisor :: process:unikernel" analogy here for no good reason. Following it suggested that it might be the hypervisor's responsibility.

Re:Unikernels are secure on Monday July 10, 2017 @03:37PM (#14738956)
Just like an operating-system executes processes, a VMM executes unikernels. An operating system is responsible for randomizing the layout of processes in memory. Shouldn't the actual question here be "Does my hypervisor implement some mechanism for randomizing the layout of my unikernel?"
Re:Unikernels are secure on Monday July 10, 2017 @02:48PM (#14738594)
Also worth mentioning that `ldd` only demonstrates how shared libraries are mmap'ed at randomized locations. Stack and heap allocations are also randomized at execution time.
Very glad to see references to Bateson here. To paraphrase some other cybernetician[s]:

"Order and chaos are not a properties of things, but relations of an observer to something observed - the ability for an observer to distinguish or specify pattern."

Re:A collection of abstract patterns on Thursday July 14, 2016 @09:43PM (#12098476)
> Both arrive in similar places, but usually for different reasons.

Kind of how I take philosophers/scientists to be (and other dichotomies that are variations on that kind of pattern). There's a funny [and highly paraphrased] quote I use from Heinz von Foerster that I think is highly relevant:

"The reductionist eventually comes to know everything about nothing (by way of distinction) - the wholist eventually comes to know nothing about everything (by way of generalization)."

Older »