Hacker News Reader

Comment by rwmj | Hacker News Reader

I really hate the error message from shim (or SB in general) when a security check fails. At tell me what exactly failed and what I could do to fix it.

View on HN

I hate error messages from most software. Recently my system failed to boot because systemd told me a start job is running for a certain disk. And it doesn't tell me what the nature of the start job is, why the start job is needed, and why the start job is not finishing. From the disk UUID I could guess the first two, but there was no way to guess the third.

Seems to be a general trend in a lot of software nowadays. Vague error messages telling you "Something went wrong" with no additional details.

It's not a new trend - error-code based software would propagate that ERROR_INVALID_PARAMETER all the way from the function with the invalid parameter back out to the return value of the user operation, then helpfully tell the user "Invalid parameter!"

Exceptions with string messages and full stack traces might be yet another underrated Java invention.

Dr Watson is still a thing for getting tracebacks. Doesn’t work for kernel mode of course, but most things don’t.

Do you ask your users to run some weird debug tool when the dialog box says "Invalid parameter!"

Does it help? The stack trace at the point where the dialog box is displayed is useless.

God that error is nearly useless even to the developer. Last couple of times I've gotten it, I've dropped the DLL that the error originates from into Binary Ninja and run the debugger to figure out which parameter failed a check.

Even that at least helps rule out the most common issues, and is less frustrating than an update pooping out 0x80070070 and making you manually translate it to ERROR_DISK_FULL.

I've most recently embraced more complex error objects. It's quite a feeling to get an error description a la

  Failed to open configuration file
  Caused by: 
    Failed to open path PATH
    Error access denied

I grew up with "System Error Type 11" (or whatever the exact quote was, hard to find on google).

I think the only button on the dialog box was "Restart".

One of the humorists I worked with at Bell Labs in the 1980s would always report error code 13 as the error when no more specific error code was available. When one looked that up in the man page, it just said "you are unlucky".

Something went wrong frowning smiley. Our engineers are probably working hard on fixing it right now.

This is why I strongly prefer working on software made by developers for developers. That is to say, internal tooling. You can just show the entire error message in as much detail as possible, without a PM stepping in and saying you can't show this much scary text to the typical user. Especially if the user of the software also has easy access to your source code so they can search for the exact string and find the exact location of the error, and understand exactly what checks are being done to emit that error.

There's two directions that goes into. Highly specialized error codes with zero results on search engines, or overly generic errors with a billion results and underlying reasons.

Error design needs to be its own subject / specialization. Errors need to say what the problem is and how to fix it, in an ideal world, or what the user can do or should google to solve it.

And of course, any error code of any public software should be listed on a website or a locally accessible resource.

This is where I really love mainframes. The errors all contain a consistent code and a description. The codes are all published, are easy to find nowadays, and have generally good documentation attached to them.

Here's an IBM example, for just a single OS facility: https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/hasa100_v2r4.pd...

Good error messages are hard. You want to tell the user what to do, but if you knew that the error could be thrown, you probably should have been gracefully handling the problem. You don't know what information is useful to a hacker and you don't know how your error will be propagated. Meaningful errors at one level ("incorrect parameters passed" when calling an API) is perfectly useless at another level ("incorrect parameters passed" when interacting with a React UI). And if you respect all of the above, at some point you'll end up with an error message that basically says "I can't tell you what, why or how something went wrong, but it did."

all information is useful to a hacker. if you can find a way to use information beyond creators intent, to achieve your goals regardless of hat color, you are hacking.

shim has an EFI variable to control its verbosity, you can set it to output all the gory details with e.g. `mokutil --set-verbosity true`, and on a glance there are some tools on Windows too to modify EFI vars

Why wouldn't that be the default?

Because most users are afraid of gory details. And the people who know enough to fix it are expected to somehow know how to turn on logging. It's the modern equivalent of "please contact your administrator"

The first thing the "administrator" will need is all the details. If they were printed, the person reporting could at least send a screenshot or similar.

Handy for the 7 people in the entire world who a) knew this existed and b) bothered to change it.

(Realistically I expect that's mainly used for debugging purposes for the Shim authors.)

Or at least include a URL to a web page explaining the error and what you can do about it

I think Windows BSOD including QR code was pretty clever idea, although unfortunately it's halfbaked in that it's just a fixed generic URL instead of something specific to the error.

The problem with bootloaders is they really can’t spare a lot of storage. Storing different QR codes for all the common errors might be asking too much.

Currently EFI partitions are on the order of 300-500 MB for common installs, that'd allow you to store millions of PNG-compressed QR codes.

Or even better, a small library which'd allow bootloader to generate it on the fly.

On my system the full qrencode binary is 85K, and it supports a lot more output formats than needed in this application.

http://fukuchi.org/works/qrencode/index.html.en

That said, with iPhone cameras supporting live OCR and URL detection, a QR code would be unnecessary.

You don't need to store the whole QR code, just code to convert an URL into a QR code. Or a good, short URL that can easily be typed, e.g. "microsoft.com/errors/1234"

A 50 character capacity QR code requires a whopping 137 bytes to store as a raw image.

No please don't do this. I have lost count how many times I tried to follow a link only to get a 404 page. If there is an issue where the app gives the user an error, show the error details & context directly and list the possible mitigation steps right then and there.

A URL with specific content is just another thing that now needs to be maintained along with the code and failure modes.

If security vendors followed this logic then all an attacker would have to do is look up the error and render the security moot.

By leaving the reason vague an attacker has no immediate feedback and no clue how to remedy.

I vastly prefer the way this works now.

The only way this could be an issue is if it's entirely relying on security through obscurity.

Attackers are smarter than you give them credit for

I believe humans are vastly more stupid than you give them credit for.

It's the HN effect. The pool of geniuses here suggests to the reader that the pool of intelligence outside of this microcosm is similar. It's not.

Criminals are overwhelmingly stupid. It's why LEO catches so many of them. Smart people don't tend to do crime, they tend to sell their skills to more legitimate enterprises.

You are vastly overestimating the intelligence of the people on this site.

Reply on news.ycombinator.com