-
rzhikharevich
2 months ago
|
link
| on:
OpenBSD Journal - Intel FPU Speculation Vulnerability Confirmed
Does Intel mention all those CPU bugs and vulnerabilities in their (updated) system programming manuals / errata?
-
Why would you ever want to access a string by a code point index and not a byte offset is absolutely beyond me. Let alone the fact that this article ignores the presence of grapheme clusters (aka user-perceived characters).
-
I don’t understand how it’s possible pick three here: “full-native speed”, single address space OS (everything in ring 0) and security. I believe you can only pick two.
-
Well, that’s what nebulet is trying to challenge.
-
-
I haven’t yet read the whole paper but in the conclusion they say that performance was a non-goal. They “also improved message-passing performance by enabling zero-copy communication through pointer passing”. Although I don’t see why zero-copy IPC can’t be implemented in a more traditional OS design.
The only (performance-related) advantage such design has in my opinion is cheaper context-switching, but I’m not convinced it’s worth it. Time (and benchmarks) will show, I guess.
-
When communication across processes becomes cheaper than posting a message to a queue belonging to another thread in the same process in a more traditional design, I’d say that that’s quite a monstrous “only” benefit.
I should have drawn your attention to section 2.1 in the original comment, that’s where you original query is addressed. Basically the protection comes from static analysis, a bit like the original Native Client or Java’s bytecode verifier
-
-
-
-
I remember making a procedure that dynamically generated functions with “bound” this pointer. It worked by allocating a trampoline and writing the object’s address. It was horrible.
-
i put on my robe and wizard hat
-
Curious what it would take to flash a modified version of this to an old iPhone. Could one theoretically boot a Linux kernel if the signing check was omitted?
-
Not sure if it’s entirely relevant to this, but I did get Android installed on my 1st gen iPhone back in the day using this: https://www.theiphonewiki.com/wiki/IDroid
-
I’m guessing the keys themselves have not been released so the issue is getting anything non-apple onto the device in the first place? Also guessing, if we had the keys we could easily modify iboot, or relatively easily port core boot or whatever the cool kids are using these days and ignore signing?
-
You don’t really need keys these days to boot something. You can use kloader which is basically kexec for (32-bit) iOS. It has been used for dual-booting a signed iOS installation with an unsigned one.
-
-
-
There was the OpeniBoot project – an open source reimplementation of iBoot that works on older iPhones up to iPhone 4.
-
-
Any security minded people have thoughts on this?
-
Debian’s security record regarding CAs is atrocious. By this I mean default configuration and things like the ca-certificates package.
Debian used to include non-standard junk CAs like CACert and also refuse to consider CA removal a security update, so it’s hugely hypocritical of this page to talk about many insecure CAs out of 400+.
Signing packages is a good idea, as that is bound to the data and not to the transport like https so in principle I agree that using https for debian repositories doesn’t gain much in terms of extra security. However these days the baseline expectation should be that everything defaults to https, as in no more port 80 unauthenticated http traffic.
Yes, moving over to https for debian repositories breaks local caching like apt-cacher (degrades it to a tcp proxy) and requires some engineering work to figure out how to structure a global mirror network, but this will have to be done sooner or later. I would also not neglect the privacy implications, with https people deploying passive network snooping have to apply heuristics and put in more effort than simply monitoring http.
Consider the case where someone sitting passively on a network just monitors package downloads that contains a fix for a vulnerability that is exploitable remotely. That passive attacker can just try to race the host and exploit the vulnerability before the update can be installed.
Package signing in debian suffers from problems with the underlying gpg level, gpg is so 90s in that it’s really hard to sustainably use it long-term: key rotation, key strength are problem areas.
-
Package signing in debian suffers from problems with the underlying gpg level, gpg is so 90s in that it’s really hard to sustainably use it long-term: key rotation, key strength are problem areas.
What do you consider a better alternative to gpg?
-
signify is a pretty amazing solution here - @tedu wrote it and this paper detailing how OpenBSD has implemented it.
-
-
-
-
i think alternatives are always good. the only thing where they really differ is that letsencrypt certificates are cross signed by a ca already included in browsers, and that letsencrypt has automation tooling. the level of verification is about the same. i’d go as fas as to say that cacert is more secure because web of trust, but that may be just subjective.
-
-
-
-
-
It would also be nice to be able to compose multiple articles into single books.
-
Writing something that, I hope, will eventually become a text editor, multithreaded and extensible with MoonScript/Lua (or any other language via loadable libraries and external processes). The implementation language is Rust and I’m going to use tokio-rs for async IO and luajit for Lua. At the moment I have a basic rope implementation with Unicode support (including extended grapheme clusters thanks to the unicode-segmentation crate) that can pass some tests. The source code is here.
-
I wonder if there’s some lightweight browser that just displays HTML/CSS webpages and maybe runs some JavaScript on trusted websites, without WebRTC, WebGL, WebDRM and other bloatware that is being baked into the web standards these days, eats resources and extends the attack surface.
Why can’t modern software just do the damn thing it’s asked to without doing anything behind my back?
-
Dillo
Just HTML/CSS2 – no Javascript, “HTML5”, or CSS3 and it’s blazing fast
-
What bothers me is that dillo appears to be unmaintained and has “alpha” SSL support that I failed to enable (the suggested –enable-ssl didn’t work).
-
-
By the way, this is a part of what Ubuntu motd contains now:
The Ubuntu Blog advertising proprietary software? I hope they got paid for it at least.
Wouldn’t want all those crazy Stallmanites hanging around calling them on advertising non-free software, which you can get from their new package manager that caters to for-profit companies.
The word “emacs” doesn’t even appear in the listicle so I suppose it’s just clickbait.