arielby

7 ms·

1.
by arielby 11y ago
No. This is a subtle vulnerability that involves the flags in the x86 page table not matching the hypervisor's view of them - not a mere buffer overflow. Ordinary static analysis couldn't have fixed this. Safe languages couldn&#x2
2.
by arielby 11y ago
> This bug might also be considered an argument for the view of ditching of para-virtualized (PV) VMs, and switch to HVMs It's not like Xen HVMs have a better security story than PVMs. The paravirtualization code should probably be
3.
by arielby 11y ago
Not more difficult than C - you write the crypto functions in asm. You could use a C compiler to handle the ABI but the code isn't really C code.
4.
by arielby 11y ago
The arithmetic operators in x86/x86-64 are certainly polymorphic (over word-length, plus integer vs. x87 vs. SSE). I think the distinction is that #3b-types, which denote the "encoding" of a value, mapping it to its meaning,
5.
by arielby 11y ago
I would split use #3 into two parts: 3a) disambiguation for builtin operators - e.g. a float local needs to go in a float register, adding 16-bit integers uses 16-bit addition, a struct local needs to go in an appropriately-sized memory loc
6.
by arielby 11y ago
That's why you make sure all operations you do are bidirectional.
7.
by arielby 11y ago
A few years ago it was popular to serve files via a not-really-trusted mirror (e.g. Sourceforge), while serving the website via a personal server.
8.
by arielby 11y ago
libgcrypt was written before timing side channels were an issue. modern crypto libraries (and OpenSSL) are at least supposed to be constant time and not to be affected.
9.
by arielby 11y ago
The problem with the original lottery is that most of its value is from high-EV tiny-probability events, e.g. the 2^{-50} probability of winning 2^50 dollars. The practical result of that event does not seem to be worth 2^50 utilons, to say
10.
by arielby 11y ago
chroot was always intended to allow running processes picky about their system environment.
11.
by arielby 11y ago
This is the well-known CRT fault attack, nothing new. SSL implementations that don't verify their signatures leak the private key if their signature routine has a bug - this is essentially a hardware problem. Verifying your signatures
12.
by arielby 11y ago
well C++11 strings are just "reallocate when you look at them funny". Or you use shared_ptr and are back to square 1.
13.
by arielby 11y ago
> Slicing Pascal-style strings is also easy and constant-time: just track the buffer, offset, and length of the slice of characters you want. Java used to do it implicitly whenever you called `substring`. That's just coercing into a
14.
by arielby 11y ago
Rust's error handling (try! and error-interoperability) do this well.
15.
by arielby 11y ago
NUL-terminated strings aren't that bad: * unlike Pascal-style strings, they can be usefully sliced, especially if you can modify them strtok-style. * unlike (ptr,len) "Modern C buffers"/Rust-style strings, references t
16.
by arielby 11y ago
Haskell has `undefined` bombs, which are a similar problem.
17.
by arielby 11y ago
According to the paper, it simply makes everywhere outside of data structure code a quiescent state. This may be a big difference in practice through, because one of the appeals of RCU is being able to interact with data structures with no
18.
by arielby 11y ago
Could someone explain the big difference between RCU and epoch-based reclamation? It seems that the only difference is that RCU has quiescent periods between reschedules and epoch-based has them when you don't have a Guard struct activ
19.
by arielby 11y ago
Except you can have a void * that does not have an end address.
20.
by arielby 11y ago
A pointer points to the start of its pointee - i.e. the point "just before" its pointee. That's how derived-to-base casts work. That's also how you can have "one-past-the-end" pointers, which are actually &quot
21.
by arielby 11y ago
Original reporter here. I was starting to worry when this will ever get fixed. I am not skilled in exploit development and I basically just found the bug by accident so I won't take the challenge.
22.
by arielby 11y ago
1.2 is so much better with ICE-s than 1.0.
23.
by arielby 11y ago
Why the focus on context-sensitivity? You can perfectly well validate a (restricted subset of) HTML with a regex - regexes are in fact very good at input sanitization. Parsers are dangerous because formats have exponentially many edges for
24.
by arielby 11y ago
When the MIR work is done creating a new translator would certainly be easier.
25.
by arielby 11y ago
The annoying thing is that (because of type inference) parts of the expression could be within different expressions: fn required_bytes(width: u16, height: u16) -> u64 { let size = width * height; // what's t
26.
by arielby 11y ago
I agree that "are you sure you want to proceed?" dialog boxes on a word processor are absolutely horrible , but not all dialog boxes are so bad - Firefox's unacceptable certificate page, is, for example, a decent solution fo
27.
by arielby 11y ago
The "use a stupid heuristic as part of the evaluation function" is is, in fact, also an important part of Chess AI's mode (as Quiescence Search), through for different reasons.
28.
by arielby 11y ago
Could you be more specific? The last Debian security update was in April, which is more than 2 months ago.
29.
by arielby 11y ago
lock-free data structures should have identical semantics (and uncontended performance) to lockful data structures with per-operation locks (up to performance), except for the temptation to hold the data structure lock for a long time. The
30.
by arielby 11y ago
Don't you lose all of your performance gains in RPC overhead? How do you avoid latency in the data thread (do you have one thread per lockable object? won't that be more than 1 thread per core?) - these are the reasons lock-free i

More ›