mato

9 ms·

31.
by mato 6y ago
If you're interested in "other things" that can be done with KVM, take a look at the Solo5 "hvt" tender: https://github.com/Solo5/solo5/tree/master/tenders/hvt .
32.
by mato 6y ago
Hi Nat. Just to clarify, do these pricing changes imply that users without a paid plan will no longer receive any e-mail support from GitHub? Speaking as a long-time user, over the last 10(?) years I've only ever needed to reach out to
33.
by mato 7y ago
Seconded. Didn't know about this tool, but have been looking for something similar with custom country selection and logarithmic graphs. Thank you for making this, keep it up.
34.
by mato 7y ago
> "Of the top 100 vulnerabilities reported for QEMU: > - 65 were not guest exploitable > [...] Which leaves about 30 that presumably were guest exploitable. Don't get me wrong -- QEMU is useful . As a "kitchen sink&
35.
by mato 7y ago
> In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins. Indeed. Nice to see that the cross-pollination is happening. For folks interested in what
36.
by mato 7y ago
I can't comment on the Nabla parts as I don't work on that and have not read the code in any detail, but upstream Solo5 (and thus MirageOS on Solo5) has gradually been getting fixes for most of the "security posture" iss
37.
by mato 8y ago
+1. I've since switched (grudgingly) to sending myself DM's of Tweets that I want to "save for later". A poor substitute, but easy to reach for from the UI.
38.
by mato 8y ago
> This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway. The largest part of a monolithic kernel today is devices drivers, by far. > Networking isn't trivial and I don&#x2
39.
by mato 8y ago
That's a very good question. The answer is, "it depends". For the 80% case, on x86_64, I consider them more or less equivalent. KVM is used daily in anger to provide isolation (e.g. GCE, and now ChromeOS) and has been around
40.
by mato 8y ago
And indeed, we have built some tooling for debugging, since we wanted it: https://github.com/Solo5/solo5/blob/master/docs/debugging.md . It wasn't that hard.
41.
by mato 8y ago
That's a shame, because Erlang as a unikernel already exists (as https://github.com/cloudozer/ling , unfortunately unmaintained). I'd be really keen on seeing an Erlang port to the Solo5 API, which would give
42.
by mato 8y ago
A unikernel conference? I didn't know there was such a thing.
43.
by mato 8y ago
> If the unikernel is running as a normal process, all that potentially vulnerable code is still on the box [...] Correct. Conceptually the same applies to all Type 2 hypervisors. Type 1 less so, but you could still potentially exploit X
44.
by mato 8y ago
> In the former scenario, the host provides things that look like CPUs, NICs and things that look like block devices, with no high-level abstractions (e.g. threads, sockets, and filesystems). To add to this, with the approach we're
45.
by mato 8y ago
The post discusses running unikernels without "the abhorrent mess that is hardware virtualization".
46.
by mato 8y ago
Co-author of the paper referenced in the blog post here. 1. Regarding bugs: There is a lot of code in your monolithic OS kernel. There have been, and will be, a lot of vulnerabilities in that code. Various sandboxing mechanisms notwithstand
47.
by mato 8y ago
Yes. I've been using a Blackberry Classic for over a year now ("upgraded" from an old Nokia Symbian phone). Does plain IMAP (TLS 1.2), with IMAP IDLE support just fine. Only annoying "feature" of the email client is
48.
by mato 9y ago
I've been hosting my own mail server since 1997, at its current colo since 2007 or so. I've never had any issues with delivering email to gmail users. So, I'm curious, am I just extremely lucky to have competent sysadmins as
49.
by mato 9y ago
Solo5/ukvm unikernel monitor co-author here: I've been thinking about rewriting ukvm in Rust off and on for some time now, your work provides a proof point that it can be done. I'll be following it with interest. Aside: I rea
50.
by mato 9y ago
Pipes and sockets on a local system are usually implemented using shared memory. While there are challenges to implementing secure* shared memory interfaces, it has been done (see eg. SEL4, QNX and many others). * For example, DoS-safe
51.
by mato 9y ago
VM interfaces are awkward due to emulating hardware so that they can run existing operating systems. A VT-backed unikernel interface does not need to inherit this awkwardness. As for memory management, in the Solo5/ukvm case the amou
52.
by mato 9y ago
By their nature, unikernels are extremely well suited to running on top of a simple and well-defined interface. By extension, such interfaces are easy to audit and secure. Why is this better than running as a normal user process? Look at th
53.
by mato 9y ago
> On a unikernel this sort of thing becomes trivial since everything is Ring 0 and all protections can be trivially disabled. If the hypervisor sets the relevant VMCS control fields for the unikernel to cause a VMEXIT on (for example) a
54.
by mato 9y ago
> On a normal operating system, an exploited app has a limited action range Minor point, but this seems to be a bit lost in the discussion: Generally 1 unikernel == 1 VM (or, virtualization-backed sandbox, the use of "virtual machin
55.
by mato 9y ago
> If you want to prevent fork/exec, that's super easy to do in a conventional Linux application: And mmap(), mprotect(), ptrace(), ..., $syscall_du_jour(). It's not about fork/exec, it's about limiting the APIs a
56.
by mato 9y ago
1) Virtualized Ring 0 != Ring 0. See section 24.6 "VM-execution control fields" of the Intel SDM for details of the controls a hypervisor can use to modify guest behaviour. 2) The same applies to any application, not just unikerne
57.
by mato 9y ago
> A unikernel cannot do this. If the app is compromised and I don't notice and don't restart it... I disagree. There's no reason such mitigations (not sure what exactly you're referring to) can't be implemented b
58.
by mato 9y ago
> Back in 1999 we had MOSDEF and CORE IMPACT (...) I'm not familiar with these. Googling "MOSDEF attack" suggests Massive Attack songs and "CORE IMPACT" various products by Core Security, I presume you're re
59.
by mato 9y ago
Access to ring 0 on a traditional OS is indeed usually "game over". In the case of a unikernel deployed on a hypervisor this is not the case, since there is not much else in ring 0 that you wouldn't already have access to fro
60.
by mato 9y ago
As one the early users[1] guilty of using the "there is no shell" argument for unikernel security, I agree with what you say. I would rephrase the argument as "there is no fork()/exec()", meaning that a unikernel ca

More ›