11,905 karma · joined May 21, 2009
Source? I haven't heard about these vulnerabilities.
In a kernel, there are several places where Rust won't help you. There are certain things you have to do that are going to need unsafe code, and need to be audited just as much as code written in any other language. The kernel is also a place ripe for logical vulnerabilities to creep in; it is the main arbiter of what is allowed and is not allowed from processes, so many possible vulnerabilities are logical, not memory safety issues.
On the other hand, when a kernel gets complex enough, there are places where memory safety or thread safety issues can come up even in code which doesn't require particular unsafe features and which is not involved in a security role; just things like manipulating complex data structures in multiple threads. This kind of code is the kind of code in which Rust can help catch issues; and it definitely still happens even when very good programmers, with good code review, work on the kernel.
Rust is not a panacea; it is not a cure-all. But it reduces the attack surface considerably, by containing the amount of code that is exposed to certain very common classes of bugs.
And besides logging, there are things like nanosleep or spinlocks which may briefly spin while querying the time before yielding.
I know of at least one CDN which was measurably impacted by the gettimeofday issue.
And yes, you could have the access to the address itself be something you are given access to via a capability/handle, but then the system call itself (which is actually a vDSO call) wouldn't have to actually take a handle as a parameter.
And the borrow checker, along with move semantics by default and the Send and Sync traits, help with several other aspects of safety as well; the Send and Sync traits encode information on what can safely be moved or shared between threads, and move semantics by default (and checked by the compiler, instead of at runtime as in C++), make it easier to encode state transitions on objects in ways that you can't try to perform operations on an invalid state.
But as others point out, Zircon, the Fuchsia kernel, was written before Rust 1.0 was released, and even after Rust 1.0 was released and stable it was still a bit rough to work with for a little while.
If you were starting a new project from scratch today, I'd seriously ask why not Rust, though of course there are other reasons why you might not choose it. But given the history, and how new Rust was at the time when this project was started, it makes a lot of sense.
Is there a way that these could mediated by a capability without having to incur syscall overhead? One of the reasons that these are bare functions is likely that they are in the vDSO, and are just simple function calls which can access some shared memory which contains the clock time. I suppose you could simply not give some processes access to that memory, and have the functions in the vDSO just return an error in that case.
I know that there was a time when the Linux kernel changed how their vDSO handling worked, so older glibcs would have to fall back to making an actual syscall for gettimeofday, and that seriously affected performance on some servers that updated the kernel without updating glibc. These functions are called quite often on servers for logging purposes, so adding overhead to make them go through a syscall can be a big performance hit.
> I'm hesitant to endorse any system calls with ambient authority, even if it's scoped by context like these. It's far too easy to introduce subtle vulnerabilities. For instance, these calls seem to permit a Confused Deputy attack as long as two processes are running in the same Job.
Yeah, this is a bit odd. In fact, it's not just these syscalls which have ambient authority, there's a whole list in https://fuchsia.googlesource.com/zircon/+/master/docs/syscal... and it includes VMOs, ports, sockets, and so on.
It does seem somewhat odd to have this capability system, but then ignore it for a number of actions which can only be limited at the job level.
From my reading so far, it looks like Fuchsia takes some of the better parts of the POSIX model, the way file descriptors can be uses as capabilities, and extends its usage more consistently over the API so that it is used in a lot more places. In Fuchsia they are handles, which are arbitrary 32 bit integers, but they act a lot like somewhat richer, more consistent file descriptors. You can clone them, possibly with limited rights like read only, you can send them over IPC channels, etc.
There are some differences, in that there's no absolute path handling directly in the kernel; instead, you always open relative to some particular file handle. A process may be given two that can be used to emulate POSIX style path resolution, by being given a root directory handle and a current working directory handle, though there may not be a guarantee that one contains the other; it sounds like more commonly application will just be given handles for the files or directories they are supposed to access, rather than having everything go through path resolution.
Signal handling is done consistently with waiting for data on handles; handles just have various states they can be in, like ready for reading, ready for writing (for file handles), running or stopped (for process handles), etc, and you can wait for changes of state on any of a variety of different handles.
Memory mapping can be done by allocating a virtual memory object, which you could either not map (treat it as an anonymous temporary file), write to, and then pass to another process, or you could map it into your process, manipulate it, clone the handle, and pass that to another process. Basically seems like a cleaner design for shared memory handling than POSIX, though something a lot like it can be done in Linux these days with anonymous shared memory and sealing.
Jobs, processes, and threads are also all handles. Jobs contain processes and other jobs, and processes contain threads. Jobs group together resource limitations (things like limits on numbers of handles, limits on total memory used, bandwidth limits, etc), processes are separate address spaces, and threads are separate threads of execution in one address space. The fact that jobs and processes are all handles, instead of IDs, means that you don't have to worry about all of the weird race conditions of trying to track things by PID when that PID may no longer exist and could be reused in the future.
An interesting part is how program loading happens. In POSIX like OSes, you fork your process, which creates a clone of the process, and then exec, which asks the kernel to replace the running program with one loaded from another file. You give the kernel the path to a file, and the kernel calls the dynamic linker on that path to link the shared libraries together and then execute the result. In Fuchsia, you just build the new address space in the parent process, and then ask the kernel to start a new process in that address space, with execution starting at a particular point in it and some parameters loaded into particular registers. This basically means that the dynamic linker will now be done by a library call in the parent process; which could be really advantageous for those processes that fork the same executable as a subprocess many times, as they can link the executable once into some read only pages, and then very quickly spawn multiple processes from that same already linked program. I'm sure that ld.so and friends on Linux and other POSIX-like OSs have a lot of caching optimizations to make this faster, but it sounds to me that the Fuchsia model of just having the parent process do the linking as a library call could be a lot faster.
(edit to add: hmm, upon further reading, it looks like they expect process creation to happen from a single central system process, rather than providing the dynamic linker API, "launchpad", as a supported API; but for now it looks like you can use the launchpad library)
It basically looks a lot like what you would wish the POSIX API worked like with a lot of hindsight. A lot simpler and more consistent, and does a much better job of "everything is a file" than the POSIX API ever did (of course, it's "everything is a handle," but that's fine, the point is that there's one consistent way to work with everything).
Not being POSIX doesn't mean it's going to be entirely foreign or that it will have no compatibility with software that is already written for POSIX-like platforms. It just means that the basic process management, IPC mechanisms, permissions handling, and so on uses a model which is akin to a cleaned-up subset of POSIX; everything is done via handles, which are a lot like file descriptors but work in a somewhat more uniform way, there is cleaned up management of resource allocations to jobs, memory mapping of processes, and thread management, and so on.
It's not terribly hard to build a POSIX-like layer on top of this; said layer isn't necessarily going to support some of the real warts of POSIX, like the really broken way signals work in POSIX, so some software that intimately depends on this may have to be factored out to support the way that Fuscia handles signals, but for most software this will be a big improvement. Software on POSIX systems nowadays has to jump through hoops to make signals play well with event loops, frequently allocating a pipe that gets written to in a signal handler, so the event loop can pick up that notification later, while in Fuscia that's how signals already work, it's just a state change on a handle that can be waited for in Fuscia's equivalent of select/poll. So in cases like this, Fuscia will add a new code path that is simpler and more maintainable than the one on POSIX-like systems.
It has some convenience functions for decoding files given a path or FD, but I'm sure Fuscia's limited POSIX compatibility layer will support that, basic file access is relatively easy to provide in a POSIX library wrapping Fuscia's file handling.
Likewise, I'd be willing to bet that curl and Git would mostly work on top of the limited POSIX compatibility layer; they might need a few tweaks, but likely not much more than the tweaks needed in porting to the various BSDs and OS X, and likely a lot less than is needed to provide them natively on Windows.
In a hierarchical system, a lot of these organizational issues are local. If I have one directory that consists of a project organized one way, and another directory that consists of a different project organized a different way, those different organizations don't really interact with each other in any way.
If you are using tags for everything, in order to avoid weird mishmashes of different ways of using tags, you would need to either have a completely standardized tagging system that everything used consistently, or you'd have to always include various contextual information in your queries or in your browsing in order for the queries to make sense. For instance: [mount: my-hd][project: my-project][type: jpeg]
I think you overstate the problem with different applications as well. For a large amount of the metadata that is relevant for these applications, there is a standard tagging system. ID3 for music, EXIF for images, XMP for various image and video formats. It's true that there is some metadata that these applications store in proprietary databases, but that's mostly an issue of it being difficult to come to a consensus on standards that meet everyone's needs, and it's easier to just write some proprietary metadata somewhere. With tagging systems, if there wasn't agreement on the schema of tags, you'd still have the same issue.
I don't think it's a bad idea to consider alternatives that are more general and more flexible than what we're doing now, but I do think that it's pretty easy to handwave about how nice a tag based system would be, but a lot harder to solve all of the little problems that are going to come up and turn it into a real, coherent, working whole, and then getting enough critical mass so that it is used outside of a small niche with a handful of applications.
1. Inertia. Most software assumes hierarchical filesystems, and assumes it can control some portion of that hierarchy. This includes things ranging from search paths for various things ($PATH for binaries, library paths, etc), temporary files, preferences files for applications, assumptions made about hierarchical filesystems in archive formats like ZIP and TAR, etc.
2. Permissions. With a hierarchical filesystem, you can apply permissions on higher levels of the hierarchy to control access to lower levels, and you can have various forms of permission inheritance to control permissions on new files. Need a design for how to do that on tag filesystems.
3. Mounting. Filesystems come and go; some are on your OS drive, some are on removable media, some are network filesystems. Hierarchical filesystems means that each one has a single root, and it's easy to tell where the boundaries are.
4. Tagging taxonomy. What kinds of tags do you use? What happens if you mount a filesystem in which someone else used a different tagging taxonomy than you used? Who controls different parts of the tag space? What happens if you import an archive of material which uses a different tagging scheme than you use?
5. Projects. How do you group files of different types with different tags into discrete projects? How do you bundle related files together? How often would you want to see files by arbitrary tag lumped together, rather than looking in particular projects that have a pre-defined structure?
6. UI. How do you browse tags? How do you refine down? In many cases, rather than a general purpose tags based interface, you actually want media-specific browsers, like ones specialized for music which let you browse by artist, album, playlist, etc, or photo galleries that can show you previews of the photos, or video browsers which can show projects, bins, and sequences (for video editing), or IDEs which can either show you file hierarchy or allow you to browse by class, function, etc.
7. And finally, why is a tag-based filesystem necessary for this? What is wrong with the current approach, in which there are special purpose applications which can index, tag, and display certain types of media in certain ways? For instance, you can use your text editor or IDE to navigate among files within development projects, iTunes or Play Music or whatever to browse your music, Lightroom or Darktable or iPhoto or Google Photos to manage your pictures, iMovie or Final Cut or Premiere or Avid for browsing and managing your video, and so on. They all frequently have some way of tagging files, but also have specialized UIs for browsing the specific types of files they are defined for without having to do explicit tagging, and the actual files are just stored on a normal hierarchical filesystem.
There are a couple of good thoughts in the original post, but a lot is handwaved away, such as mutability of files, which is an incredibly important use case, for a huge amount of what files are used for today. Lots of people have brought up the idea of making tag based or database based filesystems, such as the failed WinFS effort (https://en.wikipedia.org/wiki/WinFS), but it's actually a pretty big problem to solve.
If it's something only a small fraction of the customers actually bother to do, it doesn't dig into their profits too much.
It effectively acts as another form of market segementation. There is a mostly fixed cost for flying an airplane; the marginal cost per passenger is relatively low. So ideally, you would have a paying passenger in every seat. Some passengers are more price sensitive than others, so you want to have the less price-sensitive passengers pay as much as possible, while still providing ways for the more price sensitive passengers to get fill up seats that are still available after that.
People who are willing to go to the trouble of doing this will happen, but you're still making money off of filling seats with paying customers, they're just acting as slightly more price sensitive passengers.
The airlines fluctuate rates for just this reason; they want people to be able to buy tickets at different prices, so price sensitive passengers can go to a little more trouble to book earlier or take bigger risks by flying standby or waiting for the price to go down if it's not appropriate, while less price sensitive passengers will just buy the ticket whenever convenient.
If this were being seriously abused a lot of the time, or there were automated systems which booked trips like this for you, I could see the airlines doing something about it, but if it's just a few people going out of their way to get a slightly better price, it's probably just considered to be part of the whole ticket pricing game.
Erlang and JavaScript come much much later on in the evolution of programming languages; Erlang originated in the late 1980s, and JavaScript in 1995.
This particular location has the sidewalk end on one side, and there is a paved section in the median which looks like it is intended for crossing. There is a small sign that indicates that you should not cross here.
From the video, we can see that while there were street lights on the road, the area in which the apparent crossing existed was completely dark. A pedestrian may not have been able to see the sign indicating that you shouldn't cross here; or even if she did, there are so many roads that are built in pedestrian unfriendly ways that sometimes you just have to cross at unmarked crossings to avoid having to go substantially out of your way.
Additionally, the video shows that the driver was distracted immediately before the crash. While the dash cam video seems to indicate that you can't see the pedestrian until it was probably already too late, human eyes are a lot more sensitive over a greater dynamic range than most video cameras, so there's a good chance that if the driver were paying attention, she would have seen the pedestrian before the car did.
The thing about safety systems and standards are that there should be some redundancy in them. People make mistakes, so you shouldn't have to rely on every actor acting perfectly to remain safe. In this case, there was a failure on many parts leading to a tragedy.
It's definitely worth investigating whether Uber had done enough to ensure that operators will be staying alert during the entire test, and whether Uber had done enough testing before being on open roads of small, possibly moving obstacles on dark parts of the road, like pedestrians, deer, and so on.
I'd also put a good amount of blame on whatever department designed that portion of road and sidewalk.
But what it comes down to is, there was something about the accuracy during the first 12 hours that gave the FDA cause for concern. Whether the FDA is overly cautious or not is an open question; I do know that in the US we get worse health outcomes for more money than most other developed countries. How much of that is due to our terrible system for paying for health care, which is privatized but with enough regulatory capture and inefficiency to drive prices way up, and how much of that is due to higher costs and lower access to medication and devices not being available due to excessively stringent regulations from the FDA would be something interesting to study.
I think that the FDA could probably loosen up its regulatory process just a little bit and provide a net benefit. Not sure with how much there is wrong with health policy in the US, and partisan politics around it, that's very likely, however. It would be interesting to see if there have been any studies done on this.
There are many users who would not. They might make a rash decision based on that data. If the data is in Zone B a larger percentage of the time in testing, in much wider general use there will likely be cases that weren't caught in clinical trials in which it could land in Zone C.
During this 12 hour calibration window, you can still use fingersticks, which you have to do for calibration purposes with other CGMs anyhow. And it likely would be a fairly minor change for them to support doubling up on sensors, so that you could overlap them in order to avoid the 12 hour window; but that change would require further testing and approval, so for now the 12 hour calibration window is left in. It was only fairly recently approved with this 12 hour calibration window, so I wouldn't be surprised if the company is working on support for pairing two sensors to one device to support doubling up like this.
Because the FDA is very conservative, in part because that conservatism prevented the thalidomide incident back in the day.
When it comes to novel treatments, or monitoring devices, we don't know what we don't know. The FDA errs on the side of well-tested treatments and devices.
Extra inaccuracy during the first day could lead people to make mistakes that could prove dangerous or fatal. You don't have no data during the first 12 hours, you just have to fall back to the fingerstick method, which the FreeStyle Libre still supports.
It's possible that as more data is gathered in Europe and the US, it could be found that this extra inaccuracy is not harmful, and the European version approved in the US. Or it could be that the company is able to improve the device to improve accuracy in the first 12 hours, and get a new version approved.
It seems to me that other CGMs like the Dexcom require fingerstick calibration at lest twice a day, so I would think that 12 hours of having to use a fingerstick during calibration would be preferable to twice a day fingersticks.
It looks like on the first day, comparing blood glucose with FreeStyle Libre CGM, there was a significant difference in accuracy, with a lot more (~20% more) readings falling into "zone B", or "points that are outside of 20% but would not lead to inappropriate treatment" (chart https://www.liebertpub.com/action/showImage?doi=10.1089%2Fdi..., from paper https://www.liebertpub.com/doi/pdfplus/10.1089/dia.2014.0378).
This is just one quick thing I found on Google Scholar.
Given that this CGM can also act as a regular fingerprick blood glucose monitor during that 12 hour overlap, I think the FDA likely wanted to err on the safer side of using well known and well tested methods for monitoring to avoid any unexpected issues. Is there sufficient evidence of the benefit of CGM over fingerprick tests to believe that this caution could cause actual harm?
Well, a quick search of Google Scholar turns up at least one citation in which the Freestyle Libre CGM was significantly less accurate in the first day of use than in later days, indicating that it needed more time for proper calibration:
https://www.liebertpub.com/doi/pdfplus/10.1089/dia.2014.0378
I expect that the differences are based on some actual findings, not just "unclear reasons," but you may have to do some research to find out.
The FDA is notoriously cautious, possibly somewhat excessively so, but there is some good reason for that caution; medication and medical devices can have unexpected behavior and side effects and it can take a lot of long term study to find them. One example of the caution working out well is the Thalidomide case, which was approved in many other jurisdictions but not in the US, and which had significant side effects on fetuses.
For instance, there are accidents that cause deaths all the time; but they would only be prosecuted as manslaughter if someone were doing something considered inherently unsafe and unlawful.
If you run a red light, and kill someone in the process, it's possible you could be prosecuted for manslaughter, though even then you might not be if there could have been extenuating circumstances (sun in your eyes, etc).
In this case, there would only be a chance of a manslaughter charge if Uber were somehow being particularly negligent. In this case, it sounds like there was a human operator in the car, though the car was in autonomous mode. It's possible that the operator wasn't paying the attention that he or she should have been, or it's possible that even the human operator didn't see the pedestrian in time. It mentions that the pedestrian was crossing outside of any crosswalk, so it's possible that this was a tragic accident of them trying to cross a street with traffic without having been sufficiently careful.
On the other hand, it mentions a bicycle, but also says the victim was walking, which I find odd:
"Elaine Herzberg, 49, was walking outside the crosswalk on a four-lane
road in the Phoenix suburb of Tempe about 10 p.m. MST Sunday (0400 GMT
Monday) when she was struck by the Uber vehicle, police said."
Local television footage of the scene showed a crumpled bike and a Volvo
XC90 SUV with a smashed-in front. It was unknown whether Herzberg was on
foot or on a bike.
Unless the operator was being particularly negligent, or there was some serious and known problem with the self driving car but it was put on the road anyhow, I doubt any manslaughter charges will be filed.
Remember, Arizona has explicitly been encouraging the testing of self-driving cars, so I expect that testing a self driving car, with an operator to take over in cases which it can't handle, would not be considered unlawful or extremely negligent. Maybe what the operator was doing could be, but we'd need more information before it would be possible to tell.
I don't know. I have a hard time with calling Chelsea Manning a true hero. While some of the information that she leaked was useful in exposing war crimes, there was a lot more that wasn't particularly relevant exposing military abuses, but was used by enemies to track down and kill those who were collaborating with the US.
> in order to put more unaccountable government power in the hands of people like Donald Trump
I'm not sure how what Adrian Lamo did would have given more power to Donald Trump. In fact, it's Wikileaks that ultimately wound up being critical in the election of Donald Trump; by dumping a lot of not particularly noteworthy private campaign emails, but which could be picked through and made to extend some controversies and conspiracy theories around Hillary Clinton, it was one of the key factors in getting Donald Trump elected.
While there has been some good, newsworthy information released on Wikileaks, it seems to have been corrupted by Russian influence, has a lot of alt-right tendencies including antisemitism (https://theintercept.com/2018/02/14/julian-assange-wikileaks... ); I think that overall, it has become a net negative on the world.
From what I can tell, Chelsea Manning meant well, did some good, but also did a lot of damage, including substantially raising Wikiseaks' profile. I think that whether to report the conversation with Manning to the authorities was likely a difficult one, but the concern about leaking significant amounts of non-newsworthy but potentially quite dangerous information was well founded.
> Did he commit suicide
I don't think that's been revealed; but his Wikipedia article reports on several past struggles with substance abuse. Based on that, and general statistics on causes of death at that age, suicide, overdose, or motor vehicle accident seem like the most likely causes (https://www.cdc.gov/injury/images/lc-charts/leading_causes_o... for the leading causes of death, https://www.cdc.gov/injury/images/lc-charts/leading_causes_o... for the breakdown of the injury deaths by cause).
Yes, this is why I say that I know this is a losing battle.
I mostly care about it in the context of technical forums like Hacker News. While the word may have a different meaning for the population at large, when you're having a discussion on a technical forum you should generally try to learn how words are used in that context.
This is somewhat like the different meanings for the word "theory" in a scientific context and in general use. In general use, "theory" means an idea that may not yet have been tested or proven, somewhere around the meaning of "idea", "hunch", or "hypothesis", while in a scientific context "theory" indicates something that has been tested successfully and is well accepted.
While the use of "theory" in the broader sense is well accepted in general use, using it in that sense in a discussion about scientific theories is confusing; so if someone does that in such a discussion, I am likely to point out the stronger meaning of the word in scientific usage.
So likewise, while "crypto" as an abbreviation of "cryptocurrency" is already fairly widespread (though I think still niche enough that there's a tiny chance a concerted effort could change usage patterns), I at least want to make sure that folks getting involved in technical discussions are made aware of the earlier definition of "crypto" and are made aware of the confusion that can be caused.
Using "crypto" to abbreviate "cryptocurrency" causes a lot of confusion, as the "crypto" in "cryptocurrency" was already an abbreviation; "cryptocurrency" is short for "cryptographic currency."
People who know nothing about cryptography or even that cryptocurrency uses cryptography get confused if they are looking for information about cryptocurrencies and instead find more general purpose resources on cryptography (like https://crypto.stackexchange.com/ or https://www.reddit.com/r/crypto/).
I know that this is a losing battle, like getting people to stop using "wiki" as an abbreviation for Wikipedia (which is just one out of many wikis), but I figure that as long as we're talking about people not knowing much but investing in it anyhow, I really encourage everyone to stop using "crypto" as an abbreviation for "cryptocurrency."
We are definitely in a very hype driven cryptocurrency bubble right now, and there are a lot of naive folks who are probably going to lose money to it.
And yet somehow, we haven't really managed to make any cryptocurrencies an actual, widely accepted, payment alternative, for anyone other than a few people with special circumstances (government restrictions on currency exchange, criminals demanding ransoms, funding organizations that governments are trying to shut down) or people who are fairly technically competent.
There's a chance the lightning network could be the last piece of the puzzle to make cryptocurrencies actually usable for payment, though even still, I have a hard time seeing most places wanting to accept payment in an asset as volatile as Bitcoin.
Or maybe we'll see a coin backed by fiat currency and real, regulated banks on Stellar, where you don't have nearly the same scalability issues nor gigawatts of power wasted just to try to solve Sybil attacks. If you have a coin backed by fiat currency, and low transaction costs, businesses are a lot more likely to accept it as payment as most of their expenses, taxes, debts, and so on are in the local fiat currency rather than than in any cryptocurrency.
Some of these previous efforts might have one or two of these features, but none of them meet all of these criteria.
OK, they are flat bubbles now rather than shiny blobby ones, but it's the "bubble for everything someone says" that makes it look dated.
I hated the "bubbles" look back then and always used themes that just presented text as text, with possible unobtrusive delimiters between people's comments. Like Slack and Discord do.
In this case, there is no discussion about the article, just about the upvote brigade. So the only reason for sharing the link to the HN discussion would be to get people to upvote it.