8 ms·

A cryptographically secure bootloader for RISC-V in Rust

189 points by fork-bomber 2y ago

ladyanita22 2y ago
[flagged]
- eviks 2y ago
  It's zero overhead for zero extra functionality, here it seems they've added some > Additionally, SentinelBoot employs public-key cryptography to verify the integrity of a booted kernel (digital signature), by the use of the RISC-V Vector Cryptography extension, establishing secure boot functionality.
  - ladyanita22 2y ago
    Fair enough
- f_devd 2y ago
  I don't think the rust team would claim writing idiomatic safe rust code is always zero-overhead. Indexing into an array adds bounds checks which takes non-zero time. So by default you trade-off safety for performance to some degree; but this can be bypassed if needed, that's why you have unsafe. For completeness, it's 0.1x the size with 1.20x the runtime, so these are not just language differences
  - RsmFz 2y ago
    I think the phrase is "zero-cost abstractions", meaning "Supposing you want bounds checks, you may as well use ours and not roll your own"
    - ladyanita22 2y ago
      It's true that you can escape them though. There are some other small things (which AFAICT you can escape from to as well)
  - estebank 2y ago
    > Indexing into an array adds bounds checks which takes non-zero time. * When done in such a way that the compiler cannot know the access is in-bounds. The same code in C would also need to perform bounds checks on access. If you do the same assertion you would in C checking that the indices are always less than the length, then Rust will not perform the bounds check because it detects it's unnecessary. Leveraging iterators is one idiomatic way of avoiding those bounds checks.
- klysm 2y ago
  20% overhead from doing crypto
- winter_blue 2y ago
  The overhead is for doing computation (fr cryptographic hashing). No language has zero cost computation. Rust advertises what’s called zero-cost abstractions; which is a major improvement over many languages where abstractions can be expensive.
  - ladyanita22 2y ago
    I thought the C version (U boot) did that as well. I guess it does not.
- deleted 2y ago
  [deleted]
greenavocado 2y ago
Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reducing their technological freedom.
- mouse_ 2y ago
  That's what it's for, make no mistake. Those who sacrifice liberty for safety will receive and deserve neither.
  - gjsman-1000 2y ago
    Reminder that quote is so out of context that the actual meaning, as it was intended, is wildly different. https://techcrunch.com/2014/02/14/how-the-world-butchered-benjamin-franklins-quote-on-liberty-vs-security/ https://techcrunch.com/2014/02/14/how-the-world-butchered-be... https://news.ycombinator.com/item?id=5268899 https://news.ycombinator.com/item?id=5268899 https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...
    - mouse_ 2y ago
      I am sorry if I have caused any misunderstanding; the point I was trying to make is that, as ownership is a nebulous concept, yet one that must be protected, one with physical access to a device ought to be able to do whatever they want to it. To imply that bootloader locking is not primarily used to restrict what the owner of a device is able to do with it is disingenuous at best. I fundamentally disagree with the concept of bootloader locks in general under the idea that the evil that corporations are able to enact with them has historically far outweighed the real life security concerns that they actually protect users against. I understand this may be a controversial viewpoint but personally I feel (opinion) that the erosion of ownership is one of the most important issues we face today.
    - Z0QinrgF 2y ago
      [dead]
fefe23 2y ago
"cryptographically secure bootloader" is a meaningless phrase. They mean a boot loader that validates cryptographic public key signatures of the loaded component. That would be a secure cryptographic bootloader. AFTER they have proven that it is, in fact, secure. You can't just write some code and then say it must be secure because Rust was involved.
- creshal 2y ago
  How does it know what keys to trust? TPM?
- RsmFz 2y ago
  > You can't just write some code and then say it must be secure because Rust was involved Did they say that?
  - fefe23 2y ago
    Yes. They call it "secure" and have zero arguments to back up that claim except Rust's memory safety guarantees. Which, by the way, do not apply, since the SHA256-Code is marked unsafe.
    - AlotOfReading 2y ago
      Unsafe blocks do not imply equivalence with C. They imply that if there are memory safety issues, the issue originates in one of the unsafe blocks. Usually there are few enough lines of code in unsafe blocks doing small enough tasks that you can feasibly to rule out issues by thinking hard enough. Contrast that with C, where every line may be a source of safety issues. It's a meaningful difference.
      - uecker 2y ago
        Well, not every construct in C can have safety issue. Saying that every line in C may be the source of memory safety issues is as accurate as saying that every line of Rust may be a source of memory safety issues, because it could make use of unsafe. There is another issue: Unsafe code in Rust could violate assumptions that could cause other code in Rust to be unsafe. So it needs more care to write than regular C. But I agree that it still a huge net benefit with respect to memory safety, but let's not exaggerate.
Aurornis 2y ago
This is a very specific type of bootloader for devices that get their code over the internet: > SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain). The author readily acknowledges that it does not defend against hardware modification. The other comments here trying to vilify this project don't understand what it is supposed to do.
- deleted 2y ago
  [deleted]
zamalek 2y ago
The problem with Rust in the boot process is that it's going to become much harder to find vulnerabilities for roots/jailbreaks. Still, this is great work!
- kelnos 2y ago
  Could you elaborate on this? I'm not sure what you mean; are you saying that there will still be vulnerabilities that are of similar difficulty to exploit as would be found in a C bootloader, but will be harder to find by security researchers? Or are you just saying that there will be fewer vulnerabilities, but the ones that do exist will be more "obscure" than would be the case if it were written in C, because Rust eliminates some of the more "obvious" vectors? Either way, do you consider this a bad thing?
  - yjftsjthsd-h 2y ago
    It's neither of those. The trade-off is that features like this are often used against users, preventing them from actually controlling their own machines. Under those circumstances, bugs in the "security" of the machine are a mixed bag: malware can exploit them to break out, but users can exploit them to get full control over the machine that they own. This has happened with Android phones, for instance, allowing people to root phones and/or replace the ROM with a community version that gets security patches not available in the stock ROM, which is probably a net security improvement even with the bootloader left vulnerable. So it's really hard to call it a good thing or a bad thing; it's a trade.
- quohort 2y ago
  Yes, ironically increased transparency and more secure systems will lead to less freedom for the user, because trusted computing is most often securing the interests of manufacturers against users (what RMS refereed to as "Treacherous Computing") I think that we have been able to thwart "treachery" in the meantime by exploiting side-channels in trusted computing implementations. Ultimately it may be necessary to amend the constitution to prevent manufacturers from distributing locked-down hardware for the good of free society (competition, democracy, etc.) at large. Otherwise, computer giants will have ultimate control over the distribution of information (given that the economics of manufacturing are driven by economies of scale).
ReleaseCandidat 2y ago
I don't get the "1/10 size of U-Boot" argument. As it can only boot 3 RISC-V64 boards via TFTP, it also has less than 1/10 of the features and supported hardware of U-Boot. https://github.com/u-boot/u-boot https://github.com/u-boot/u-boot
- Z0QinrgF 2y ago
  [dead]
- Arnavion 2y ago
  Supported hardware doesn't matter because they're comparing the compiled binary size, not source code size. The u-boot binary you'd compile would also only have the stuff relevant to that particular hardware compiled-in. If you don't need the other features of u-boot that this doesn't have, it makes sense to count the lower binary size and runtime memory usage as an advantage. That said, they compared it to "an example U-boot binary", which sounds like they probably didn't tweak the bajillion config options u-boot has to produce one with an equivalent feature set to theirs, which would've been a fairer comparison for sure.
Vogtinator 2y ago
Measured boot > trust chain through signature verification: With measured boot, components in the boot chain tell some trusted component (e.g. a TPM, possibly in FW) about all of their input and only if the hashes at the end match, $something is accessible (in most cases a secret key for data decryption). 1. More flexibility (with TPM e.g. you can "seal" a secret against different parts independently) 2. No need for PKI, which gets very complex once revocations are involved (have fun looking at the "Secure Boot" DBX lists and the shim SBAT mechanism) 3. More freedom: The system still boots if the measurements don't match, you just don't get access to secrets. You're free to seal your own secrets against your new measurements and whoever did the last sealing has no access anymore. (Unlike on PCs where the Microsoft trust is in most cases not removable).
- quohort 2y ago
  1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach. I assume the TPM in this case would only have a partial decryption key? I think something similar could be accomplished with SSS, no? 2. As for this, I can say i've never used DBX with UEFI Secure boot. Instead of revoking keys, I just remake the entire PKI from the top. The PKI is only there to support independent use by OS Vendor/OEM hence the separation of PK/KEK/db. 3. Counterpoint: over-reliance on TPMs and such. Whereas the ordinary trust chain only requires signature verification at the start of boot (presumably on-chip), measured boot requires more complex trusted computing hardware (presumably off-chip). Personally, I find that systems that are overly-reliant on complex trusted computing hardware tend to lack in other areas. For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN. These systems try often to reconcile "analog" passkeys like Biometrics (FaceID, fingerprints) by using trusted computing. Of course, if the trusted computing systems are breached (https://www.404media.co/leaked-docs-show-what-phones-cellebrite-can-and-cant-unlock/ https://www.404media.co/leaked-docs-show-what-phones-cellebr...), then security is very weak. I suppose the advantage of the measured-boot method is that it is optional. So you can still boot whatever OS you want, just without some TC features.
IshKebab 2y ago
That is I've impressive final year project, nice work! Vector crypto is very cutting edge too. I guess there isn't any hardware that has it yet...
- ReleaseCandidat 2y ago
  SiFive's P670 Cores do: https://www.sifive.com/cores/performance-p650-670 https://www.sifive.com/cores/performance-p650-670 If and when they are available, I don't know, Sophgo licensed them: https://www.cnx-software.com/2023/10/21/sophgo-sg2380-16-core-sifive-p670-risc-v-processor-20-tops-ai-accelerator/ https://www.cnx-software.com/2023/10/21/sophgo-sg2380-16-cor... preorder is here: https://arace.tech/products/pre-order-milk-v-oasis-16-core-risc-v-desktop-coupon https://arace.tech/products/pre-order-milk-v-oasis-16-core-r...
zokier 2y ago
tbh I feel bad for the kid, his thesis supervisor should have helped him more here to scope and direct the work in some sensible way. now it is bit of a mess :( like just doing a review and comparison of existing boot verification mechanisms would have been already good scope for a thesis. Instead they are barely even mentioned as a side-note, which puts this in a awkward position. or if crypto was focus, then putting more work on designing and implementing the crypto scheme would have been relevant. Now they got so tangled with the nitty gritty boot details that the crypto ended up also as questionable side-note. or if rust was focus, then just implementing clean pure-rust bootloader could have been already enough for the thesis, avoiding the stumbling over on misguided crypto bits. or many other ways this could have been more successful. overall it now feels the author ended up biting far more than what they can chew. also they should have imho spent less time coding and more time on editing the actual thesis. the text is all over the place.
- fch42 2y ago
  You have rather high expectations towards the supervisor there ... maybe you were one of the "unlucky" ones who had a genius supervisor ... There aren't that many people in the world who write bootloader code daily for a living, an even smaller subset of those would ever have done one entirely from scratch (vs. just board-porting U-Boot), and even of those, the likelihood of someone having done a secureboot capable one wouldn't be high. Assuming you have such a person as a thesis advisor is a huge stretch ... That said though, a thesis is (or should be) a learning exercise. Even a complete fail (to achieve the "initial" objective) can make a great thesis if new knowledge - even negative proofs, "this isn't possible because ..." - come out of it. It's just my opinion maybe, but a graduate should never be taught "fake it till you make it"; rather, describe and document failures thoroughly, explain the observations, highlight and justify the parts that work or are breakthroughs. That can make a much better readable and much more useful thesis than one that skims over one-time lucky else nonreproducible results and delivers uncommented sources that fail to compile for anyone but the original author. In that sense, I would argue that a good thesis advisor will focus on the scientific process, documentary evidence, clarity of experimental setups and tests/checks/benchmarks performed, not whether the outcome would be "great enough" to pitch as a founder to VCs.

189 points by fork-bomber 2y ago

ladyanita22 2y ago

[flagged]

eviks 2y ago
It's zero overhead for zero extra functionality, here it seems they've added some > Additionally, SentinelBoot employs public-key cryptography to verify the integrity of a booted kernel (digital signature), by the use of the RISC-V Vector Cryptography extension, establishing secure boot functionality.
- ladyanita22 2y ago
  Fair enough
f_devd 2y ago
I don't think the rust team would claim writing idiomatic safe rust code is always zero-overhead. Indexing into an array adds bounds checks which takes non-zero time. So by default you trade-off safety for performance to some degree; but this can be bypassed if needed, that's why you have unsafe. For completeness, it's 0.1x the size with 1.20x the runtime, so these are not just language differences
- RsmFz 2y ago
  I think the phrase is "zero-cost abstractions", meaning "Supposing you want bounds checks, you may as well use ours and not roll your own"
  - ladyanita22 2y ago
    It's true that you can escape them though. There are some other small things (which AFAICT you can escape from to as well)
- estebank 2y ago
  > Indexing into an array adds bounds checks which takes non-zero time. * When done in such a way that the compiler cannot know the access is in-bounds. The same code in C would also need to perform bounds checks on access. If you do the same assertion you would in C checking that the indices are always less than the length, then Rust will not perform the bounds check because it detects it's unnecessary. Leveraging iterators is one idiomatic way of avoiding those bounds checks.
klysm 2y ago
20% overhead from doing crypto
winter_blue 2y ago
The overhead is for doing computation (fr cryptographic hashing). No language has zero cost computation. Rust advertises what’s called zero-cost abstractions; which is a major improvement over many languages where abstractions can be expensive.
- ladyanita22 2y ago
  I thought the C version (U boot) did that as well. I guess it does not.
deleted 2y ago
[deleted]

greenavocado 2y ago

Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reducing their technological freedom.

mouse_ 2y ago
That's what it's for, make no mistake. Those who sacrifice liberty for safety will receive and deserve neither.
- gjsman-1000 2y ago
  Reminder that quote is so out of context that the actual meaning, as it was intended, is wildly different. https://techcrunch.com/2014/02/14/how-the-world-butchered-benjamin-franklins-quote-on-liberty-vs-security/ https://techcrunch.com/2014/02/14/how-the-world-butchered-be... https://news.ycombinator.com/item?id=5268899 https://news.ycombinator.com/item?id=5268899 https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...
  - mouse_ 2y ago
    I am sorry if I have caused any misunderstanding; the point I was trying to make is that, as ownership is a nebulous concept, yet one that must be protected, one with physical access to a device ought to be able to do whatever they want to it. To imply that bootloader locking is not primarily used to restrict what the owner of a device is able to do with it is disingenuous at best. I fundamentally disagree with the concept of bootloader locks in general under the idea that the evil that corporations are able to enact with them has historically far outweighed the real life security concerns that they actually protect users against. I understand this may be a controversial viewpoint but personally I feel (opinion) that the erosion of ownership is one of the most important issues we face today.
  - Z0QinrgF 2y ago
    [dead]

fefe23 2y ago

"cryptographically secure bootloader" is a meaningless phrase. They mean a boot loader that validates cryptographic public key signatures of the loaded component. That would be a secure cryptographic bootloader. AFTER they have proven that it is, in fact, secure. You can't just write some code and then say it must be secure because Rust was involved.

creshal 2y ago
How does it know what keys to trust? TPM?
RsmFz 2y ago
> You can't just write some code and then say it must be secure because Rust was involved Did they say that?
- fefe23 2y ago
  Yes. They call it "secure" and have zero arguments to back up that claim except Rust's memory safety guarantees. Which, by the way, do not apply, since the SHA256-Code is marked unsafe.
  - AlotOfReading 2y ago
    Unsafe blocks do not imply equivalence with C. They imply that if there are memory safety issues, the issue originates in one of the unsafe blocks. Usually there are few enough lines of code in unsafe blocks doing small enough tasks that you can feasibly to rule out issues by thinking hard enough. Contrast that with C, where every line may be a source of safety issues. It's a meaningful difference.
    - uecker 2y ago
      Well, not every construct in C can have safety issue. Saying that every line in C may be the source of memory safety issues is as accurate as saying that every line of Rust may be a source of memory safety issues, because it could make use of unsafe. There is another issue: Unsafe code in Rust could violate assumptions that could cause other code in Rust to be unsafe. So it needs more care to write than regular C. But I agree that it still a huge net benefit with respect to memory safety, but let's not exaggerate.

Aurornis 2y ago

This is a very specific type of bootloader for devices that get their code over the internet: > SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain). The author readily acknowledges that it does not defend against hardware modification. The other comments here trying to vilify this project don't understand what it is supposed to do.

deleted 2y ago
[deleted]

zamalek 2y ago

The problem with Rust in the boot process is that it's going to become much harder to find vulnerabilities for roots/jailbreaks. Still, this is great work!

kelnos 2y ago
Could you elaborate on this? I'm not sure what you mean; are you saying that there will still be vulnerabilities that are of similar difficulty to exploit as would be found in a C bootloader, but will be harder to find by security researchers? Or are you just saying that there will be fewer vulnerabilities, but the ones that do exist will be more "obscure" than would be the case if it were written in C, because Rust eliminates some of the more "obvious" vectors? Either way, do you consider this a bad thing?
- yjftsjthsd-h 2y ago
  It's neither of those. The trade-off is that features like this are often used against users, preventing them from actually controlling their own machines. Under those circumstances, bugs in the "security" of the machine are a mixed bag: malware can exploit them to break out, but users can exploit them to get full control over the machine that they own. This has happened with Android phones, for instance, allowing people to root phones and/or replace the ROM with a community version that gets security patches not available in the stock ROM, which is probably a net security improvement even with the bootloader left vulnerable. So it's really hard to call it a good thing or a bad thing; it's a trade.
quohort 2y ago
Yes, ironically increased transparency and more secure systems will lead to less freedom for the user, because trusted computing is most often securing the interests of manufacturers against users (what RMS refereed to as "Treacherous Computing") I think that we have been able to thwart "treachery" in the meantime by exploiting side-channels in trusted computing implementations. Ultimately it may be necessary to amend the constitution to prevent manufacturers from distributing locked-down hardware for the good of free society (competition, democracy, etc.) at large. Otherwise, computer giants will have ultimate control over the distribution of information (given that the economics of manufacturing are driven by economies of scale).

ReleaseCandidat 2y ago

I don't get the "1/10 size of U-Boot" argument. As it can only boot 3 RISC-V64 boards via TFTP, it also has less than 1/10 of the features and supported hardware of U-Boot. https://github.com/u-boot/u-boot https://github.com/u-boot/u-boot

Z0QinrgF 2y ago
[dead]
Arnavion 2y ago
Supported hardware doesn't matter because they're comparing the compiled binary size, not source code size. The u-boot binary you'd compile would also only have the stuff relevant to that particular hardware compiled-in. If you don't need the other features of u-boot that this doesn't have, it makes sense to count the lower binary size and runtime memory usage as an advantage. That said, they compared it to "an example U-boot binary", which sounds like they probably didn't tweak the bajillion config options u-boot has to produce one with an equivalent feature set to theirs, which would've been a fairer comparison for sure.

Vogtinator 2y ago

Measured boot > trust chain through signature verification: With measured boot, components in the boot chain tell some trusted component (e.g. a TPM, possibly in FW) about all of their input and only if the hashes at the end match, $something is accessible (in most cases a secret key for data decryption). 1. More flexibility (with TPM e.g. you can "seal" a secret against different parts independently) 2. No need for PKI, which gets very complex once revocations are involved (have fun looking at the "Secure Boot" DBX lists and the shim SBAT mechanism) 3. More freedom: The system still boots if the measurements don't match, you just don't get access to secrets. You're free to seal your own secrets against your new measurements and whoever did the last sealing has no access anymore. (Unlike on PCs where the Microsoft trust is in most cases not removable).

quohort 2y ago
1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach. I assume the TPM in this case would only have a partial decryption key? I think something similar could be accomplished with SSS, no? 2. As for this, I can say i've never used DBX with UEFI Secure boot. Instead of revoking keys, I just remake the entire PKI from the top. The PKI is only there to support independent use by OS Vendor/OEM hence the separation of PK/KEK/db. 3. Counterpoint: over-reliance on TPMs and such. Whereas the ordinary trust chain only requires signature verification at the start of boot (presumably on-chip), measured boot requires more complex trusted computing hardware (presumably off-chip). Personally, I find that systems that are overly-reliant on complex trusted computing hardware tend to lack in other areas. For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN. These systems try often to reconcile "analog" passkeys like Biometrics (FaceID, fingerprints) by using trusted computing. Of course, if the trusted computing systems are breached (https://www.404media.co/leaked-docs-show-what-phones-cellebrite-can-and-cant-unlock/ https://www.404media.co/leaked-docs-show-what-phones-cellebr...), then security is very weak. I suppose the advantage of the measured-boot method is that it is optional. So you can still boot whatever OS you want, just without some TC features.

IshKebab 2y ago

That is I've impressive final year project, nice work! Vector crypto is very cutting edge too. I guess there isn't any hardware that has it yet...

ReleaseCandidat 2y ago
SiFive's P670 Cores do: https://www.sifive.com/cores/performance-p650-670 https://www.sifive.com/cores/performance-p650-670 If and when they are available, I don't know, Sophgo licensed them: https://www.cnx-software.com/2023/10/21/sophgo-sg2380-16-core-sifive-p670-risc-v-processor-20-tops-ai-accelerator/ https://www.cnx-software.com/2023/10/21/sophgo-sg2380-16-cor... preorder is here: https://arace.tech/products/pre-order-milk-v-oasis-16-core-risc-v-desktop-coupon https://arace.tech/products/pre-order-milk-v-oasis-16-core-r...

zokier 2y ago

tbh I feel bad for the kid, his thesis supervisor should have helped him more here to scope and direct the work in some sensible way. now it is bit of a mess :( like just doing a review and comparison of existing boot verification mechanisms would have been already good scope for a thesis. Instead they are barely even mentioned as a side-note, which puts this in a awkward position. or if crypto was focus, then putting more work on designing and implementing the crypto scheme would have been relevant. Now they got so tangled with the nitty gritty boot details that the crypto ended up also as questionable side-note. or if rust was focus, then just implementing clean pure-rust bootloader could have been already enough for the thesis, avoiding the stumbling over on misguided crypto bits. or many other ways this could have been more successful. overall it now feels the author ended up biting far more than what they can chew. also they should have imho spent less time coding and more time on editing the actual thesis. the text is all over the place.

fch42 2y ago
You have rather high expectations towards the supervisor there ... maybe you were one of the "unlucky" ones who had a genius supervisor ... There aren't that many people in the world who write bootloader code daily for a living, an even smaller subset of those would ever have done one entirely from scratch (vs. just board-porting U-Boot), and even of those, the likelihood of someone having done a secureboot capable one wouldn't be high. Assuming you have such a person as a thesis advisor is a huge stretch ... That said though, a thesis is (or should be) a learning exercise. Even a complete fail (to achieve the "initial" objective) can make a great thesis if new knowledge - even negative proofs, "this isn't possible because ..." - come out of it. It's just my opinion maybe, but a graduate should never be taught "fake it till you make it"; rather, describe and document failures thoroughly, explain the observations, highlight and justify the parts that work or are breakthroughs. That can make a much better readable and much more useful thesis than one that skims over one-time lucky else nonreproducible results and delivers uncommented sources that fail to compile for anyone but the original author. In that sense, I would argue that a good thesis advisor will focus on the scientific process, documentary evidence, clarity of experimental setups and tests/checks/benchmarks performed, not whether the outcome would be "great enough" to pitch as a founder to VCs.