11–20 of 47 posts
Earlier quoted context omitted.
Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR
But > It is disabled by default. Why?
> The below patch fixed the issue: struct { uint8_t dac_state; - int dac_rd_index; - int dac_rd_subindex; - int dac_wr_index; - int dac_wr_subindex; + uint8_t dac_rd_index; + uint8_t dac_rd_subindex; + uint8_t dac_wr_index; + uint8_t dac_wr_subindex; uint8_t dac_palette[3 * 256]; uint32_t dac_palette_rgb[256]; } vga_dac; > The VGA device emulation in bhyve uses 32-bit signed integer as DAC Address Write Mode Register…
I'm fairly certain a real hardware VGA implementation would maintain that index as an unsigned 8-bit value. There's no letting the index overflow, per se. It should overflow back to zero when incremented at 0xFF. The mistake was representing it as anything other than an 8-bit number because that's what the hardware really would have done.
If I had the patience (and a machine close at hand) I'd boot MS-DOS and run thru a little test in DEBUG to see how it acts on a real card to write beyond address 0xFF via the auto-increment feature.
Most of the palette-cycling / setting code I ever wrote just updated the entire palette at once and stopped. I can't think of any particular reason why somebody would want to overflow the DAC write index but it should work. (I suppose there's probably some demoscene code out there somewhere that repeatedly updates the entire palette, outputting to the address write register once then just banging on 0x3c9 repeatedly...)
Earlier quoted context omitted.
But > It is disabled by default. Why?
FreeBSD has a very strong commitment to stability and making things work in new releases that working in old releases. This results in fairly conservative defaults.
Interestingly this is the kind of thing Rust is great at protecting against, and why Firecracker is such a neat project.
How does Rust prevent you from choosing the wrong size for an integer? It's easy to imagine a bug in Rust code in which someone is supposed to write "u8" as in this case, but didn't think carefully and just used "usize" (the most typical integer type used for indices).
> The below patch fixed the issue: struct { uint8_t dac_state; - int dac_rd_index; - int dac_rd_subindex; - int dac_wr_index; - int dac_wr_subindex; + uint8_t dac_rd_index; + uint8_t dac_rd_subindex; + uint8_t dac_wr_index; + uint8_t dac_wr_subindex; uint8_t dac_palette[3 * 256]; uint32_t dac_palette_rgb[256]; } vga_dac; > The VGA device emulation in bhyve uses 32-bit signed integer as DAC Address Write Mode Register…
Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR
Earlier quoted context omitted.
Firecracker also doesn't have this sort of complex device emulation such as VGA, only minimal virtio devices.
At the moment.
(Edit: as far as I know)
Earlier quoted context omitted.
At the moment.
And in the future. The project explicitly does not want to provide anything beyond the things required for it's use case (mostly non computation intensive course servers like used for serverless computing platforms). Part of it's upperformance comes from the thinks they don't support. (Edit: as far as I know)
Earlier quoted context omitted.
Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR
HardenedBSD (FreeBSD fork) has had ASLR and other mitigations since forever. Shawn submitted a patch that was never merged because of mailing list politics or something of that sort + people afraid it was going to break the world. https://reviews.freebsd.org/D473
I suppose you could classify "the patch doesn't work and breaks other things besides" that way.