Re: boot disk ???
PJ af.gour...@videotron.ca writes: ... It's not I who is having problems. I think it's OpenBSD. Assigning blame before resolving the problem is counter-productive. It doesn't take much to look at the contents of the ISO file and see that it won't boot. But I guess I'm a glutton for frustration and I was just laughing at myself. Now what. The only evidence you've produced here indicates your bios didn't like your CD. There's a rather large tree of possibilities for what could cause this - most of which have nothing to do with OpenBSD. You're right, it doesn't take much to look at an ISO image. Have you verified that your burned cd has the same checksum as your downloaded ISO file? So what did you find when you looked at the contents of your cd? Are there tar balls? kernels? el torito boot image? This is a great start for a new system. Temper, temper. -Marcus Watts
Re: AHCI License?
Date:Thu, 16 Apr 2009 09:41:04 PDT To: misc@openbsd.org From:J.C. Roberts list-...@designtools.org Subject: AHCI License? I was looking into AHCI stuff this morning and found something kinda disturbing, namely the fact Intel requires a license for AHCI. The real trouble is I can't tell if they *only* require it for hardware/chips, or if the require the license universally i.e. including the OpenBSD software support for AHCI. Where would a virtualized HBA supporting AHCI fall on the infamous hardware/software dividing line? If anyone would be kind enough to beat me with a lawyer clue stick, it would be much appreciated. -jcr Lawyers like to make claims that are as sweeping as possible. There are lots of business/legal reasons for this. Ask a lawyer if you really want to know why. There's a fair amount of US case law regarding look-alike implementations of hardware and software. Again, if you want the full scoop talk to a lawyer. Or several. This is definitely a matter of continuing controversy - see previous paragraph. As a practical matter, I think this is true: the *names* of things can be protected as trademarks the *documentation* of things can be protected via copyright *access* to documentation can be controlled via licensing some companies like evil licensing, including nda's, contractual entanglements, etc. *novel ideas* can be protected via patent. *paper forms* and similar interfaces cannot be protected by any of the above So AHCI is a trademark. AHCI proper, as an interface, looks and acts like a paper form. So I think you can implement something that looks as much like AHCI as you care -- provided you don't call it AHCI, don't use any unobvious ideas, and haven't signed any evil licensing. You might succeed in calling a virtual software interface AHCI compatible if it doesn't use hardware, provided you aren't obviously competing with Intel, and that their lawyers don't take offense. Given that Intel sells chips that implement VMD, it doesn't appear to make business sense for them to object. Since I'm not a lawyer, my advice is of course worth every penny you paid me. :-) -Marcus
Re: Ramifications of blocking SYN+FIN TCP packets
J.C. Roberts list-...@designtools.org writes: ... I know SYN+FIN is a valid packet according to RFC 793 and 1644 (T/TCP), but the more important question is, what are the valuable *uses* for SYN+FIN packets? Personally, I can't think of any valuable uses. Can you? ... There is a use actually. If you want to do minimal packet count transactions, then you want this. Here's a better description, http://www.sean.de/Solaris/ttcp.html I don't know of anything that requires this, or even makes it possible to do this in a rational way. A smart tcp based rpc mechanism, or perhaps sort of odd http application (embedded controllers on slow network segments?) might be candidates for this kind of logic. -Marcus Watts
Re: Can someone please suggest a replacement for xterm for me?
Date:Fri, 06 Mar 2009 16:24:52 GMT To: misc@openbsd.org From:Matthew Szudzik mszud...@andrew.cmu.edu Subject: Re: Can someone please suggest a replacement for xterm for me? On Fri, Mar 06, 2009 at 02:16:05PM +0100, frantisek holop wrote: hmm, on Fri, Mar 06, 2009 at 11:45:49AM +, Matthew Szudzik said that PRIMARY. So, if you've copied something to the CLIPBOARD in firefox, then you won't be able to paste it in xterm. i disagree. shift+insert No, Shift-Insert does not work. Suppose you've copied String1 to the CLIPBOARD in firefox. That is, you've highlighted String1 and pressed Ctrl-C. Then suppose that you highlight some other string String2. (For example, you may have gone to the firefox Save Page As... dialog box, which automatically highlights the title of the current page.) Now, if you go to xterm and press Shift-Insert, you do not get String1 which is in the CLIPBOARD, but String2 which is in the PRIMARY. That's the problem! You can paste the PRIMARY to xterm, but you cannot paste the CLIPBOARD to xterm. (Unless you use xsel.) Recent versions of xterm (237, 242) have some new options you might find helpful. control-center-button brings up VT options, then just past Allow 80/132 Column Switching, there are 2 new options: Keep Selection, and Select to Clipboard. I think the 2nd of these might cause xterm to behave as you wish. -Marcus Watts
Re: umts need help
Didier Wiroth dwir...@gmail.com writes: ... Mar 5 22:43:01 406334G chat[9395]: send (ATZ^M) Mar 5 22:43:01 406334G chat[9395]: expect (OK) Mar 5 22:43:01 406334G chat[9395]: TZ^M^M Mar 5 22:43:01 406334G chat[9395]: ERROR^M ... Unfortunately these AT commands are chinese to me, ... Wow, people don't know modems anymore. Here is a fair description of the hayes command set: http://en.wikipedia.org/wiki/Hayes_command_set You should definitely experiment. Use tip. Just because the company went bust doesn't mean you should leave this to the chinese. You should pay particular attention to how the AT command prefix operates, the use of +++, and on-hook vs. off-hook oeration. You might also care about S registers and dial strings, but those vary. If this were a real modem I'd suggest listening to the speaker too. The time temperature lady used to be a good choice for this. The general problem you want to solve is: given any state this device might be in when you connect, get to a known state, then get it to whatever final state. So, some states the device might be in: online connected offline connected offline idle offline connected, at issued offline idle, at issued (and if you want to be particular, offline 'a' issued is also a state.) the stuff you had in your chat script (and other parts of the hayes command set) is supposed to deal with various cases, so, some common choices, (1 second delay)+++(1 second delay) if the modem is online, go offline. (you'll need to include a delay, and you'll have to suppress the trailing cr to make this work with chat.) \rATZ\r if the modem had previously gotten an at prefix, issue a null command. then reset the modem, which will hang up, and restore initial settings. In the case of your ERROR message - probably something had previously managed to issue AT but hadn't sent a trailing \r. -Marcus Watts
Re: spamd - 250 return text
writes Tom Bombadil [EMAIL PROTECTED] Subject: spamd - 250 return text ... Short of recompiling spamd, is there any undocumented way of changing the 250 responses from spamd? ... Sure. It's called bvi. -Marcus Watts
Re: calling syscalls directly from asm
Date:Sat, 14 Jul 2007 18:48:46 +0200 To: misc@openbsd.org From:Vincent GROSS [EMAIL PROTECTED] Subject: calling syscalls directly from asm Hi folks, I would like to call write(2) without going through the libc functions. I wrote this little thing to test, it does not print anything, but friends say it works just fine with linux. I did check the addresses and operands in the resulting binary with objdump, everything has the correct values. What am I doing wrong ? Feel free to cluebat me to death if I missed some obvious point ... ... I don't know what you hope to accomplish by avoiding the use of libc. But if you really want to do that, you'll need to know that the system call interface is completely different on linux than openbsd. Here's assembly code to call write on linux: .globl write write: pushl %ebx movl8(%esp),%ebx# fd movl12(%esp),%ecx # buffer movl16(%esp),%edx # count movl$4,%eax # __NR_write int $128 popl%ebx testl %eax,%eax jl cerror_ ret cerror_: negl%eax movl%eax,errno movl$-1,%eax movl$-1,%edx ret In linux, parameters are passed in the registers, the error code is returned as a negative number. Here's assembly code to call write on openbsd: .globl write write: movl$4,%eax # SYS_write int $128 jb cerror_ ret cerror_: movl%eax,errno movl$-1,%eax movl$-1,%edx ret On OpenBSD, parameters are passed on the stack. The kernel cleverly copies stuff from the stack just where the C calling conventions left them, which is why you don't see any code here to muck with that. An error is indicated by setting the carry flag. Incidently, there are better ways to do hexadecimal conversion. That is, assuming you really don't want to use libc. For instance, consider how you might use this: *--cp = 0123456789abcdef [ n 15 ]; -Marcus Watts
Re: ADVERT: C12G
Joachim Schipper [EMAIL PROTECTED] wrote: Subject: Re: ADVERT: C12G ... That, and Schneier's 'snake oil' may well apply. ... Almost certainly applies. See http://groups.google.com/group/sci.crypt/msg/401bd358ad9f651e -Marcus Watts
Re: 4.0 sparc64 booting problems
openbsd neophyte [EMAIL PROTECTED] writes: Date:Wed, 27 Jun 2007 00:12:53 PDT To: misc@openbsd.org From:openbsd neophyte [EMAIL PROTECTED] Subject: 4.0 sparc64 booting problems i have an ultra 5 (440mhz/512mb/14.4GB IDE) with OpenBSD 4.0 installed. i never really had any problems with the machine for some months until earlier today. i couldn't access the machine so i connected through the serial port to find the machine stuck on the ok prompt. when i tried forcing a boot (boot disk) this is what I got: --- Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 File and args: -r OpenBSD IEEE 1275 Bootblock 1.1 ..Program terminated --- when i tried a reset on the ok prompt i got the following: Resetting ... Data Access Error i really don't know where to begin. what could have gone wrong with the system? is this something that indicates a hardware issue, or has something happened to the 4.0 installation? You should power-cycle the machine. The prom environment is probably too corrupt to properly reset. If that doesn't work, consider doing these next: /1/ boot from removable media (after a power-on reset) /2/ check the cmos battery. renew if necessary. /3/ check other cables, memory modules, etc. try prom memory test. You may have a hardware problem. -Marcus
Re: AFS Server on OpenBSD
Date: Tue, 17 Apr 2007 01:30:46 +0200 From: Rico Secada [EMAIL PROTECTED] To: misc@openbsd.org Subject: AFS Server on OpenBSD Message-Id: [EMAIL PROTECTED] Hi, I have been trying to find some information on setting up a AFS server on OpenBSD, is it even possible? Rico. Yes, this should be possible. Visit: www.openafs.org to get openafs source. Either use heimdal (built-in to openbsd) or build and install MIT kerberos, or decide if kaserver is sufficient and acceptable to you. You don't need to bother with the openafs afs cache manager if you're just running an afs server, so you will most likely want to build openafs with '--disable-kernel-module'. If you have more questions regarding openafs, ask [EMAIL PROTECTED] what you're asking about is really AFS-centric, not openBSD-centric. -Marcus Watts
Re: Serial Port Network
Don Smith [EMAIL PROTECTED] writes: I have 2 older desktop computers (old Pentium 1 processors), ... slip or ppp. You won't be doing much file sharing this way though, unless you're *very* patient. usb doesn't do peer-peer networking, so I don't see what good that does you. You'd be *much* better off buying a brace of ethernet cards. ISA - 10 megabits cards should be nearly free. You'll also have to score some thin-net cable and terminators. Alternatively, you can get twisted pair cards. If you have PCI bus machines you can do better, but that probably postdates your machines. You probably don't need a console except for maintenance. You can just swap monitors for that. You could set up a serial console tip, but it's not worth it unless you have some other reason you want it. You probably don't want to run ppp on your console port. -Marcus
Re: bcw(4) is gone
Writes darren kirby [EMAIL PROTECTED]: ... From: Joseph Jezak: As one of the reverse engineers, the reason for the openness of writing the specification was to ensure that the Chinese Wall method was maintained. To date, I have not been contacted by any of the bcw programmers regarding clarification of the specification, but I would welcome any questions they might have. So how were they not trying to work with the OpenBSD folks? In order for the OpenBSD folks to have worked this out, they would have had to go through function by function and ask for approval to use that function. If refused, they would have had to devise a workaround that was sufficiently different as to qualify as new and original -- without documentation. The example function quoted sounded like it was actually a macro - probably a small enough chunk of code that there may not be any logical new and original alternative. So, even if we stop here, we have a cumbersome process that (a) wastes a lot of time, and (b) is not guaranteed to result in anything that works. But wait, there's worse! The FSF contract standard generally requires a release *in writing*. (See documents like Legal Issues about Contributing Code to GNU). Assuming the gnu bcw programmers are serious about protecting their interests (and they sure sound like they are), and assuming the openBSD folks are even willing to tolerate this level of nonsense, then to get the same level of protection each of these exceptions would then need a separate written release. So, what we're talking about here is a momumental amount of work that is easily an order of magnitude more complicated than the actual driver, with no appreciable benefit to anybody except perhaps the lawyers drafting up all those releases. No part of this process produces better code, and no part of this process produces a more secure operating system, so all this work we're talking about here is way out of scope for OpenBSD. There isn't really any alternative for Marcus Glocker here either. Now that he's clearly seen the GPL code, it would be very difficult for him to produce any code for this hardware a clever lawyer couldn't argue was derivative. He's on the dirty side of the Chinese Wall now. Unless he wants to spend 90% of his time working out function by function copyright releases, the only real alternative he has is to delete his code find something completely different of actual value to work on. I think the really valuable lesson out of all this is that this shows, for once for all, that a GPL licensed driver is *not* an acceptable substitute for proper documentation released by the maker without undo intellectual or financial burden (ie, no NDA's, excessive licensing fees or restrictions.) It's a shame the gnu folks didn't release their reversed engineered specifications separately. I can understand why though; DMCA would make that a much more risky affair today than when the Phoenix folks pioneered the Chinese Wall approach. -Marcus Watts
Re: bcw(4) is gone
bofh [EMAIL PROTECTED] writes: On 4/6/07, Marcus Watts [EMAIL PROTECTED] wrote: It's a shame the gnu folks didn't release their reversed engineered specifications separately. Waitaminit - I thought they did?!?! Reading that gmane list, one of the spec writing people said he would be happy to answer any questions about the specs. Cool! My mistake -- http://undeadly.org/cgi?action=articlesid=20061121194620 openbsd... points to http://bcm43xx.berlios.de/ http://bcm-specs.sipsolutions.net/ points to http://bcm-v4.sipsolutions.net/ I have seen other pieces of GPL code where the writers had signed NDAs to get the necessary information. I always found that questionable. -Marcus Watts
Re: bcw(4) is gone
Gordon Willem Klok [EMAIL PROTECTED] writes: Part of this is nonsense and I dont mean to pick on you in particular but I have seen it repeated a few times now and its getting annoying. If licenses were as viral as some of you people imagine that one cannot look at a source file copyrighted with a dumb license interpert what the code does and create your own version parts of the LINUX KERNEL WOULD BE SUBJECT TO THE APSL and imagine the CDDL as well but I dont mess around with sun hardware... Seriously you can go look at some of their recent mac powerpc drivers and you can see plenty of references to where bits of information were taken from darwin, they have done nothing wrong. You got me. I'm not a lawyer. But before you assume you're in the free clear, you might want to look at these: http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0101000-.html text of us statue defining derivative work. http://www.ivanhoffman.com/fairusemusic.html fair use - music sampling http://www.ivanhoffman.com/helpful.html pointers to more interesting copyright cases. http://en.wikipedia.org/wiki/Campbell_v._Acuff-Rose_Music,_Inc. parody - fair use? 4 grounds: purpose, nature, substantiality, effect on market case by case - no general rule. http://www.chillingeffects.org/derivative/ derivative works. all or parts. 4 part rule again. http://www.chillingeffects.org/derivative/faq.cgi note last case - same expression. also note in many cases, words like probably not, that depends, etc. That means you're in a grey zone, which means you could be right, and you could still end up in court. http://en.wikipedia.org/wiki/List_of_leading_legal_cases_in_copyright_law lots and lots of case law. some of them are even relevant, some is not. http://www.low-life.fsnet.co.uk/copyright/ copyright and sampling. UK. http://dvinfo.net/articles/business/copyrightfaq4.php lots of stuff. Note question 30: new recording based on parts of other songs usually not legal. may fall into the category of derivative work. This isn't a black white thing. There's a lot of grey here, with room for lots of expensive legal maneuvering, and you can definitely find case law on both sides of the coin. The biggest saving grace I can see here is since the GPL folks aren't in fact a for-profit concern, they can't really claim much in the way of monetary damages in their market. That *might* save you on ground #4. One of the things I learned in constructing the above list is a lot has happened with music sampling and copyright law in the past decade, and questions that were formerly in the grey area might not be anymore. All of this stuff is evolving rapidly. When I've talked to lawyers in the past, they've been very clear there's probably safe and nearly certainly safe - and there's a choice you make. They'll cheerfully tell you what's nearly certainly safe, and urge you to take that, and it will very likely seem quite unreasonable - especially after they say even that's not absolutely safe. Part of the judgement call you get to make very often is what will the other guy actually decide to do, and why. One of the many reasons I went into software development instead of lawyering is that computers are a lot more straight-forward. -Marcus Watts
Re: A little about assembly language
Rico Secada [EMAIL PROTECTED] writes: ... I am brushing up a bit on my assembly language skills, I used to work on MIPS but are now looking on x86. I have a problem choosing between following a book using the (as) ATT syntax and another using (nasm) Intel syntax. I know that this isn't directly OpenBSD related but I would appreciate any recommendations. ... If you only intend to run on unix platforms, use the ATT syntax. If you intend to do a lot of work with ms windows as well and want to transport code back forth, use intel (nasm, masm). If you're not sure, you might want to start with the ATT syntax; it has slightly more obvious functionality than the intel syntax, and is also more like the unix assemblers on other architectures (such as mips, arm, etc.) Also, you'll find it easier to read gdb output. Whichever syntax you use, if you plan on doing a lot with x86 you should spend enough time with the other to be able to read code written in that. -Marcus Watts
Re: Hard drive going bad? or something else? (obsd4.0)
I've not see this type of problem before, so I turn to you guys. Is this a sign that maybe a drive is going bad? Or sign of bad memory? What's going on here!? I know it is almost Halloween and all, but this is kinda _spooky_ to say the least. Idea? Please? :-) Hard drives contain lots of moving parts, a known reliability risk. Therefore most if not all modern hard disks and associated logic contain more or less elaborate internal self-checking logic to detect failing media, failing spindle motor, failing head positioning mechanism, over and under voltage, bus driver failure, etc. Most of these will result in kernel messages and/or other obvious signs of system distress. Your dmesg (assuming it was done after the failed build) doesn't show any evidence of such problem, so there's no reason to suspect a hard disk going bad. More likely possibilities are bad memory, a bad motherboard, incompatible memory, bad disk controller, mis-configured bus speeds, environmental problem, or possibly but less likely, a bad cpu. Memory is simple: if you buy a consumer grade home machine, you get memory that has no self-check logic. A chip going bad could well produce the problems you show below. A server class machine will nearly always contain ECC memory. A few companies (Dell, Sun) also make commercial grade desktop machines, which usually also contain ECC. Note that most home computer stores and even many professionals don't understand or value ECC memory, and will steer you away from such technology. If it's memory, even without self-check logic that may still be easy to see if it's broken. memcheck86+ has a good reputation. This is a stand-alone program, which you can leave running overnight. If it fails memcheck86+, then the problem is obvious. If it passes, the memory is still not in the clear; for instance, it's in theory possible for the memory to fail when accessed by DMA but not by the processor. If you can get the memory to fail more or less predictably, and you have multiple memory modules, you may be able to play remove swap games to identify which module is bad. Check your hardward doc first - on some systems, modules may need to be paired in some particular fashion. It is certainly worth checking your machine for obvious physical problems. For instance, check air paths to ensure they aren't blocked. Be suspicious of burning smells, obvious heat, excessive fan noise, or lack of distinct air flow. Check the inside of the machine. Is there excessive dust build-up? Are the fan blades clean? Do the fans spin very smoothly and fairly freely? Are the cables in the way? Are there any loose cables? Loose boards? Bad solder joints or cracks? (On most modern motherboards, it's not worth spending much time checking this if it's not easy to get to; removing the motherboard may itself cause damage, and even a large crack sufficient to produce complete failure may be nearly impossible to spot). Other signs of physical distress? Ideally you want your machine to be in a climate-controlled environment comfortable to people. Dust, very dry air, excessive moisture, temperature cycles, etc. are all bad. Electrically conductive dust can become particularly exciting. An older or fancier machine may have a separate disk controller, in which case if you have a spare it may be worth swapping. Your machine is probably not one of these. On many newer machines, the BIOS can contain settings which alter the speed or timing of various bus components. Getting this wrong can produce subtle weirdness, or obvious and drammatic signs of failure. It may take a while for subtle weirdness to manifest itself in any obvious fashion. If you have ECC memory, make sure the bios knows that. Sorting all this out can take time. If the machine is an older one, it may be cheaper to replace it than figure out what failed. Also, in case you missed it, building large software packages is an excellent way to burn a new machines in or establish that an existing machine is reliable. :-) -Marcus
Re: AF_ISO, SOCK_RAW - mysterious phenomena in OpenBSD
Karel Kulhavy [EMAIL PROTECTED] writes: How do I do this C call taken from a Linux program on OpenBSD? socket(PF_PACKET, SOCK_RAW, htons(0x4254)) man socket on OpenBSD offers AF_ISO (ISO protocols) which sounds like it could be access to individual ISO stack layers including layer 2? However ... When I wrote something using SOCK_RAW, some time back, I ended up digging through kernel sources and experimenting to figure out how it worked. There were some non-obvious features like setting the address family, using setsockopt(,IPPROTO_IP,IP_HDRINCL, and etc. that were good to know. You might also want to check out tcpdump and libpcap - either the source for coding examples, or the tool or library for a higher level interface to generate packet traffic. AF_ISO is obselete - it got removed in openbsd some time ago. 4.4bsd had an arpa funded implementation of all of the iso networking standards, but somehow these just never did displace TCP/IP. For a dated but entertaining perspective on the ISO networking reference model vs. ietf, check out: RFC 871 A Perspective On The Arpanet Reference Model M.A. Padlipsky It's fashionable today to map TCP/IP layers into the iso networking reference model, but this is merely for human convenience, it's not something you'd code into a program. -Marcus Watts
Re: Intel breaking patents - related to closed documentation?
Breen Ouellette [EMAIL PROTECTED] writes: I just spotted this in the news: http://news.com.com/Transmeta+sues+Intel+for+patent+infringement/2100-1006_3-6124965.html?tag=nefd.top If Intel makes a habit of stealing patented technology would open access to their hardware documentation then make it easier for the patent holder to sue? The reason I ask is that I am merely trying to understand if Intel's real motivation for NDAs could be to protect themselves from lawsuits if they are stealing IP. I doubt it. The NDA isn't going to stop somebody else in the field from knowing what is happening. Most breakthroughs don't happen in some solitary persons' basement; they normally happen in the context of large research establishments with lots of people who talk to each other. An NDA might even backfire. It could be seen as evidence the company knew it was somebody else's proprietary secret, and they were trying to hide their ill-begotten gains. That could even increase the odds of criminal penalties for the persons involved -- an NDA is pretty much by definition a self-documenting process. I haven't looked at your link yet, but patent infringement cases come up all the time. They almost never are decided in court. What usually happens first is the parties involved settle out of court and make some sort of cross-licensing pact - very often the pact itself is secret, so it's not always easy to decide who comes out the winner in these cases. Keep in mind, Intel *needs* companies like TransMeta and AMD to be in business. If they go out of business, Intel has a large exposure for anti-trust action. If any developers are willing to comment that would be great. I've never seen hardware documentation from a vendor so I don't know what it usually contains. Here is some hardware docuemntation: ftp://download.intel.com/design/Itanium/Downloads/24531903s.pdf http://e-www.motorola.com/brdata/PDFDB/docs/MPCFPE32B.pdf http://www.sun.com/microelectronics/UltraSPARC-IIi/docs/805-0087.pdf;$sessionid$Z55GQEK3RHOIVAMTA1LU45Q http://www.intel.com/design/pentium4/manuals/24547012.pdf http://bitsavers.vt100.net/ibm/360/A22-6843-3_360channelOEM.pdf http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/pdp28_tsChanges_apr65.pdf ps2q04-019.pdf http://www.dell.com/downloads/global/power/ps2q04-019.pdf ( they may not all work - they date back many years... ) ( if you look at intel other companies, you'll find plenty more documentation. Old stuff is usually not protected by nda. ) Thanks. Breeno
Re: OpenBSD's own compiler
Rico Secada [EMAIL PROTECTED] writes: Date: Mon, 31 Jul 2006 01:37:46 +0200 From: Rico Secada [EMAIL PROTECTED] To: misc@openbsd.org Subject: OpenBSD's own compiler ... I am curently studying the Ada programming language and I read about the different safety demands, which has been made a standard, upon compilers. You're probably reading propaganda from the Ada folks. If you check out the C++ folks, you'll find a different perspective on the design decisions that were made in Ada. Also note that despite the optimistic projections of the Ada folks back in the 80's, Ada is even today far from becoming universally popular. I was wondering, would it be a stupid and bad idea, for the OpenBSD team to develope, an OpenBSD C compiler based upon the OpenBSD security knowledge and internal standards regarding the language? Making it impossible for the compiler to accept and compile programs with all the knows errors which cause problems. The OpenBSDs way of programming has clearly made it clear, what security and quality is all about. ... There is already an OpenBSD C compiler. It's based mostly on Gnu, but with a bit of extra stuff pioneered in part by the OpenBSD folks. The C compiler in OpenBSD is not designed to stop you from writing buggy code. Even if the compiler were as smart as a human being, it couldn't do that, and we don't yet have fast enough hardware to make the compiler anywhere near that smart. The OpenBSD design principals are designed to do what the compiler cannot do - proactively discover fix problems. The hacks in the compiler, library runtime system of OpenBSD are designed to limit contain the effects of several common bugs, and to encourage good coding practice to avoid those bugs. It's not designed to ensure that the resulting code is in fact problem-free or completely secure. For reasons of compatibility (because it's nice to be able to port other people's code) OpenBSD specifically allows you to do things that are known to be bad. In this, OpenBSD is following the well-known C precept: give the programmer enough rope to hang himself. -Marcus Watts
Re: cat -v
Nick Guenther [EMAIL PROTECTED] writes: ... Anyway, I wasn't trying to fight about it, I'm just curious. ... sed -n l has been around since forever or at least since v7. Presumably before that folks used ed or od. cat -v -e etc. have been around in *bsd since at least 4.1bsd. I don't remember ATT picking up on those options, but probably -v, -e, etc., are part of various standards today. Certainly the FSF folks picked up on those flags in their GNU core utilities. The vis command appears to have been added in 4.4bsd. I can't find any evidence of vis outside of 4.4bsd. Most people who've been around Unix long enough have their own pet commands. For instance, I have randomize, fd, and genpass. I use randomize all the time to unsort data line by line differently each time, fd in place of od -xc to get side-by-side hex ascii dump output, and more rarely genpass to generate random passwords for things. There's very probably some population of other people out there who might find those very commands useful, - but it's also very probable there's not a large enough population of such users that I could find them without annoying a bunch of other people in the process. -Marcus Watts
Re: cat -v
Nick Guenther [EMAIL PROTECTED] writes: Message-ID: [EMAIL PROTECTED] Date: Thu, 27 Jul 2006 22:31:10 -0400 From: Nick Guenther [EMAIL PROTECTED] To: OpenBSD-Misc misc@openbsd.org Subject: cat -v Why does cat retain the -[etv], -[bn] and -[s] options? I am reading the paper cited in cat's manpage and saw 'vis' mentioned. vis is in base, and line numbering and stripping can be done with sed, so why does cat have those options? Is for history, just for compatibility, or has no one ever bothered to remove them (I find this unlikely)? -Nick Using the same argument, everything that grep, sed and awk can do can be done in perl, so why have grep, sed awk? All we need to do is teach everybody to type perl -pe 1 in place of cat. -Marcus Watts
Re: Forward IP to remote location
Various wrote: Subject: Re: Forward IP to remote location Date: Fri, 21 Jul 2006 15:47:24 -0400 Message-ID: [EMAIL PROTECTED] From: Dan Farrell [EMAIL PROTECTED] To: Nguyen Manh Thang [EMAIL PROTECTED], misc@openbsd.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nguyen Manh Thang Sent: Friday, July 21, 2006 6:00 AM To: misc@openbsd.org Subject: Forward IP to remote location Hi, I'm trying to forward one or more IP addresses from one location to another. Location A has xxx.xxx.xxx.96/27 IP addresses. In Location A there is a CISCO Router, but I don't have access to this router. Location B is connected to the Internet using cable modem. The IP address that comes to the server in location B is 10.1.70.40, as you can see this is not ratable IP address. Is there a way to run HTTP server at Location B using one of the IP address in Location A? Thank you, Rossen -- --- --- I have the same your question. You not do yet? pls lead me do. thanks manh thang Maybe I'm missing something, but... Nope. When a surfer to your site wants to go xxx.xxx.xxx.98 they will go to location A, not to whatever cable modem location site A is at. The only way to make certain IP addresses appear to be coming from locations they weren't intended to come from (and have actual two-way communication) is as a result of hacking one or more networks. If this kind of thing worked, people would be hijacking websites left and right. Dan Farrell Applied Innovations [EMAIL PROTECTED] There's at least 3 ways to do this. 2 of them require physical presence at the bounce site. The 3rd requires some form of trusted access. Way #1 -- at location A, allocate an IP address and install a bridge. The bridge should route all traffic for that IP address to location B, possibly via some form of vpn or tunneling. At location B, attach the web server to the other end of the bridge give it the assigned IP address. You might find it convenient to do some form of NAT somewhere in here to map addresses. Way #2 - at location A, install a proxy squid server, and sshd. On the web server at location B, make an ssh connection to the squid server that will forward remote connections from a given port to the web server on the local host. Now teach the proxy squid server to talk to the designated port that will forward via ssh to the remote server. You don't need the proxy squid server if you can stand using a non-standard port number 2048 in your URLs, or if you're willing to make your sshd connection as root and forward 80. Way #3 - the CISCO router at location A probably has some means of acquiring routing information. Supply it routing information that will route data to for the designated location A IP address to location B. You'll need to convince each intermediate point between A and B to cooperate. If you can't establish such a path to B, you'll need need to acquire some location C where you can have physical presence and a routable path back to A. From location C you can of course use #1,#2 to reach B. Unless you *really* value the routable IP address at location A, AND you can convince the folks at location A to let you do this, you're probably better off not doing this. Common factors to all of these: yes you can use openbsd for all the pieces. (I'm not sure openbsd has any other specific connection to this problem.) you need some way to route incoming connections to something at location B. If you can't directly accept incoming connections on something at location B then you need some form of network forwarding to some point where you do have such access. you need *some* level of cooperation at location A. You need *something* at A that will see the incoming packet connection for your public IP address at A, that can *somehow* point this towards B. This doesn't need to be the Cisco router, but it does need to be something the router can see. The last constraint is why you don't see people hijacking websites left right. -Marcus Watts
Re: Preventing password reuse
Chris Zakelj [EMAIL PROTECTED] writes: Date: Mon, 03 Jul 2006 21:09:32 -0400 From: Chris Zakelj [EMAIL PROTECTED] To: STeve Andre' [EMAIL PROTECTED] CC: misc@openbsd.org Subject: Re: Preventing password reuse STeve Andre' wrote: On Monday 03 July 2006 17:37, Jeff Simmons wrote: A client is setting up a password policy, and would like to prevent users from reusing a password for a period of time (four changes ninety days apart). Is there a way to do this, either within the OS or via a program in ports? I've been looking for quite a while and haven't found anything. I can't resist pointing out that this is an AWFUL policy. You will be remembering peoples passwords, a history of them, which are very likely to be used on other systems. Thats really bad. I wonder (at least in the USA) what would happen to your company if that data was ever stolen? The same thing that happens whenever any other data (like, say, SSNs) gets stolen. Absolutely nothing. Check out any good newspaper morgue before you believe that. There are too many counter-examples to your claim. The person who made this initial request claims to be working for medical doctors credit card processors. There are specific horrible examples of the possible consequences of either. Of course, most of these are consequences to the person stealing the data, or the person whose data was lost -- but if too many data professionals start asserting it's not their responsibility at all, our politicians who art in whatever will certainly create laws that say otherwise. HIPA for instance. Or think of the poor guy who lost a laptop at the VA recently. In any case, you don't need to store passwords. You can store a history of one-way hashes instead, get (nearly) the same benefit, and without nearly the security exposure. I think the more interesting security argument is that if you make people change passwords too often, they're much more likely to adopt other less secure policies in compensation, ones you can't control nearly so easily. For instance, they're much more likely to write them down. Or they may force you to adopt a less strigent password reset policy. Or they may just invent an obvious way to permute their password. -Marcus Watts
Re: wikipedia article
Various wrote: From: Otto Moerbeek [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] ... What was the bit size of the CPU's originally used to write UNIX in Bell Labs? What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, it could not even do paging. The pdp-11 mmu could handle program relocation, segmentation (after a fashion) and memory protection. I'm not sure what more you could expect from an mmu. What you mean by paging is probably demand paging, which means the ability to run a program without requiring that it be entirely resident. The key feature you need for that is a guarantee that any instruction fault caused by missing memory can be either restarted or continued. In most architectures that's a question of cpu design not mmu. In the case of the pdp-11 that's mostly a moot point. The pdp-11 only provides for mapping the 64k of memory space into into 8 segments (addressable on 64-byte clicks) and there's just not much win to demand paging 8 pages. (actually 6 x 8 pages; there was kernel, user, and supervisor mode, each had separate instruction and data spaces, but supervisor mode was rarely used in Unix environments, and only a few large user mode programs ran using split I/D space.) For what it's worth, though, I *think* it was possible to restart most instructions on the /45 and /70, which were the big machines and the primary target of most later pdp-11 work. In fact, some use was made of this feature -- automatic stack growth. If you look through ancient Unix source, you'll find interesting bits of kernel code that manage this. There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. -Marcus Watts
Re: Hifn policy on documentation
From: Marc Balmer [EMAIL PROTECTED] writes: Date: Wed, 14 Jun 2006 00:22:12 +0200 From: Marc Balmer [EMAIL PROTECTED] To: Michael Scheliga [EMAIL PROTECTED] Cc: Hank Cohen [EMAIL PROTECTED], misc@openbsd.org Subject: Re: Hifn policy on documentation * Michael Scheliga wrote: truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Clearly you don't. The vendor probably does. [ I do know somebody who once seriously inquired into the procedure to send in partial dead rat corpses to city hall. Seems the state had a bounty program on the books from a century ago ... ] In this case, the vendor appears to be talking about documentation, which means they're actually confused. EAR covers chips but not documentation. By US law they *have* to care about the chips. Otherwise they're not in business. However the same law and a bunch of court cases also makes a big thing about free speech. For quite a number of years, when cryptography was considered a munition and not allowed to be exported without special license, people were writing books and talking about cryptography almost entirely without problems. Somebody needs to point this out to them; there's simply no defensible US export legal reason for them to make people fill out web forms of any form to acquire human readable documentation. If the purpose of their web registration was to satisfy US export purposes, it would still be different. Such a form would mainly be concerned with issues like where do you live - can you prove you are a US citizen - and nothing more. The MIT folks distributed kerberos source via http with just such a registration system for a number of years. If they're asking 50 nosey personal questions, that's not US export law. That's business accounting and marketing think, 100% (or possibly a *really* bad lawyer.) They want to know where to send the next load of junk mail so they can spend their advertising dollars most effectively. They may want to resell that information to other people in similar businesses. Their sales people want to know if you call with questions after that whether you're going to buy enough of their product to make it worth their time to answer your questions. Maybe they're imagining they can reduce product liability claims - although I don't know of very many product liability cases that were won by failing to disclose problems. Seems like they're more likely to succeed at reducing product liability by reducing customer interest and usage. It's conceivable they think their competitors are actually stupid enough that this form will stop them from learning about what they're doing or coming up with better ways to do it. In any event, however justifiable they think they are in their business practices, it still stinks, and it bodes ill for their long-term business health. I wish their competition the best of luck. -Marcus Watts
Re: wikipedia article
Various wrote: Message-ID: [EMAIL PROTECTED] Date: Wed, 14 Jun 2006 00:50:53 +0200 From: Johnny Billquist [EMAIL PROTECTED] Organization: Update Computer Club User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Per_Fogelstr=F6m?= [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Marcus Watts [EMAIL PROTECTED], Otto Moerbeek [EMAIL PROTECTED], Ted Mittelstaedt [EMAIL PROTECTED], John Nemeth [EMAIL PROTECTED], Nikolas Britton [EMAIL PROTECTED], Ted Unangst [EMAIL PROTECTED], =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= [EMAIL PROTECTED], misc@openbsd.org, freebsd-questions@freebsd.org, [EMAIL PROTECTED] Subject: Re: wikipedia article Per Fogelstr=F6m wrote: On Tuesday 13 June 2006 14:23, Rick Kelly wrote: =20 Johnny Billquist said: There's actually a cheesy way to do demand paging with microprocessor= s that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instructi= on causing the fault so contains restartable machine state. Masscomp so= ld a machine like this once. Didn't the first Apollos do this? And also the Sun 1. =20 =20 IIRC it was simpler than that. When the first cpu caused a 'miss' it wa= s put in wait and cpu 2 handled the pagein and then released cpu 1. Keeping t= he two cpus synched, one instruction apart would have been too complicated if = not impossible... Your idea will not work, as far as I can tell. If the first CPU instruction execution causes a miss, the end result in=20 the CPU will be pretty undefined, and you cannot restart. That's the=20 whole point in why you'd have a second CPU shadowing the first one. So=20 that you'd be able to restore the state as it were before the illegal=20 memory access. And that was the problem with the original 68000. On an illegal memory=20 reference, you would not know what state the CPU was in before the=20 instruction, so you could not back it up, and re-execute the instruction=20 after a page fault. Johnny Several clarifications. The sun-1 did not have a dual CPU page fault arrangement. It used a slightly higher clock speed version of the same CPU board used previously used by codata 4 other vendors, originally designed by stanford university. Instead of using the motorola MMU which was late to market, expensive, slow, or industry standard MMU cache logic (TLB), they used a very clever generic chip implementation that used the CPU alternate space instructions to manage dedicated high speed RAM which provided all the mapping. This managed a page addressed space, but did NOT do demand paging. Another exciting low-cost feature of the sun-1 CPU was software dynamic ram refresh- every 2 ms, the CPU was interrupted by the refresh interrupt and would execute 127 nop instructions. The sun-2 was very similiar to the sun-1, but upgraded the 68000 to a 68010 (which could do instruction restarts and hence demand paging), deleted the onboard RAM, and instead added the ability to use DMA via an IOMMU to private bus RAM. The sun-1 ran unisoft version 7 unix, complete with swapping. The sun-2 ran 4.2bsd. I've got an actual physical codata processor manual (complete with schematics) but I believe I've seen a sun-1 processor manual in pdf somewhere on the web recently. I'm not 100% sure how masscomp or apollo handled page faults. The impression I had is that the first CPU got reset, and the second was interrupted on the instruction boundary and saved its CPU state first thing in the interrupt handler. While the user register state in the first is undefined, the CPU itself is still good - it can take an interrupt, transition into kernel mode and recover machine state from somewhere else (like the 2nd CPU) just fine. That seems to me to be the most sane way it could have been handled. I suppose it's possible the 2nd CPU could have been instead paused, while the first CPU processed the segmentation violation, trashed its non-recoverable machine state, handled the exception, and ?somehow? reloaded machine state from the 2nd paused CPU. Switching to a different process while the 2nd CPU was paused waiting for a page to come in off disk might have been a bit awkward. So while I think this might have been made to work, I doubt it could have performed as well. So far as the 2 cpu synchronization logic goes - either of these would have required such a beast. The 68000 used address spaces to distinguish between instruction and data references, so instruction synchronization was no problem. It might have been necessary to decode instructions to sort out operands other instruction stream references, including logic to sort out page faults in the middle
Re: How to find memory leak in library/OS?
Kurt Miller [EMAIL PROTECTED] and others write: Date: Thu, 30 Mar 2006 14:01:55 -0500 From: Kurt Miller [EMAIL PROTECTED] Subject: Re: How to find memory leak in library/OS? In-reply-to: [EMAIL PROTECTED] To: Claus Assmann [EMAIL PROTECTED] Cc: misc@openbsd.org Reply-to: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On Thursday 30 March 2006 1:25 pm, Claus Assmann wrote: On Thu, Mar 30, 2006, Ted Unangst wrote: particular to pthreads, if you are using mutexes or somesuch on the stack, you will leak memory. (the lock on the stack is just a pointer, it gets allocated on first use). All mutexes are part of structures that are allocated via malloc(). Would those leak memory too (even if pthread_mutex_destroy() is called)? The application (it's the sendmail X address resolver) uses a new mutex/condition variable for every request in the test that triggers the leaks. Thanks for your answer! I recently went through a similar exercise looking for leaks in the jvm thread creation and destruction code. The process is simple but tedious. Build a debug version of libc, libpthread and your application. Put a break point on malloc, realloc free. When malloc and realloc are hit, do the finish gdb command and note the returned address on a pad and where it was called from. When free is called cross off the matching address from the list. Whatever is left is the source of your leak. There are things you could do help the process along, like using gdb's 'commands' feature. If you suspect the pthreads library is leaking you could place break points at the malloc / realloc / free calls that your application hits in pthreads (ie break at the calls to malloc in the pthread code, not at malloc itself). -Kurt This tedious book-keeping process is exactly the thing computers are supposed to be good at doing. I've had a special version of malloc that I've used for years which does this and a few other tricks. It's not exactly elegant, because it requires relinking and usually additional hooks in the application to take full advantage of the leak detection, but when all else fails, I find it worth the trouble. I had forgotten it had pthread locking logic - it might even be thread safe: /afs/umich.edu/group/itd/build/mdw/xmalloc/src/ No real documentation, sorry. -Marcus Watts
Re: Where to get a good seed for srandom()
Alexander Farber [EMAIL PROTECTED] asks: ... If % is not good enough for getting random values in a range, then what is? ... Actually, % 32 is fine (or any reasonably small power of 2). Modulo any odd number is guaranteed to have at least a small problem, and module a large enough number is going to start to get really bad. To illustrate the problem, suppose you had a perfect rand function that returned numbers in the range 0-255. On average, about half the time, the numbers will be even or odd. That's %2. Any power of two up to 128 will work perfectly as well. Now, suppose instead we take it module 189. For values out of the rand function less than 189, things work fine. However, there are only 67 values = 189, so the output of this will be twice as likely to pick values 0-66 as it is values 67-188. That's sort of really bad. Now, the output from arc4random() is really quite large, so for small values of N, %N will be fine. It's only for large values of N that this roundoff problem is going to be significant. The for N=289 and using arcrandom(), the bias is only 0.00044, so it would take a lot of values to estimate this empirically. Another way to fix this, is if you're using %, make sure the random value you plug into % is smaller than the largest multiple. For 189, that would be 22724694*189 or 4294967296U. If the number you get is larger than this, discard it and obtain another random number. If you throw out the last 130 values, you've now got a fair generator. rc4 is a common cheap expansion function for random functions. A higher quality but slower method is to use sha-1 or some other function. Another possible alternative is to use a symmetric algorithm such as aes or blowfish. Typically you would plug your seed plus a counter into the input of these functions, then supply the output (perhaps with some truncation) as the result of your function. Incidently, I think your card shuffling algorith has some of the same problems as the rc4 key schedule algorithm. You might want to read up on that. -Marcus Watts
Re: Openbsd 3.7's Gnu Assembler (as) file tagging behaviour?
edgar mortiz [EMAIL PROTECTED] writes: ... $as -o hello.o hello.s $ld -o hello hello.o $./hello sh: ./hello: Operation not permitted $file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped i noticed that the Gnu (AS) that FreeBSD uses will automatically tagged the file FreeBSD where as the Gnu (AS) that OpenBSD doesn't. is there a patch that can resolve this or a tweak of some sort .. I really want it to work on OpenBSD and not on the other BSD .. i picked OpenBSD coz it basically has all the docs I'll ever need together with the OS ... For openbsd, to tag it as such you need something like this: # for openbsd; see # /usr/src/lib/csu/common_elf/os-note-elf.h # /usr/src/sys/kern/exec_elf.c .section .note.openbsd.ident, a # .note .p2align 2 .long 8 .long 4 .long 1 .ascii OpenBSD\0 .long 0 .p2align 2 You can read the files mentioned in the comments if you need more information on how all this works. -Marcus
