Notices by Demi Marie Obenour (alwayscurious@infosec.exchange)

@nazokiyoubinbou @dalias 100% agree for stuff like infotainment firmware. For stuff that is safety critical there is an argument that the general public (and any passengers and subsequent owners) have the right to count on safety features not being defeated. I’m not sure where the line should be drawn there.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley People want to run games. How should they do it? “Don’t do it” is not an answer.

If you limit the browser too much, people will just run desktop applications instead, and for stuff that isn’t fully trusted that is a security regression.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley If you are wanting to get performance that is anything close to what the hardware can actually do, you aren’t doing most of the work on the CPU. You are dong it on the GPU, and that is a nightmare of its own security-wise. Oh, and I highly doubt you will ever able to run an interpreter there with performance that is remotely reasonable due to how the hardware works.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley What kind of performance can one get from a type-1 only JIT? If one only compiles to a bytecode then performance is limited to that of an interpreter, and my understanding is that even threaded code is still quite a bit slower than native code (due to CPU branch predictor limitations I think?). On the other hand, compiling to a safe low-level IR (such as WebAssembly or a typed assembly language) and generating machine code from that could get great performance, but that requires trusting the assembler (which, while probably much simpler than a full JS engine, isn’t trivial either).

@hayley @dalias @theearthisapringle @swordgeek @lispi314 JS is a very badly designed language from a performance perspective: every property access is semantically a dictionary lookup, and the JS engine must do heroic optimizations to get rid of that lookup. It’s much easier to write a Scheme or Common Lisp compiler because record type accessors are strictly typed, so they will either access something with a known offset or raise a type error.

@lispi314 @dalias @theearthisapringle @swordgeek @hayley Yup! Duck typing is absolutely horrible from a performance perspective, unless compile-time monomorphization gets rid of it.

@dalias @lanodan @theearthisapringle @swordgeek Hard disagree on SSO, which (combined with SCIM) really is the right way to authenticate to things in an enterprise or government environment. For instance, many U.S. government websites use https://login.gov as the SSO provider, and that really is an improvement over them all managing authentication separately.

@dalias @swordgeek @theearthisapringle For web compat postMessage() still needs to work for PayPal, as does ??? for Google. Might make sense to just hard-code those services as special-cases for legacy reasons, though.

@dalias @swordgeek @theearthisapringle I think the HP Sure Click Secure Browser comes close to that. It’s sadly the only viable model with present browsing engines.

A partial solution is to use a mainstream browser (like up-to-date Chromium) for work that needs to be secure (like managing web hosting) and something else in a VM (ideally Tor) for general browsing.

@dalias @swordgeek @theearthisapringle that’s why you have different VMs for different websites 🙂.

@dalias @swordgeek @theearthisapringle In that case the safest option is to run the browser in a tightly sandboxed VM, so a browser exploit is not game over. That’s what Qubes OS does.

@dalias @swordgeek @theearthisapringle A lot of browser vulnerabilities are JS engine bugs, and those are much harder to mitigate unless one disables JS altogether.

@dalias @swordgeek @theearthisapringle The problem is the security patch gap. If one diverges too far from upstream then one risks not being able to release security patches in time.

@swordgeek @theearthisapringle @dalias I’d avoid downstream forks of browsers unless they have a record of pulling updates from upstream within days of upstream updates.

@dalias 5 requests per 10 seconds seems like something that a human could easily be hit by accident when looking through commit logs.

@dalias Are you thinking of specific functionality or just overall priorities?

@gregkh @sima @sourcejedi Is this because dev_t was 32 bits back then?

@gregkh @sima The problem is that whether a device should be trusted depends on what slot it is plugged into 😞. Are there systems that do expose slot information? If so, which ones are they, and is there a way for userspace to get it on these systems?

@gregkh @sima @sourcejedi Even if the path is never reused, the device major and minor number can still be reused. Right now I think one needs a custom FUSE filesystem if one wants opening e.g. /dev/disk/by-diskseq/1 to be race-free, and that’s bad.

@gregkh @sima Some more questions:

1. Which entry in sysfs correspond to physical (as opposed to logical) topology? Is it the path under /sys/devices?
2. How can I go from this path to a PCI bus/slot/function?
3. Will this path change when other cards are added or removed or if the system firmware is updated?
4. Is there a way for driver probing to be deferred until after userspace can check the device against the actual topology of the machine? That would allow checking if the device that claims to be a serial port in slot X is actually supposed to be a serial port, or if it is a GPU passed through to a VM that the VM compromised and is now pretending to be a serial console. In the latter case the device would never be allowed to be used except for passthrough.