OpenBSD lectures in Bavaria?
Hello, I'm using OpenBSD when teaching Unix operating systems on University of Ostrava. I'm searching for a teacher or student from University in Bavaria, who is interested to cooperate on a university project with OpenBSD involved. Best regards, Jiří -- Jiri Navratil, https://prf.osu.eu/kip/jiri-navratil/77251/ smime.p7s Description: S/MIME cryptographic signature
Re: vmd and /dev/sd*
Manuel Giraud writes: > Mike Larkin writes: > >> On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote: >>> Manuel Giraud wrote: >>> >>> > > Manuel Giraud writes: >>> > > >>> > >> Hi, >>> > >> >>> > >> I can't find the information on this list (or elsewhere). Is it >>> > >> possible to have a vm that access a disk through its device? The >>> > >> following does not seem to work: >>> > >> >>> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm >>> > >> vmctl: start vm command failed: Unknown error: -1 >>> > > >>> > > No, passing file descriptors to devices over ipc sockets isn't currently >>> > > allowed by the kernel. You'd need to use the raw character device, too, >>> > > afaik if passing them were allowed. >>> > >>> > Ok, noted. BTW I have the same error passing the raw character device. >>> >>> >>> >>> I made the decision to not allow passing of weird file descriptor types >>> very intentionally. I'm still very sure that is the right decision. >>> >>> Here's 1 program which wants to do it, but the other 1000 pledge'd programs >>> are being protected from being passed an incorrect fd and then doing system >>> calls upon it which behave "different". By that, I mean seek, read, and >>> write short-operation behaviours are subtly different outside of files and >>> sockets, and it would also expose some ioctl (which is MOSTLY limited by >>> pledge, but ioctl "request" values are just numbers, and they can overlap in >>> surprising ways). >>> >> >> I would like to make clear that vmd does not "want to do it", and that I >> agree >> that the current design of not being able to pass these types of fds is >> correct. It may be slightly inconvient for certain niche use cases, but not >> worth weakening everything else or putting in hacks. Just dd the device you >> want to a .raw file and use that. > > Thanks for making that clear. I do not understand all the security > implications but you do :) Maybe to prevent future request, you could > have a more explicit error message. I agree reporting "Unknown error" is unhelpful. I don't think having something specific to people trying to use devices instead of files is worth the effort as none of the documentation should be implying that's a feature.
Re: OpenBSD 7.4
On Fri, Oct 13, 2023 at 10:36:43AM +, Laura Smith wrote: > Certainly by all means, track that file on CVS as the "source of truth" but > ultimately there's no certainty until it happens. For more accuracy you could try grabbing a local copy of the CVS repo with reposync and writing a script to carefully analyse the changes to every file across each release ever made, compare them to previous known release dates, do some kind of statistical analysis using a machine learning system, produce a mathematical model that approximates the mental processes of the developers involved, manually adjust the algo for known external factors then compute an estimated release date for 7.4. Or just wait until Monday.
Re: OpenBSD 7.4
> I usually track the following file. > > https://cvsweb.openbsd.org/src/etc/root/root.mail > Ironically, that file seems to support the earlier statement made by Peter Hansteen that he got shot down for (i.e. "The exact date will not be generally known until it happens if recent releases are anything to go by."). Peter was absolutely right, and the CVS shows it, the date is constantly subject to change until such point as the powers that be call time. Certainly by all means, track that file on CVS as the "source of truth" but ultimately there's no certainty until it happens.
Re: vmd and /dev/sd*
Mike Larkin writes: > On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote: >> Manuel Giraud wrote: >> >> > > Manuel Giraud writes: >> > > >> > >> Hi, >> > >> >> > >> I can't find the information on this list (or elsewhere). Is it >> > >> possible to have a vm that access a disk through its device? The >> > >> following does not seem to work: >> > >> >> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm >> > >> vmctl: start vm command failed: Unknown error: -1 >> > > >> > > No, passing file descriptors to devices over ipc sockets isn't currently >> > > allowed by the kernel. You'd need to use the raw character device, too, >> > > afaik if passing them were allowed. >> > >> > Ok, noted. BTW I have the same error passing the raw character device. >> >> >> >> I made the decision to not allow passing of weird file descriptor types >> very intentionally. I'm still very sure that is the right decision. >> >> Here's 1 program which wants to do it, but the other 1000 pledge'd programs >> are being protected from being passed an incorrect fd and then doing system >> calls upon it which behave "different". By that, I mean seek, read, and >> write short-operation behaviours are subtly different outside of files and >> sockets, and it would also expose some ioctl (which is MOSTLY limited by >> pledge, but ioctl "request" values are just numbers, and they can overlap in >> surprising ways). >> > > I would like to make clear that vmd does not "want to do it", and that I agree > that the current design of not being able to pass these types of fds is > correct. It may be slightly inconvient for certain niche use cases, but not > worth weakening everything else or putting in hacks. Just dd the device you > want to a .raw file and use that. Thanks for making that clear. I do not understand all the security implications but you do :) Maybe to prevent future request, you could have a more explicit error message. -- Manuel Giraud
