Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


holdmybeer last won the day on April 10

holdmybeer had the most liked content!

Community Reputation

6 Neutral

About holdmybeer

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I was able reproduce that, XC16 and XC32 seem to strip the quotes from your string literal definition, no matter what you do 😞
  2. For me, the trick to strictly read it from right to left helped a lot. volatile List_t * ListHead; A variable ListHead which is a pointer to the type List_t which is volatile. List_t * volatile ListHead; A variable ListHead which is a volatile pointer to a type List_t volatile List_t * volatile ListHead; A variable ListHead which is a volatile pointer to a type List_t which is volatile const int *ptr_to_constant; A variable ptr_to_constant which is a pointer to a type int which is a constant int *const constant_ptr; A variable constant_prt which is a constant pointer to a type int
  3. Not every pin is capable of driving such high frequencies. I strongly suggest to have a look at the output signal with a scope. Are the edges of the signal okay or do they get rounder and rounder with increasing baud rate? Is the frequency correct? A few pins may have special hardware (such as SPI) to have more drive strength, have a Schmitt trigger behavior for inputs etc.
  4. My SAME54 project is growing every day, and I have to make a decision how to manage my code. Maybe someone has an advise for me? The situation is this, I started to develop the project in Studio. Later, some people persuaded my to rebuild my project to work with XC32 along with the headers from XC. So I made a branch "MPLABX_Branch" to put the modified project there. Now I have a complete parallel branch with different register names and it's quite a pain to maintain them both if I want to add something new. Should I put the branch into a new repository? Or should clutter up the code with a lot of #ifdefs for XC and GCC? What would be the best approach?
  5. According to your zip package, PBCLK is set to 48 MHz, not 96MHz? And it's a PIC32MX470F512L, just for clarity 🙂 It would be a good idea to debug your project and have a look at the actual register settings, to see if Harmony did everything right. I would also suggest to check the analog output signal with a scope to check the frequency and the signal quality. Is there a signal at higher baud rates and how does it look like?
  6. And now it works with 2.15. Try to add "extern" to your inline function, this worked for me:
  7. Oh, I see now. You have to include the body, otherwise the compiler complains (if -Winline is used): my_inline_func.h:4:17: warning: inlining failed in call to 'inl_func': function body not available [-Winline] And it works fine with 2.10, I see nice inlined functions in the disassembly:
  8. I just had a look at your test project and really wonder why you put the definition of a function in a header file. Since you include that header file with the definition in two C files, you end up with two conflicting definitions, don't you?
  9. No you haven't, right. This only was my conclusion for my original idea 🙂 The key for filtering the output string was activating line buffering, then the _write function will be called with a larger string which can be filtered well. If buffering is set to off or if filtering is implemented in putchar, you would have to set up a little state machine to keep track of the characters already written.
  10. error: 'cmse_nonsecure_entry' attribute not available to functions with variable number of arguments This is what I saw today on my screen 😂 So I had no other choice than exposing _read and _write as a non-secure entry. The write function filters out all non-printable chars and adds the prefix before the string. Another challenge was to bring printf to not print char by char, I had to turn on line buffering: setvbuf(stdout, NULL, _IOLBF, 80); I still have trouble understanding how a function call from non secure to secure and back looks like from the perspective of the stacks (it has two stack pointers). Have a look at my Github if you like, I'm open for critical reviews. Anyway, filtering printf format strings would work, but gets complicated very quickly with all these possible combinations of parameters, flags, etc. It would quickly end up in building a parser for the format string. I didn't foresee how deep the problem actually is when I started this thread 🙂 Thanks for your input!
  11. Well, the initial idea of simply filtering out a carriage return turned way more complicated than I thought. Let me explain the background, but first let's put aside hardware tampering and side-channel attacks, this is about software security along with a Trustzone. I'm writing this software as an exercise for me to understand the SAML11, which has a Trustzone where I'd like to put all the secure communication functions. One of them has access to a console via UART. So the secure part of the software is able to use printf() and can output a string to the console. For better distinguishability, the printf precedes a "SECURE" string before each output of the secure app. The non-secure app is running in a different part of the memory, has it's own stack, it's own program counter and a kind of hypervisor (IDAU) is preventing this app from accessing the memory of the secure app in any way. Additionally, it won't have access to any peripherals or registers which aren't declared non-secure before by the secure app. To control access to the outside world, I can implement so called non-secure caller functions (NSC function), which are placed in a special (de-militarized?) zone between the secure and the non-secure memory. This functions can be called by the non-secure app and can branch to a secure function (again supervised by hardware) to do something which requires secure privileges and then return to the non-secure app. So, my first idea was to simply let them use printf and put that into the NSC zone. Each time the non secure app calls my NSC-printf, I simply precede a "NONSECURE" to mark this line coming from the non secure app. The first post shows my implementation. But then I have to control the format string to prevent the non-secure app from overwriting my prefix, I thought. And THEN I realized how much you can do with %s, %x and %n I have different options now. The safest way would be to just print out the format string without bothering with the arguments, like printf("%s", nonsec_string). In this way, I only allow constant strings, so I could just write my own function like printc(const char *) and forget about stdlib, saving space. The second way would be to severely limit the capabilities of printf and filter out all malicious format placeholders and only allow a handful of them. Like if it's not a 'd' or a '%' what follows a '%', replace the '%' with '_'. And yes, the non-secure app could have an own implementation of printf(), but that would just allow them to explore the non-secure memory, which yields nothing. Even if they could reach memory parts which are placed in the secure zone by this method, that would lead to a hardfault by the hypervisor. However, a secure function is execute inside the secure memory, so an uncontrollable format string would pose a serious threat. What do you think - does it still make sense to filter the format string in a wrapper or should I just expose a function to output constant strings, length limited, stripped from non-printable chars?
  12. Oh dear, printf() seems to be a big security hole. Reading into the matter by googling around, this is known since 1989. I'd like to share my findings: printf() is a variadic function, that means it accepts a variable amount of arguments. Definition of such a function is void function (int foo, ...); It has to have a least one named parameter and the ellipsis parameter ("...") has to be at the end. To access the parameters, macros defined in <stdarg.h> can be used va_start, va_list, va_arg, va_end. So, as I already found out, I can pass a list of arguments va_list to vprintf() (which accepts a va_list instead of a string) to build a wrapper for my printf. However, the very sad part is, that va_list is only a pointer to the beginning of the list, so you can't determine the end without a convention with the caller. This is the weakness many exploits use to read and write arbitrary memory. printf() as a variadic function can't know about the number of arguments passed in a call. So if you type: printf("This is column %d and row %d", column); You have a mismatch between the number of placeholders and the number of arguments. printf() fetches the arguments from stack, not knowing how many "legal" arguments have been placed there: Stack ------ (grows in this direction) -----> .... | Argument c | Argument b | Argument a | Address of Format String | ... <--- (moving in this direction) --- ^ | printf()'s internal pointer So with printf and a tricky format string, we basically can read the stack! More evil, printf accepts format parameters like %s, which treats the argument as an address of a string, which has to read out until the next \0 (NULL) character. Both combined, we are able to place an address on the stack and then read out this address with %s: printf ("\x10\x01\x48\x08 %x %x %x %x %s"); But printf() isn't limited to read access of arbitrary memory locations, it can even write to memory with %n, this format parameter writes the number of characters written so far. With the same example from above, replacing %s by %n, the contents of that address will be overwritten. So, back to my initial idea, replacing the "NONSECURE" string by adding an "\r" and overwrite the preceding string seems to be my least problem if I build a wrapper for printf(). This concept is meant to be used for the brand new Cortex M23 architecture, which has a Trustzone with a secure library and hardware monitoring and a non secure part. The wrapper is a non secure call to be able to have printf available in the non secure part without having access to the library nor the hardware. For sure, only allowing constant strings would be easy. The good thing is, I have access to the format string in my wrapper, so I should be able to filter out all malicious %s and %n format parameters. Leaving the possibility to read the stack. Will this be secure enough? The wrapper will be called in the secure world, so being able to read out the secure stack might not be the best idea. I'd be happy if someone could add some thoughts about this, my project is on Github, please have a look: https://github.com/dxstp/saml11_init/blob/master/SecureProject/utils/print.c.
  13. Hi all, I'm trying to implement a wrapper for printf, which filters the string to prevent special non-printable characters. The background behind this is a console output for a secure software where the secure output should be preceded by "SECURE:" and the non-secure output should be preceded by "NONSECURE". I want to prevent someone to insert some control chars to overwrite the prefix (like including an '\r' at the beginning.) So far, I found a good example for a wrapper: void nonsec_printf(char *string, ...) { va_list argp; fprintf(stdout, "NONSEC: "); va_start(argp, string); vfprintf(stdout, string, argp); va_end(argp); } How could I check the parameters for any special characters? Or should I rather start one level deeper at putc...
  14. Next one: 14. The Pragmatic Programmer: From Journeyman to Master A book for programmers who need a first orientation. It is great for beginners, but I think everyone involved in software programming should have a look into it. The first part isn't even specifically for programmers, it is how to think as a professional developer and what managers expect from you. The following chapters lay out the craftman's tool box and explain which tools you should use, along with the right mindset how to face daily problems. A lot of tips and techniques are targeted on avoiding code smells (without saying the word for that) or avoiding common pitfalls. The author also gives attention to a couple of social / communication aspects - the best programming skills are worth nothing today without that. There is a checklist with all tips glued into the book to be taken out - very pragmatic!
  • Create New...