Announcement

Collapse
No announcement yet.

F2FS Hit By Three Security Vulnerabilities: Memory Corruption, Possible Code Execution

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by linuxgeex View Post

    It wasn't done cheap then. It was done to budget. Cheap would be half that. Then what would happen to your quality/scope/timely delivery objectives? I can promise that at 1/2 the cost you wouldn't have gotten something that matched your formal spec. You might not have even been able to afford someone to write the formal spec, or you might have written a lovely spec, then had the plug pulled on your project because it was going over (1/2 the) budget, and your product would have been vapourware. Lucky for you, nobody set an impossible budget, impossible deadline, or impossible scope.


    The work flow is way different. To achieve good fast cheep you do not have a workflow where any part is isolated from each other.
    <b>An implementation correctness proof between low-level design and C implementation for a code base of similar size or complexity had not been achieved before.</b>
    The scope was impossible before they did it. So yes Australian mil was insane enough to request the impossible with budget, deadline and scope.

    The difference here is automation. Automated quality control with automated proof checking reduces you defects and reduced the labour you need to deal with them to get product to somewhat usable. So cheap it is. Cheap without automated validation/proof ends up costing more than cheep with. Of course this also means you have fast and good.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by linuxgeex View Post

    It wasn't done cheap then. It was done to budget. Cheap would be half that. Then what would happen to your quality/scope/timely delivery objectives? I can promise that at 1/2 the cost you wouldn't have gotten something that matched your formal spec. You might not have even been able to afford someone to write the formal spec, or you might have written a lovely spec, then had the plug pulled on your project because it was going over (1/2 the) budget, and your product would have been vapourware. Lucky for you, nobody set an impossible budget, impossible deadline, or impossible scope.
    Linuxgeex you have made a mistake. The formal specification of sel4 and eChronos becomes a mathematical proof. It was done under budget and way lower cost than you would expect.



    The work flow is something way different to what you would expect. Yes you are correct the formal spec is not 100 percent written by human directly in sel4 and Echronos case. Quite a bit is generated. Both sel4 and eChronos worked out it about half the cost of something done cheap due to reduced debugging time.

    Basically to achieve the cost level sel4 and eChronos did you have to use a different work-flow to traditional and different staff mix. You need high level mathematics person you need a documentation writer and 1/8 of the programming staff time. Why the mass reduction in programming staff time they are not wasting time going into the code working out why it not working most of the time the proof will say these lines of code are wrong and why so fix them.

    Reality is you cannot get cheapest if the result is not good and fast. Impossible budget, impossible deadline, or impossible scope got to be kidding me that is exactly what those 2 projects had. For the number of lines of code at the time sel4 specification and validation was done the allocated budget was 1/20 of the normal expect cost, normal dead line for doing it was 12 months for demonstration they only got 6 months to first complete validation demonstration and it had to be absolute complete validation at 12 months. Basically if you attempt to do what sel4 or echronos has done with the method they used it is truly impossible. Over half the formal specification is generated over 90 percent of the test casing is generated sections of the final C code again generated. Basically a heck load of automation. This is Manual labour vs Automation. Reality is most of our code development is way too much manual labour and that is why you cannot achieve good fast cheep.

    One of the key bits of scope to both sel4 and eChronos is the lower amount of human labour to produce final product and to release maintenance releases to keep cost as low as possible.

    When something did what was called impossible it becomes a very interesting read of method to achieve it because it means they have done a method others are not doing. sel4 and eChronos did the impossible and are still doing what people say are not possible or impossible.

    An implementation correctness proof between low-level design and C implementation for a code base of similar size or complexity had not been achieved before.

    Even groups with 1000 times more budget and staff than what Data61 had were unable to achieve what Data61 did with sel4. Reality this was a problem that was not solved by throwing money or massive number of human hours at it instead was solved by a solid automated quality assuring development process that in it self reduces costs.

    Of course scaling up what was done for sel4 to something like the Linux kernel will not be easy. Dealing with the defects that could have been detected and remove if Linux kernel had a form proof system like sel4 are not easy or cost effective either.

    Really sel4 and eChronos should alter our expectations. The idea that fast, good and cheep in software development is impossible need to go away because that is demonstrated by sel4 and eChronos as false. Now it comes how can we get to where fast, good and cheep in software development is the normal. Fast good cheep does not require leaving C as both sel4 and eChronos are both written in C with executable proof written in haskell. So limited new programming languages as well.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by linuxgeex View Post

    It wasn't done cheap then. It was done to budget. Cheap would be half that. Then what would happen to your quality/scope/timely delivery objectives? I can promise that at 1/2 the cost you wouldn't have gotten something that matched your formal spec. You might not have even been able to afford someone to write the formal spec, or you might have written a lovely spec, then had the plug pulled on your project because it was going over (1/2 the) budget, and your product would have been vapourware. Lucky for you, nobody set an impossible budget, impossible deadline, or impossible scope.
    Linuxgeex you have made a mistake. The formal specification of sel4 and eChronos becomes a mathematical proof. It was done under budget and way lower cost than you would expect.



    The work flow is something way different to what you would expect. Yes you are correct the formal spec is not 100 percent written by human directly in sel4 and Echronos case. Quite a bit is generated. Both sel4 and eChronos worked out it about half the cost of something done cheap due to reduced debugging time.

    Basically to achieve the cost level sel4 and eChronos did you have to use a different work-flow to traditional and different staff mix. You need high level mathematics person you need a documentation writer and 1/8 of the programming staff time. Why the mass reduction in programming staff time they are not wasting time going into the code working out why it not working most of the time the proof will say these lines of code are wrong and why so fix them.

    Reality is you cannot get cheapest if the result is not good and fast. Impossible budget, impossible deadline, or impossible scope got to be kidding me that is exactly what those 2 projects had. For the number of lines of code at the time sel4 specification and validation was done the allocated budget was 1/20 of the normal expect cost, normal dead line for doing it was 12 months for demonstration they only got 6 months to first complete validation demonstration and it had to be absolute complete validation at 12 months. Basically if you attempt to do what sel4 or echronos has done with the method they used it is truly impossible. Over half the formal specification is generated over 90 percent of the test casing is generated sections of the final C code again generated. Basically a heck load of automation. This is Manual labour vs Automation. Reality is most of our code development is way too much manual labour and that is why you cannot achieve good fast cheep.

    One of the key bits of scope to both sel4 and eChronos is the lower amount of human labour to produce final product and to release maintenance releases to keep cost as low as possible.

    When something did what was called impossible it becomes a very interesting read of method to achieve it because it means they have done a method others are not doing. sel4 and eChronos did the impossible and are still doing what people say are not possible or impossible.

    An implementation correctness proof between low-level design and C implementation for a code base of similar size or complexity had not been achieved before.

    Even groups with 1000 times more budget and staff than what Data61 had were unable to achieve what Data61 did with sel4. Reality this was a problem that was not solved by throwing money or massive number of human hours at it instead was solved by a solid automated quality assuring development process that in it self reduces costs.

    Of course scaling up what was done for sel4 to something like the Linux kernel will not be easy. Dealing with the defects that could have been detected and remove if Linux kernel had a form proof system like sel4 are not easy or cost effective either.

    Really sel4 and eChronos should alter our expectations. The idea that fast, good and cheep in software development is impossible need to go away because that is demonstrated by sel4 and eChronos as false. Now it comes how can we get to where fast, good and cheep in software development is the normal.

    Leave a comment:


  • linuxgeex
    replied
    Originally posted by oiaohm View Post

    So close. Please note sel4 and eChronos done by data61 manage to sit right in the not possible marked area in the good fast cheep. The key is in the project management trilemma being scope. Both projects had clearly defined scope.

    For a project to have a formally written scope you need documentation writers. To do formal proofs and be sure you have done everything you need a formal written scope. To make sure test cases cover everything the need to hello formal written scope useful again.

    Remember sel4 and eChronos is being developed for military usage in control of weapons systems where they can in fact take someone life. The Australian military that Data61 is doing this development for does not give them a very big budget either . A weapon system being slow is not an option a slow weapon you are dead before you can fire it. Poor quality is not a option because that can kill again. So fast and good are mandatory features. Really restricted budget means cheep has to be done. So all 3 points have to be achieved as there was no other choice. This is why look into how sel4 and eChronos development is done is so interesting.
    It wasn't done cheap then. It was done to budget. Cheap would be half that. Then what would happen to your quality/scope/timely delivery objectives? I can promise that at 1/2 the cost you wouldn't have gotten something that matched your formal spec. You might not have even been able to afford someone to write the formal spec, or you might have written a lovely spec, then had the plug pulled on your project because it was going over (1/2 the) budget, and your product would have been vapourware. Lucky for you, nobody set an impossible budget, impossible deadline, or impossible scope.
    Last edited by linuxgeex; 10 August 2017, 09:57 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by linuxgeex View Post

    I first heard this from 'fortune', googled it, and found the Arthur C Clarke reference, which was about software development. Handily today I can also find that on Wikipedia.

    There's also this:
    So close. Please note sel4 and eChronos done by data61 manage to sit right in the not possible marked area in the good fast cheep. The key is in the project management trilemma being scope. Both projects had clearly defined scope.

    For a project to have a formally written scope you need documentation writers. To do formal proofs and be sure you have done everything you need a formal written scope. To make sure test cases cover everything the need to hello formal written scope useful again.

    Remember sel4 and eChronos is being developed for military usage in control of weapons systems where they can in fact take someone life. The Australian military that Data61 is doing this development for does not give them a very big budget either . A weapon system being slow is not an option a slow weapon you are dead before you can fire it. Poor quality is not a option because that can kill again. So fast and good are mandatory features. Really restricted budget means cheep has to be done. So all 3 points have to be achieved as there was no other choice. This is why look into how sel4 and eChronos development is done is so interesting.

    Leave a comment:


  • garegin
    replied
    Yeah. Let's take out rear view cameras, air bags and obtruction warning systems so people drive more carefully.
    And btw from my experience code has gotten monumentally more complex and programs are more robust than ever. So no, application quality is not decreasing, unless your CEO is Gabe Newell.
    Last edited by garegin; 09 August 2017, 09:29 PM.

    Leave a comment:


  • caligula
    replied
    Originally posted by garegin View Post
    there's also gonna be trashy code written for some Taiwanese webcam. In fact most code is of subpar quality.
    Better development tools, expert sexchange sites, and easier languages also enable the writing of cheaper and worse quality code. We have now code written by less skilled people than ever before. The time to market for applicants has gone super low. Also people buy cheap and worse crap than ever before directly from Shenzhen.

    Leave a comment:


  • garegin
    replied
    The point is that we are already "being responsible". The big names like MS, Google and HP are already running every fuzz test and memory profiler and we still have security holes. All things being equal we need safer languages. C fans are strawmanning Rust advocates that we think safer languages are a cure all. They are NOT. About 70% of holes are memory errors. The rest are probably not gonna be caught with static analysis.
    We are forgetting that not every dev is a security nut/programming enthusiast. My aunt has been programming in C++ since late 80s and didn't even know what lint is. The testing is probably done by a different team.
    there's also gonna be trashy code written for some Taiwanese webcam. In fact most code is of subpar quality.

    Leave a comment:


  • linuxgeex
    replied
    Originally posted by garegin View Post
    No one said to throw code away. Rust is a good idea if you are starting a new project. no one is holding their hand from using testing tools. C apologists are like people who drive a Ford Pinto and say that we need safer driving.
    LOL. They're not wrong, we do need safer driving, and safety is the responsibility of everyone on the road, but yeah some people deserve to win a Darwin Award as a result of their choices, I just hope they don't take me with them.

    Leave a comment:


  • linuxgeex
    replied
    Originally posted by bug77 View Post

    That's not about software development, that's management's iron triangle: https://en.wikipedia.org/wiki/Projec...ement_triangle

    As for your other arguments, I deal with the "we have tests that can be run on demand, thus we must have unit tests" or "it's too expensive to do code review" mentality way too often to want to think about it again.
    I first heard this from 'fortune', googled it, and found the Arthur C Clarke reference, which was about software development. Handily today I can also find that on Wikipedia.

    There's also this:


    captioned "The First Law of Software Development". And it goes on to make all the same points you and I are making, lol.

    One of the best analogies I enjoy is the programmer turning to the project manager and saying "I'm your doctor. I've diagnosed you with malignant testicular cancer, you have 2 months to live if it isn't removed immediately. My intern can try it this week, or you can book me for next week. Oh, you'd like a discount? I think I might have a free spot 3 months from now."
    Last edited by linuxgeex; 09 August 2017, 09:35 AM.

    Leave a comment:

Working...
X